Ibm Worklight provides method sets the interval of the heartbeat signal and I am using it but could anyone please tell me What is the best practices for heart beat interval and server session time out.
The purpose of the heartbeat is (quoting from the link above): ".... to ensure that the session with the server is kept alive when the app does not issue any call to the server (such as invokeProcedure)."
The heartbeat is not being sent if the application has moved to the background (or stopped) allowing the session to expire.
This is why you should sync the hearbeat time with the session expiration timeout parameter in the server.
See more in: link
(search for "heartbeat")
Related
I am using ZK framework on server. Also, I use Spring Security and home grown security server.
Session timeout in Servlet container - 3600 seconds.
Session timeout in security server - also 3600 seconds.
Sometimes security server's session fils, but ZK session is still alive. I wrote servlet filter to intercept requests and check security server's session for availability.
So, I can intercept request to /zkau, but it's POST request and during redirect ZK shows error message box, with message about server connection error.
Does anyone knows, is there any way to tell ZK that it's session needs to be destroyed?
Best regads and thanks for wasting your time.
I suppose you kill session immediately during POST request to /zkau. Interface org.zkoss.zk.ui.Session has two methods to make session invalidated: invalidate and invalidateNow. The former method just sets the flag that indicates that session is invalid and native session will be invalidated on next request. I believe this is what you need.
I have a javascript SPA application that needs to support a user being offline for brief periods of time. I'm considering using actioncable for broadcasting changes the client may not be aware of.
If a websocket connection is lost for a brief amount of time, and then reconnected: will the client receive messages which were broadcast while they were offline?
Yes. Action cable will trigger a reconnect when the client gains access to the Internet.
You can test this your self by logging connections on your server and your client, then taking the client offline and reconnecting.
Hope this helps.
From the guide:
Broadcastings are purely an online queue and time dependent. If a consumer is not streaming (subscribed to a given channel), they'll not get the broadcast should they connect later.
So no, the client will not receive messages sent when they were offline.
Worklight 6.1.0.1 If I have a worklight server session timeout set to 1 hour, and I don't have a heartbeat interval set. The application starts, and establishes a connection with the WL server.
The WL server is shutdown, and not restarted. If the application does not invoke any back requests to the WL server (ex: connect, adapter, etc) while the server is stopped will the loss of connection be detected, or would I have had to set a heartbeat interval to cause the loss of connection to be detected?
If you did not write applicative code to handle off line scenarios, none is going to do that for you.
Consult with the Working Offline training module.
If you want to detect the loss of server connection please use the following
Events that are fired only on change of connectivity state. Success <--> Failure
WL.Events.WORKLIGHT_IS_CONNECTED and WORKLIGHT_IS_DISCONNECTED. For more info see this link
use onConnectionFailure in initOptions to figure out server connection failure.
See this SO answer for more info.
I have added the serverSessionTimeout=3 in the worklight properties file, I have edited this in the WAS server and restarted the application, but when i test the app and keep it idle for 3 mins, i cant see the server session time out automatically, is there anything we need to call on the mobile client to check if the server session time out is done or not. please help
Thanks
djrecker
Please look at the following documentation to get a better understanding of how the serverSessionTimeout and heartbeat property effect eachother as well as other tuning mechanisms:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fadmin%2Fc_optimizing_and_tuning_of_ibm_wl_server.html
Specifically the "Worklight Server internal configuration" section:
"Consider the following factors:
A session is an object that is stored in server memory for each connecting device. Among other things, it stores authentication information. The number of active sessions is the difference between the number of opened sessions and the number of sessions that are timing out because of inactivity. The serverSessionTimeout property configures the session timeout and affects the server memory consumption. The default session timeout is 10 minutes.
The mobile client "heartbeat" property causes the mobile client to ping the server while the app is in the foreground. This feature prevents the server session from timing out.
When a mobile app runs in the background, it no longer interacts with the server or sends a “heartbeat”. The server session drops after the specified server session timeout period.
For example, suppose every minute 1,000 users start a session against the server. Even if they exit the application after 3 minutes, their sessions remain active on the server for 10 minutes, leaving 10 x 1,000 = 10,000 active sessions.
"
You could try disabling the heartbeat using
WL.Client.setHeartBeatInterval(-1)
Maybe during the initialization of your app
Documentation at:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fapiref%2Fr_wl_client_setheartbeatinterval.html
With that the session timeout may work with the app in foreground too.
If the app is in the foreground, a heartbeat message will be sent
to the server and the session will not time out.
So the app should be placed in the background for the timeout to occur.
If that does not help, please try the test for a period of 10 minutes,
as this is the default session timeout value.
Normally the value of the serverSessionTimeout is greater than the
heartbeat interval so that the session is kept alive when idle and
as long as the application is in the foreground.
So as long as the app is in the foregraound,
by design it will never invalidate the session.
But on the other hand, if it is backgrounded then there are no heartbeats
and then past the default 10 min in the background state, the session
is invalidated. This is the intention here.
We have a Silverlight client which runs "out-of-browser" on a Mac. This client consumes a WCF service through a polling duplex binding.
In the client I am listening to the "Faulted" event exposed by the "InnerChannel" property of the System.ServiceModel.DuplexClientBase derivative which represents the service in the client side.
After exactly one minute this "Faulted" event is triggered and after that the channel is not working anymore, i.e. when the server tries to send a message through the callback channel it gets a timeout exception.
Here is a theory I have: I suspect that the underlying polling operation in the client has a timeout of 1 minute. In the server side the serverPollTimeout property of the pollingDuplexHttpBinding section is set to more than one minute. This means that the server holds a poll request for more than one minute if it has nothing to tell to the client during that time. I suspected that this revealed to the timeout in the client poll message. To test my theory, I've reduced the serverPollTimeout setting to less than a minute and indeed – the problem is not shown.
In the client-side, there is the PollingDuplexBindingElement.ClientPollTimeout property which is according to this blog exactly the setting which should tell the client to wait for more than a minute. The default for this setting is 5 minutes and I've even set it explicitly – but the problem still remains (without the workaround as described above).
Please note that this problem happens only on Mac out of browser client.
To sum-up, here are my questions:
How/where can I see a descriptive error message which tells exactly what is the problem here?
Why does it happen only in Mac out of browser client?
Can someone confirm my theory?
If my theory is true – how can I really set the timeout for the polling request in the client?
After a long thread regarding this with Microsoft support here are the conclusions regarding this issue:
The problem is relevant also for "regular" WCF calls. If we call a regular WCF operation from SL Mac OOB, it will timeout after exactly one minute, even-though the timeout is set to be higher
Microsoft confirmed that 60 seconds is the default timeout on Mac OS and that the SL runtime doesn't call the required Mac OS API to set it to higher value even-though the SL client code uses the documented SL API for changing the timeout. They say it’s "by design" since they are not aware of any scenarios where the server might take that long even in a long poll