I have an X-code app integrated with Mobile first platform 7.0. I want to implement idle session timeout for the app. I have tried two scenarios to resolve this issue.
First I have added below line in server.xml
<httpSession invalidationTimeout="10m" />
Second I have added below line in worklight.properties
serverSessionTimeout=10
I am still not getting time out after being idle for more than 10 mins.
What am I missing?
The serverSessionTimeout property is a server property. Meaning that the session expires in the server and if the client attempts to connect to the server after the set expiration time, then the client will act accordingly.
If you have a security challenge in place, then once the expiration took place, the challenge would've been invoked (once the client attempts to connect the server). Otherwise, you cannot detect this through this property.
What you can do, is set a "timer" on the client side that runs and counts until the session time has met, and do some logic based on it. This of course solely depends on what your required scenario is.
Related
my application (Node.js) is using moleculer for microservices and redis as transporter. However, I find that the application will have this log Redis-pub client is disconnected every 10 minutes, then reconnect with the log Redis-pub client is connected after a few seconds. This is a problem because if a client send a moleculer action during this time, it will fail.
Any idea what is causing this? Let me know if more information is needed.
Azure Cache for Redis currently has a 10-minute idle timeout for connections, so the idle timeout setting in your client application should be less than 10 minutes. Most common client libraries have a configuration setting that allows client libraries to send Redis PING commands to a Redis server automatically and periodically. However, when using client libraries without this type of setting, customer applications themselves are responsible for keeping the connection alive.
More info: https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-best-practices-connection#idle-timeout
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
We have a WCF Service that runs on a Domain Server. We have a couple a website (WCF Client) not on the domain and we use Username and password to authenticate. And everything workes fine.
Some days when the Service app-pool recycles the website fails to connect and starts throwing lots of identity check failed error messages. (The expected identity is 'identity(http://schemas.xmlsoap.org/ws/2005/05/identity/right/possessproperty: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/thumbprint)' for the 'http://xxx.com:8004/sts.svc/username' target endpoint.) But most days it works fine.
What could be wrong and how to resolve this.
** The clocks on the server and client are in sync.
thanks
Ravi
Check the clocks on the servers and clients. WS-Security fails if the clock skew between the client and server is greater than a threshold, 5 minutes by default.
The automatic clock sync on Windows Server doesn't always do its job. Clients may not sync at all. If everyone syncs to a reputable time source (NIST, for example), your problems may go away entirely.
I have a WCF Service Deployed on IIS. (BasicHTTPBinding with [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)])
I have built custom in-memory session management and Now I am facing a strange problem that is IIS 7 Restarts Automatically without even throwing any kind of warning or error not even in EventLog. This problem leads to destroy the all available sessions.
I discovered this issue after logging the Application_Start and Application_End methods using log for net and also i put the break point in application_start and it paused there in between test execution.
This happens rarely but i need to know why it happens and if it is normal and acceptable or not. if not then what may be the possible reasons of this.
Regards
Mubashar Ahmad
Could it be the app pool being re-cycled? IIS 6 has this set on by default to 1740 minutes. As for IIS 7 I guess you would have the same kind of setting? I know in IIS 6 this "event" is not logged as 'n error.
IIS recycles worker processes either when it detects an "unhealthy" process, or after certain operator-configurable limits are reached.
Among the limits are:
memory threshold
after a configured number of requests
elapsed time
time of day
more info
The Session timeout (which is separate to the app pool recycling) is set to 90 minutes by default, this is set at the application level. This also means anything being held in Session will be blown away at that time. You can set it via the properties of the virtual directory/application in IIS6, and via SessionState->Open Feature in IIS7 (when you have the application selected).
Also note that session timeout can be set via the web.config of an ASP.Net application, should your web services be hosted in one of those.