You are viewing limited content. For full access, please sign in.

Question

Question

WebLink11 disable KeepAliveTimer

asked on January 27, 2022

I have a customer using WebLink 11 for internal purposes only and they have sessions being held open but inactive for hours or days and they have to manually kill the connections through the LF Admin Console.

There is an old KB (KB: 1012655) that tells how to disable/stop the KeepAliveTimer to prevent this type of thing when someone keeps the document open in a tab.  We do not find the "$(document).ready(function()" in the WebLink 11 DocView.aspx.

Is there a new method of preventing the DocView from keeping a session open?

0 0

Answers

APPROVED ANSWER
replied on May 26, 2022 Show version history

Hi @████████ and @████████!  We tracked down the problem and implemented a fix; we're giving a build to Support that they can provide through support cases right away.  We'll get it deployed more generally in a patch in the near future.

2 0
SELECTED ANSWER
replied on February 2, 2022 Show version history

Hi Bert,

I don't believe that KB item should be relevant anymore. Instead, the timeout is based on the provided value in web.config which is what the designer setting impacts. If that is not working, there may be more to investigate here as a support case. 

0 0

Replies

replied on May 17, 2022 Show version history

Hi Bert,

The timeout set in the WebLink Designer (or web.config) isn't meant to apply to connections to the Laserfiche Server; instead, it defines how long a WebLink ASP.NET browser session can be idle before it expires.

Idle timeout for Laserfiche sessions can be set in the Admin Console: https://doc.laserfiche.com/laserfiche.documentation/11/administration/en-us/Subsystems/LFAdmin/Content/Automatically_Logging_Out_a_User.htm

(Note that LF is conservative about ending sessions, since a long-running operation could look like an idle session, so you still might not see sessions ending after the exact time you set: see this post.)

Have you tried changing this setting?

If you have changed the repository idle logout setting and WL's behavior still seems incorrect (or inconsistent with other clients' behaviors), it's possible that WL is aggressively renewing Laserfiche sessions even after WebLink sessions have expired.  As mentioned elsewhere in the thread, we have Bug 370909 to investigate whether this really is a WL issue.

1 0
replied on May 17, 2022

In most cases, the customer is only concerned with the WebLink connections and all other connections can be kept open as long as the user wants.  But with WebLink, bots tend to tie up the licenses and then no one can get in through WebLink.

So setting a global timeout in the Admin Console is not the desired solution.

0 0
APPROVED ANSWER
replied on May 26, 2022 Show version history

Hi @████████ and @████████!  We tracked down the problem and implemented a fix; we're giving a build to Support that they can provide through support cases right away.  We'll get it deployed more generally in a patch in the near future.

2 0
replied on July 19, 2022

Any update on this?  When will the patch be available? If I need to have my VAR contact support to get it, how should they request it?

1 0
replied on July 19, 2022

@████████It is available, reference #370909. 

1 0
replied on January 28, 2022

In WebLink Designer on the Connection tab is a Session Timeout parameter.  Connection (laserfiche.com).  Which is supposed to automatically disconnect idle sessions.

0 0
replied on January 28, 2022

The Session Timeout is set at 15 minutes and is not being enforced.

0 0
replied on January 28, 2022

Possible bug?  Or Laserfiche's definition of an idle session needs clarification.

0 0
replied on January 28, 2022

any input from Laserfiche staff?

0 0
replied on February 2, 2022

bump

0 0
replied on May 16, 2022

@████████, were you able to get any more details on this issue?

 

0 0
replied on May 16, 2022

@████████, no I did not hear anything more than the response from @████████ above.

0 0
replied on May 16, 2022

I'm wondering if it is related to bug #370909.

0 0
replied on May 16, 2022 Show version history

We're taking a look into that specific bug and expect it's related. It's on our current radar but no root cause yet. 

3 0
replied on May 20, 2022 Show version history

I hadn't planned to spend the weekend jumping into the admin console every two hours to manually close connections. Oh well.

0 0
replied on May 20, 2022

Hi Steve,

For a scenario like that, you can consider updating the repository idle timeout for Laserfiche sessions that Melanie discusses below. We are still looking into the best way to approach this going forward, but that seems like it should allow you to avoid having to sign in every 2 hours this weekend. 

1 0
replied on May 23, 2022

Hi Justin,

Unfortunately, my repository idle timeout is set to 60 minutes. This morning when I got into the admin console, I had 10 connections over two hours Inactive Duration, and probably 10 more over an hour. Since this is a global setting, I think I can't make my named users connections drop more frequently than that.

I've set my robots.txt to dissallow all.

I made a macro (using MacroScheduler https://www.mjtnet.com/  ) that logged into the admin console and removed the top four connections with a certain login name (the public login) every couple hours then kept track of it by making sure I could login and do a search every so often throughout the weekend. 

It wasn't perfect but the public portal stayed up all weekend. Happily, because of the macro, my "checking in on it" didn't involve vpn-ing in every couple hours, just checking it from my phone periodically.

0 0
replied on May 26, 2022

Hi @████████

We tracked down the problem and implemented a fix; we're giving a build to Support that they can provide through support cases right away.  We'll get a patch released more generally in the near future.

1 0
replied on June 15, 2022

The hotfix seems to have resolved my problem. Thank you!

2 0
You are not allowed to follow up in this post.

Sign in to reply to this post.