on 05-06-2011 1:27 PM
When trying to preview/show a WD4A which has shortly been transported from QS to PROD we are getting the error
"LockException / failed to acquire exclusive lock on client session"
on QS this doesn't occur. Both Systems (Portal QS+ HCM QS AND Portal PROD + HCM PROD) are on equal Systems and SPs
I checked the following notes:
1180508 (doesn't really help)
1234847 (supposedly doesn't apply as the Application is WD4A)
I checked thread /thread/1596510 [original link is broken] and thus made our basis guys check the Databases, all is fine (supposedly, this is outside of my reference).
Detailed error Log:
Exception occured during processing of Web Dynpro application sap.com/pb/PageBuilder. The causing exception is nested.
[EXCEPTION]
com.sap.tc.webdynpro.services.session.LockException: Thread SAPEngine_Application_Thread[impl:3]_7 failed to acquire exclusive lock on client session ClientSession(id=(J2EE317770400)ID0741190250DB44961f08fcc5c2790ca21b628b7e6b4258207430End_488588755). Existing locks: LockingManager(ThreadName:SAPEngine_Application_Thread[impl:3]_7, exclusive client session lock: ClientSessionLock(SAPEngine_Application_Thread[impl:3]_12), shared client session locks: ClientSessionSharedLockManager([]), app session locks: ApplicationSessionLockManager([]), current request: sap.com/pb/PageBuilder).Hint: Take a thread dump of the server node to find the blocking thread that causes the problem.
at com.sap.tc.webdynpro.clientserver.session.ClientSession$LockingManager.lock(ClientSession.java:1539)
at com.sap.tc.webdynpro.clientserver.session.ClientSession.doProcessing(ClientSession.java:236)
at com.sap.tc.webdynpro.clientserver.session.RequestManager.doProcessing(RequestManager.java:149)
at com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doContent(DispatcherServlet.java:62)
at com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doPost(DispatcherServlet.java:53)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java:401)
at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java:266)
at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:386)
at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:364)
at com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java:1060)
at com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java:265)
at com.sap.engine.services.httpserver.server.Client.handle(Client.java:95)
at com.sap.engine.services.httpserver.server.Processor.request(Processor.java:175)
at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:33)
at com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java:41)
at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
at java.security.AccessController.doPrivileged(Native Method)
at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:104)
at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:176)
best regards.... Lukas...
But this is java exception and note 1234847 does apply here.
the reason for this
Web Dynpro provides a single-threaded programming model. As soon
as a request for a user session is processed, the user session is
blocked for the duration of the request, i.e. there is always atmost one
thread that has acquired the lock of a user session.
Concurrent requests which refer to the same user session(i.e.
triggered from the same browser process) are serialized and
processed one after each other. If there is a request which
blocks or hangs due to some waiting/blocking condition, then
other concurrently incoming requests are waiting for a certain
period of time that the user session lock is released. If they
can't acquire the user session lock after this time interval, the
waiting thread terminates with a LockException error page.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Siddarth,
Thanks for your quick reply.
You are right, dispatcher is still java, so the note does apply of course ;-/ . We have compared the property "sap.locking.maxWaitInterval" in visual admin provided by the note between our QS and our PROD. It is the same. I would feel strange just "trying" to alter the value in prod system while it all works fine in QS.
We try what note 710154 suggests next. In the meantime, do you have any other ideas what we could do?..
best regards, Lukas
Edited by: Lukas Weigelt on May 9, 2011 10:28 AM
You can set that or raise a message for SAP, with the traces or attach the snapshot here!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
we found a problem with the URL-generation in our WebDynpro-Application not generating a full qualified domain name.. That's probably why the handshake of http/https cannot be accomplished and the session is queued/waiting forever... We resolve this issue tonight. Hopefully this does it now. I'll give feedback tomorrow.
best regards, Lukas
production there will be more usage so you can use this parameter
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi..
We have done as suggested concerning thread dumps. Basis Team could'nt find any abnormalities. I, myself, don't even remotely understand what is output in the dumps (I'm lacking the java-knowledge)...
What exactly in the logs do we have to fix our eyes on? Are we missing something?
Concerning Parameter sap.locking.maxWaitInterval. We might try setting it to 100....
best regards, Lukas
You could do these
1234847 - Analysing WebDynpro session LockException
here lets focus on:
[1]
Please check the parameter sap.locking.maxWaitInterval as the note
suggests.
[2]
If the parameter does not help, then
Please create 3 thread dumps for dispatcher process as describe in note
710154 I mentioned before:
- Create one thread dump.
- Wait 30 seconds.
- Create another one.
- Wait 30 seconds.
- Create another one.
Do the same with for the server process.
and verify the thread dumps
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Siddarth,
[1] sap.locking.maxWaitInterval is blank on all machines, yet error only occurs on PROD.
[2] EDIT: We have created a dump. Can you give us hints what entries we "are looking for" oder what they "look like"? I dare not post it here because it has over 100 pages...
thanks a lot until now
regards, Lukas
Edited by: Lukas Weigelt on May 10, 2011 9:11 AM
User | Count |
---|---|
103 | |
12 | |
11 | |
6 | |
6 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.