cancel
Showing results for 
Search instead for 
Did you mean: 

LockException / failed to acquire exclusive lock on client session

Lukas_Weigelt
Active Contributor
0 Kudos

Hi guys... in continuation to

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...

Accepted Solutions (1)

Accepted Solutions (1)

siddharthrajora
Product and Topic Expert
Product and Topic Expert
0 Kudos

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.

Lukas_Weigelt
Active Contributor
0 Kudos

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

Answers (3)

Answers (3)

siddharthrajora
Product and Topic Expert
Product and Topic Expert
0 Kudos

You can set that or raise a message for SAP, with the traces or attach the snapshot here!

Lukas_Weigelt
Active Contributor
0 Kudos

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

Lukas_Weigelt
Active Contributor
0 Kudos

One issue solved, the problem remains. I will close this thread "unanswered" and open a new one for a more general question regarding portal communication.

regards, Lukas

siddharthrajora
Product and Topic Expert
Product and Topic Expert
0 Kudos

production there will be more usage so you can use this parameter

Lukas_Weigelt
Active Contributor
0 Kudos

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

siddharthrajora
Product and Topic Expert
Product and Topic Expert
0 Kudos

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

Lukas_Weigelt
Active Contributor
0 Kudos

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