Catalog request queued and status unknown after Catalog upgrade

book

Article ID: 141207

calendar_today

Updated On:

Products

CA Service Catalog

Issue/Introduction

CA Service Catalog 17.2 RU4 and later (Ex: RU5, RU6, RU7,RU8)  

After applying RU4, newly submitted requests get stuck in "Request Queued" status. Uninstalled RU4 back to RU3 and it  works normally again .

Users may also see a Current Status of "unknown" and the Request Status "Not Submitted - Cart" under the Status Change History.

In view.log ,  noticed the following errors :

2019/12/04 19.14.56.961 ERROR [ActiveMQ Session Task-8] [RequestQueueListener] Unable to handle request failure due to JMS message exception: javax.jms.JMSException: Failed to build body from bytes. Reason: java.io.StreamCorruptedException: Inconsistent vector internals
2019/12/04 19.14.56.961 ERROR [ActiveMQ Session Task-8] [RequestQueueListener] Request Submission failed for request with exception:javax.jms.JMSException: Failed to build body from bytes. Reason: java.io.StreamCorruptedException: Inconsistent vector internals

Cause

one critical post RU4 step is not done . Also potential corrupted viewService.conf file under USM_HOME\view\conf\

Environment

Release : 17.2 and higher

Component : CA SERVICE CATALOG

Resolution

After applying RU4 ,  there is one critical  post step you will need to do .   This post step mentioned in the following documentation :

https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/business-management/ca-service-management/17-2/installing/Installing-CA-Service-Management-17_2_0_4/Post-Installation-Tasks-for-CA-Service-Management-17_2_0_4.html

 

Basically ,   in viewService.conf file under USM_HOME\view\conf\   ,  you will need to add the following line :

 

wrapper.java.additional.24=-Dorg.apache.activemq.SERIALIZABLE_PACKAGES=java.lang,javax.security,java.util,org.apache.activemq,org.fusesource.hawtbuf,com.ca,com.ca.usm.billing.ServiceManager,wv,sun

 

after the line :   wrapper.java.additional.23=-Xverify:none

 

Please note  : while adding the entry  "wrapper.java.additional.24", maintain the step sequence.

and then recycle catalog service .  If there are more than one catalog node on the catalog system , it will need to be done on all catalog  nodes .    It should be able to resolve this issue

Additional Information

If you upgrade the catalog from 17.1  to 17.3  ,  you will also need  to do what mentioned above .  Otherwise ,  the catalog request will have trouble to kick off PAM process from catalog . 

In the case of an upgrade from 17.1 to 17.3, if the issue is occurring despite applying the above post install step, please check the viewService.conf file under USM_HOME\view\conf\ if there are any duplicate entries of the same lines. 

In at least one instance of the above concern encountered, the following lines were detected in the given viewService.conf file:

But further down in the same file, we see:

Note the duplicate line references.  In this example, the latter three lines (140, 141, and 142) were commented out to correct the issue.

Such a scenario may arise if there are backup copies of viewService.conf file present in the same location as the original viewService.conf file and the post-install steps performed automatically during the RU patch install process.

Attachments