Wednesday, April 29
Web Dynpro error page, known error situations, error codes
Symptom
Web Dynpro error page is shown
Other Terms
Web Dynpro error page error code
LockException SessionExpiredLongJumpException ChunkLimitException SessionLimitExceededException RuntimeException Error
LockException SessionExpiredLongJumpException ChunkLimitException SessionLimitExceededException RuntimeException Error
Reason and Prerequisites
Exception occurs in Web Dynpro and Web Dynpro error page is shown.
Solution
This note describes how a user should analyze the Web Dynpro error page that is shown in case an error occurs when procesing a Web Dynpro application. It also describes well-known error codes and error situations which are not related to funtional correctness of the UI runtime.
=======================================================================
Analyzing error page information:
In case an error occurs when processing a request to a Web Dynpro application, an error page is shown.
System runs in development mode:
If the system runs in development mode, the error page contains following details about the related error.
If the shown error page results in a CSN, the complete error page should be saved as HTML file and attached to the CSN message.
System runs in productive mode:
If the system runs in productive mode, the error page only shows a log ID which references to the detailed exception stacktrace in the trace or log file. The related defaultTrace.trc and log file should be checked for further analysis. This can be done by the system administrator. To disable the reduced error page, the administrator can connect to the Java EE telnet console and type in following command:
> setsp -p DetailedErrorResponse true http
If the shown error page results in a CSN, the related defaultTrace.trc, and log file should be attached to the CSN message. Additionally, the system information page should be saved as HTML file and attached to the message (-> Web AS start page -> System Information).
For more information on how to get the defaultTrace.trc and System Information please have a look to note 742674. For more information on how to switch between productive and development mode see note 962319.
=======================================================================
Description of well-known error situations, their reasons and solutions:
There are some well-known error situations which are not related to a bug or functional incorrectness of the Web Dynpro runtime. The following list shows such error situations, grouped by exceptions and error codes, and explains their causes and possible solutions.
SessionLimitExceededException:
LockException:
SessionExpiredLongJumpException:
DispatcherException:
"Failed to process the request: Request refers to an unknown session":
"Failed to process the request: The suspension of a non-suspendable application resulted in the destruction of the requested session.":
=======================================================================
Analyzing error page information:
In case an error occurs when processing a request to a Web Dynpro application, an error page is shown.
System runs in development mode:
If the system runs in development mode, the error page contains following details about the related error.
- Exception text and error code
- System information, like version of the used Web Dynpro runtime, Web AS version, etc.
- Correction hints are shown if a well-known error situation has occured that is not related to a bug in the Web Dynpro runtime.
- If the error page is shown due to a unexpected error situation, the stacktrace of the exception is shown in a short version and additional in a full version at the bottom of the error page. Often, causing exceptions are nested in such stacktraces. Nested Exceptions can be identified by 'Caused by' prefix. To find the root cause of the problem, the last nested exception of the stacktrace is relevant. This is the exception after the last 'Caused by'.
If the shown error page results in a CSN, the complete error page should be saved as HTML file and attached to the CSN message.
System runs in productive mode:
If the system runs in productive mode, the error page only shows a log ID which references to the detailed exception stacktrace in the trace or log file. The related defaultTrace.trc and log file should be checked for further analysis. This can be done by the system administrator. To disable the reduced error page, the administrator can connect to the Java EE telnet console and type in following command:
> setsp -p DetailedErrorResponse true http
If the shown error page results in a CSN, the related defaultTrace.trc, and log file should be attached to the CSN message. Additionally, the system information page should be saved as HTML file and attached to the message (-> Web AS start page -> System Information).
For more information on how to get the defaultTrace.trc and System Information please have a look to note 742674. For more information on how to switch between productive and development mode see note 962319.
=======================================================================
Description of well-known error situations, their reasons and solutions:
There are some well-known error situations which are not related to a bug or functional incorrectness of the Web Dynpro runtime. The following list shows such error situations, grouped by exceptions and error codes, and explains their causes and possible solutions.
SessionLimitExceededException:
- Symptom:Error page is shown with either a com.sap.tc.webdynpro.services.exceptions.SessionLimitExceededException
- Error code: 403 - Forbidden
- Cause: There is a configurable maximum number of sessions which can be started by a single user in one user session. If this maximum limit is exceeded, the error page comes up. There is an extra user session per browser process (respectively per browser login). Web Dynpro counts following sessions within a user session:
- Web Dynpro applications running without the portal
- Portal pages containing embedded Web Dynpro applications are counted when running within the portal
- Solution:
- User must close external browser windows or browser tabs to reduce the number of active sessions.
- If the maximum number of allowed sessions per user session is to small in general, the administrator can configure it via the parameter "sap.max.session.limit" in the Web Dynpro default.properties (for details, see note 1012065).
LockException:
- Symptom:Error page is shown with a com.sap.tc.webdynpro.services.session.LockException
- Error code: 408 -Request Timeout
- Cause: 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 at most 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.
- Solution:
- The LockException error page shows a 408 error code and the stacktrace of the thread that holds the user session lock and that is responsible for the blocking/waiting condition. Forward the stacktrace to the development group or CSN component that can help to understand the shown stacktrace and explain the waiting/blocking condition.
- If there are intended long running requests which hold the user session lock for a longer time, an administrator might want to configure the maximum time for which an incoming request will wait if the user session lock is already taken. This can be done via "sap.locking.maxWaitInterval" parameter in the Web Dynpro default.properties (for details, see note 1012065).
SessionExpiredLongJumpException:
- Symptom:Error page is shown with a com.sap.tc.webdynpro.clientserver.session.SessionExpiredLongJumpException
- Error code:400 - Session Timeout
- Cause 1: A started application was untouched for a certain period of time and has expired in the meantime. The expiration happens as an asynchronous server event and the client is not notified about this event. The user is notified about it the next time when a request to the expired application is triggered and the error page with the SessionExpiredLongJumpException is coming up.
- Cause 2:A application that is started on the client is stopped/removed/redeployed on the server. Such an action leads to a termination of the depending sessions on the server. The user gets a SessionExpiredLongJumpException when triggering the next request to the related application.
- Solution:The user has to restart the application (browser refresh, or "Refresh" entry in the IView tray menu in the portal).
DispatcherException:
- Symptom:Error page is shown with a com.sap.tc.webdynpro.services.sal.core.DispatcherException
- Error code:500 - Internal Server Error
- Cause: The requested application is not deployed on the server.
- Cause: There is a typo in the application URL, i.e. the URL doesn't address an existing and deployed application.
- Solution: The user should check the URL for typos; the user should contact the system administrator whether the requested application is deployed at all.
"Failed to process the request: Request refers to an unknown session":
- Symptom: Error page is shown with message text: "Failed to process the request: Request refers to an unknown session".
- Error code: 404 - Application Not Found
- Cause: The server received a request which refers to an assumingly existing application session which is unknown to the server.
- Solution: The problem occurs if for instance the client has sent an incorrect request to the server, or the request dispatching mechanism of a cluster incorrectly dispatched a postback/follow-up request to a wrong server node. For a concrete analysis, the http traffic should be recorded using a tool like HttpWatch and the recording should be attached to an OSS message. To check whether a wrong request dispatching is the problem, check if the loadbalancing cookie "sap_lb" contains the same value over the sequence of requests. If this is not the case, it is an indication that the request was dispatched to the wrong server node during the sequence of requests.
"Failed to process the request: The suspension of a non-suspendable application resulted in the destruction of the requested session.":
- Symptom: Error page is shown with message text: "Failed to process the request: The suspension of a non-suspendable application resulted in the destruction of the requested session.".
- Error code: 400 - Suspend Error
- Cause: The server received a request which refers to an assumingly suspended application session which was destroyed because the application is marked as non-suspendable.
- Solution: The problem occurs if a request is sent with previous session parameters. For a concrete analysis, the http traffic should be recorded using a tool like HttpWatch and the recording should be attached to an OSS message. Check whether the request contains the request parameters "sap-wd-norefresh" or "sap-wd-cltwndid".
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment
You are welcome to express your views here...