Extended Log

-
Recently, I was running some support flows for a CRM application.
After recording the scripts, I was about to run load test. For this purpose I refreshed the database.
When I replayed the scripts with fresh database dump, close case started failing as shown below:
Action.c(344): Notify: Transaction "11. Close Case" started.
Action.c(346): Error -26368: "Text=com.uif.common.ExceptionInfo" found for web_global_verification ("CRMGlobal") (count=1)        [MsgId: MERR-26368]
Action.c(346): web_custom_request("crm_39") highest severity level was "ERROR", 3811 body bytes, 312 header bytes    [MsgId: MMSG-26388]
Action.c(346): Notify: Transaction "11. Close Case" ended with "Fail" status (Duration: 1.1719).

As we can see above there is an exception com.uif.common.ExceptionInfo. The above detail was displayed when the logging level is set to standard log.
Since an exception has occurred after refreshing the database, there must be some parameter dependent on database. So ran the script again with the Extended Log on.
The below log is displayed for the close case. It failed again but with more details.
If we go through the log, we can observe that in respose to the resquest log the following line "x00HClose Case: Failed. There is no available transition to a Closed Status."
Action.c(344): Notify: Transaction "11. Close Case" started.
Action.c(346): web_custom_request("crm_39") started       [MsgId: MMSG-26355]
Action.c(346): Notify: Parameter Substitution: parameter "Ticket" =  "<Tksmau6TK20eK5d7mHyzhZu4UGxZuHlr4t5Cd8s0;appId="
Action.c(346): Notify: Parameter Substitution: parameter "CaseObjid" =  "34359762141"
.
.
.
Action.c(346): t=32887ms: 500-byte request headers for "http://10.25.230.117:9000/crm" (RelFrameId=1, Internal ID=14)
Action.c(346):     POST /crm HTTP/1.1\r\n
...
...
...
Action.c(346): t=33934ms: 312-byte response headers for "http://10.25.230.117:9000/crm" (RelFrameId=1, Internal ID=14)
Action.c(346):     HTTP/1.1 200 OK\r\n
Action.c(346):     Date: Thu, 07 Jun 2012 09:33:49 GMT\r\n
Action.c(346):     Server: Apache/2.0.59 (Unix)\r\n
Action.c(346):     Content-Length: 3811\r\n
Action.c(346):     Content-Transfer-Encoding: binary\r\n
Action.c(346):     X-Powered-By: Servlet/2.5 JSP/2.1\r\n
Action.c(346):     ASCFServer-Elapsed-Nano: 343188943\r\n
Action.c(346):     Keep-Alive: timeout=100, max=487\r\n
Action.c(346):     Connection: Keep-Alive\r\n
Action.c(346):     Content-Type: application/octet-stream\r\n
Action.c(346):     \r\n
Action.c(346): t=34059ms: 2920-byte response body for "http://10.25.230.117:9000/crm" (RelFrameId=1, Internal ID=14)
Action.c(346):     \xAC\xED\x00\x05sr\x000com.uif.common.datatype.ResponsePayloadVo\x00t\xE0\x8FR\xB6\xE0
Action.c(346):     \x95\x0C\x00\x00xpw\x01\x01pur\x000[Lcom. uif.common.datatype.ResponseItemVo;\xDE\x0B
Action.c(346):     \x07p*\x92_\x1C\x02\x00\x00xp\x00\x00\x00\x01sr\x00-com.uif.common.datatype.Respons
Action.c(346):     eItemVo\x00t\xE0\x8FR\xB6\xE0\x98\x0C\x00\x00xpw*\x01\x00\x1Fqaperflab01xp_ReqThread_T1_42
Action.c(346):     _1\x00\x00\x00\x00\x00\x00\x01\x0Fsr\x00#com. uif.common.ExceptionInfo\x00r\xBE\xDC\xEE
Action.c(346):     \xA87`\x03\x00\x04L\x00\x07m_Causet\x00%Lcom/uif/common/ExceptionInfo;L\x00\x0Bm_Cl
Action.c(346):     assNamet\x00\x12Ljava/lang/String;L\x00\tm_Messageq\x00~\x00\x08[\x00\x0Cm_StackTracet\x00
Action.c(346):     \x1E[Ljava/lang/StackTraceElement;xpsq\x00~\x00\x06pt\x00'com.clarify.webframework.AbortEx
Action.c(346):     ceptiont\x00HClose Case: Failed. There is no available transition to a Closed Status.ur\x00
Action.c(346):     \x1E[Ljava.lang.StackTraceElement;\x02F*<<\xFD"9\x02\x00\x00xp\x00\x00\x00$sr\x00\x1Bjava.

Tried the flow manually on the application. Same exception is posted on the screen. So, Close case is failing in application also.
Added the transition in the database, as in every database refresh the transition is deleted and need to create one.
The issue is resolved, after replacing the id of the transition created with that of the old present in the script.
In this way, we can use the Extended log to get the exact cause of the exception.

Comments

Post a Comment

Popular posts from this blog

Steps to Analyze AWR Report in Oracle

-
Image
Steps to Analyze AWR Report in Oracle AWR -   Automatic   workload repository is a collection of persistent   system performance   statistics   owned by SYS. It resides in SYSAUX   tablespace . By default snapshot are generated once every 60 min and maintained for 7 days . Each snapshot has a unique ID know as "snap_id". Snapshot detail can be found in " dba_hist_snapshot " view.   If we have Database performance issue and not the Database machine, then AWR Report is the place to look at. AWR is not used for real-time performance monitoring like the v$ tables. It is used for historical analysis of performance. AWR complements, but doesnot replace real-time monitoring. Once AWR Report is generated in Oracle, the next task is to analyze it. By going through the AWR Report we can easily solve issues like slow database, high wait events, slow query and many more issues. Even though the report is lengthy, Analyzing or Reading relevant part of AWR Report can
Read more

Vmstat Output explained

-
vmstat : vmstat is a tool in Unix/Linux which is used to Report virtual memory statistics. It shows how much virtual memory there is, how much is free and paging activity. Most important, you can observe page-ins and page-outs as they happen.   vmstat   reports   information about processes, memory, paging, block IO, traps, and cpu activity.   > vmstat procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----   r   b    swpd    free    buff   cache         si    so     bi     bo    in    cs us sy id wa st   0   0   21688 12797396 850716 15372668     0     0      3     35     0     0   1   0 99   0   0   0   0   21688 12789292 850716 15372668     0     0      0   1355   883   744   1   0 99   0   0   1   0   21688 12784648 850716 15372676     0     0      0     15 1934 1292   6   0 93   0   0   2   0   21688 12781356 850716 15372736     0     0      0     16 2222 2094   8   1 92   0   0   0   0   21688 12809992 850716 15376880     0
Read more

Verifications and Error Handling in LoadRunner *Web_reg_find and Web_reg_save_param*

-
Verification's and Error Handling Verification points must be inserted into the scripts to verify the application being tested with the load. Verification function that are used in our application are:  Web_reg_find, web_reg_save_param These verification should be outside towards the end of the transaction. Mandatory verification points: ■          Login – whenever there is a login, verification points must be added to verify that the user logged in correctly. ■          Update Transactions – transactions that update the database must be verified that they are successful. ■          Each page should be verified using Web_reg_find function Using Web _ reg_find for verifications. Example: web_reg_find("Text= Main Package","SaveCount=Verify_Count1",LAST); Verification: if (strcmp(lr_eval_string("{Verify_Count1}"),"0")==0) { lr_end_transaction("AddMainPackage", LR_FAIL);  lr_error_message(&q
Read more