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.
Related
I have a simple webbapp deployed in tomcat8. But some HTTP requests requires access to DB with slow queries. Sometimes HTTP client made reset connection. In the same time i'd like to handle it in my webapp for cancel slow query (which result is no longer interesting).
The main question: "How to catch reset connection from client side in phase awaiting response from server". Is it possible? Interrupting thread - the best way for it because I can easly handle it.
When connection is broken from client side tomcat does not interrupts http-nio-X thread. Why? How to do it?
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.
the service endpoint socket connection always abort 10 mins after last use.
the above image shows that the last use of the end point was 10:18:21. after 10 mins, activity Aborted 'System.ServiceModel.Channels.ServiceChannel' happened. is the 10 mins time out a default setting for WCF endpoint socket connection? can I set the timeout to be infinite? notice the abortion happens on a separate thread(thread 16).
or did I not configure the endpoint correct on the service endpoint?
The socket connection timeouts needs to be configured on both client and server side (smaller of the two will prevail). These should be done via binding configuration (in config or code). The timeouts can be done via inactivityTimeout setting of a reliableSession, in combination with recieveTimeout of the netTcpBinding. You can also consider using idleTimeouts in the connection pool settings option of netTcpBinding. It is typically not recommended to set infinite timeouts unless you have very specific needs that need to be met and have service usage parameters that safegaurd against infinite timeouts.
Can I configure Glassfish to drop any request that takes longer than 10 seconds to process?
Example:
I'm using Glassfish to host my web service. The thread pool is configured to have max 5 connections.
My service has a method that does this:
System.out.println("New request");
Thread.sleep(1000*1000);
I'm creating 5 requests to the service and I see 5 messages "New request" in the log. Then the server stop to respond for a looong time.
In live environment all requests must be processed in less than a second. If it takes more time to process then there is a problem with the request and I want Glassfish to drop such requests but stay alive and serve other requests.
Currently I'm using a workaround in the code. At the beginning of my web method I launch a separate thread for request processing with a timeout as it was suggested here: How to timeout a thread
I do not like this solution and still believe that there must be a configuration setting in the Glassfish to apply this logic to all requests, not to just one method.
Hi I have a application that is deploy on two weblogic app servers
recently we have issue that for certain cases the user session returned is null. Developer feedback is that it could be caused by the session not replicating to the other server.
How do we prove if this is really the case?
Are you using a single session store that both application servers can access via some communication protocol? If not, then it is definitely the case. Think about it, if your weblogic servers are storing the session in memory anywhere, and having users pass their session id via cookies, than the other server has no way of accessing the memory on the other machine. Unless you are using sticky load balancing. Are you?
There's 2 concepts to consider here - Session stickiness and session replication.
Session Stickiness is a mechanism where weblogic server ensures that if a request from a user with session A goes to server 1 then the next request from user with session A will go to server 1 only.
This is achieved by configuring a hardware loadbalancer (like F5) which is capable of providing session stickiness. or configuring weblogic proxy installed on apache/iis/weblogic.
The first time a request reached WLS managed server, it responds with a session id and appends to it the JVM id of the server (this is the primary id), if the managed server is part of a cluster, it also attaches a secondary server jvm id (the secondary server is the server where the session is being replicated)
The proxy maintains a table of all JVM id's and corresponding IP of managed server, it also checks periodically if the servers are up and running or not.
The next time when another request passes the proxy with existing session id and a primary jvm id, the proxy parses this and tries to send the request to that server, if it cannot within some time it tries to send to secondary server.
Session Replication - This is enabled by default when you configure a WLS cluster with 2 or more managed server. Each time any data is updates to a session, its data is replication in a secondary server too.
So in your case if your application users are loosing session or getting redirected to login page between normal usage, then check that the session did not get invalidated because of a timeout, if you have defined a cluster and using WLS proxy then check the proxy debug output to make sure the primary and secondary server are being appended to the session id.
Finally there's a simple example in the sample application deployment of wls that you can use to test session replication and failover functionality.
So to prove why session is getting lost,
1) check server log to see if session got invalidated because of timeout,
2) if using wlproxy, enable debug, and the next time the issue happens check in the proxy log if the request was sent to a different server, and if that server is not the secondary server.