cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4418
Views
25
Helpful
8
Replies

CUCM 8.6(2)SU1 Web Access

James Hawkins
Level 8
Level 8

Hi,

I have a customer running a cluster of five CUCM 8.6(2)SU1 servers on MCS7835-I3 hardware - see full details below:

admin:show version active

Active Master Version: 8.6.2.21900-5

Active Version Installed Software Options:

cmterm-7945_7965-sccp.9-2-1.cop

cmterm-7942_7962-sccp.9-2-1.cop

ciscocm.refresh_upgrade_v1.1.cop

cm-locale-en_GB-8.6.2.1000-1.cop

admin:show hardware

HW Platform       : 7835I3

Processors        : 1

Type              : Intel(R) Xeon(R) CPU           E5504  @ 2.00GHz

CPU Speed         : 2000

Memory            : 4096 MBytes

Object ID         : 1.3.6.1.4.1.9.1.585

OS Version        : UCOS 5.0.0.0-2

My problem is that the web admin service fails every week or so requiring the Tomcat service to be restarted. At the time of writing 8.6(2)SU1 is the lates version available. Has anyone else seen this and what steps did you take to resolve it?

1 Accepted Solution

Accepted Solutions

Rob Huffman
Hall of Fame
Hall of Fame

Hi James,

Looks like it could be this bug;

CSCty36110 - CUCM 8.6 Tomcat OOM with "com.rsa.sslj.x.cu" suspect under high AXL Load

Description

Symptom:
Tomcat becomes  unreachable or inaccessible after a number of days.  So far the observed  timeframe tends to be between 7 and 20 days. 
If the generated hprof shows the main suspect as "com.rsa.sslj.x.cu" then this is most likely the cause.
Conditions:
This has been observed in environments where a very large number of AXL queries are done on the CUCM server.
Workaround:
Restart the Tomcat service on the CLI using "utils service restart Cisco Tomcat".
Prevent  the external application from performing AXL queries. This is usually  not a feasible workaround as AXL queries are a requirement for basic  functionality of some applications.

Details

First Found in:                          (6)

8.6(2),8.6(1.10000.43)

8.6(2.10000.30),9.0(0.99111.3)

More

Status:

Fixed

Last Modified:

Jun 08,2012

Fixed in:                          (13)

9.0(1.98000.1),9.0(1.10000.6),9.0(1.10000.2)

9.0(0.99091.6),9.0(0.99091.2),9.0(0.98000.93)

9.0(0.98000.52),9.0(0.98000.47),9.0(0.98000.25)

9.0(0.98000.186),8.6(3.98000.206),8.6(2.22028.1)

1.9(9.98000.16)

Less

Product:

Cisco Unified Communications Manager (CallManager)

Platform:

Dependent

Severity:

2 - severe

Cheers!

Rob

"Show a little faith, there's magic in the night" - Springsteen

View solution in original post

8 Replies 8

Aaron Harrison
VIP Alumni
VIP Alumni

Hi James

I've not seen the issue on that specific version but this is like the common cold for CallManagers. It seems to crop up every few releases and the resolution so far has always been an upgrade.

If there is no 'fixed' version then you'll probably want to raise a tac case as there's usually little you can do due to the appliance model.

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

Rob Huffman
Hall of Fame
Hall of Fame

Hi James,

Looks like it could be this bug;

CSCty36110 - CUCM 8.6 Tomcat OOM with "com.rsa.sslj.x.cu" suspect under high AXL Load

Description

Symptom:
Tomcat becomes  unreachable or inaccessible after a number of days.  So far the observed  timeframe tends to be between 7 and 20 days. 
If the generated hprof shows the main suspect as "com.rsa.sslj.x.cu" then this is most likely the cause.
Conditions:
This has been observed in environments where a very large number of AXL queries are done on the CUCM server.
Workaround:
Restart the Tomcat service on the CLI using "utils service restart Cisco Tomcat".
Prevent  the external application from performing AXL queries. This is usually  not a feasible workaround as AXL queries are a requirement for basic  functionality of some applications.

Details

First Found in:                          (6)

8.6(2),8.6(1.10000.43)

8.6(2.10000.30),9.0(0.99111.3)

More

Status:

Fixed

Last Modified:

Jun 08,2012

Fixed in:                          (13)

9.0(1.98000.1),9.0(1.10000.6),9.0(1.10000.2)

9.0(0.99091.6),9.0(0.99091.2),9.0(0.98000.93)

9.0(0.98000.52),9.0(0.98000.47),9.0(0.98000.25)

9.0(0.98000.186),8.6(3.98000.206),8.6(2.22028.1)

1.9(9.98000.16)

Less

Product:

Cisco Unified Communications Manager (CallManager)

Platform:

Dependent

Severity:

2 - severe

Cheers!

Rob

"Show a little faith, there's magic in the night" - Springsteen

Thanks Guys,

I think that it is the bug that Rob has detailed. This cluster has five servers so I am a bit reluctant to install the

8.6(2.22028.1) Engineering Special just to fix this.

Until a mainstream 8.6 fix is released I think I will set up a script to restart the Tomcat service daily - I know that I can do this by running Plink (party of the Putty suite) as a scheduled task under Windows unless anyone can suggest a more elegant solution?

Rob Huffman
Hall of Fame
Hall of Fame

Hi James,

That sounds like a pretty good work-around to me my friend I know that

clients don't want to upgrade to every ES that comes down the path, so if that's the

only issue you are encountering then waiting for a full release seems reasonable to me.

Cheers!

Rob

"Show a little faith, there's magic in the night" - Springsteen

Has anyone else had trouble installing the 8.6.2.22028-1 ES?  I just tried it tonight for a client and the checksum part of the install fails and it aborts, however the MD5 on the file matches what the special download is on cisco page which the TAC engineer said was correct. MD5 for the ISO was

a3d8ae63624df3bc642c86fbc3ca0253.

I tried upgrade with DVD and via FTP and both failed.

Waiting on TAC now, maybe I just got a bad file since it sounds like others did this update fine.

I wish they would post a SU1a or SU2 now with the fix as regular download since this can be a pain for some installs.

Ruud van Strijp
Level 1
Level 1

Hi,

According to http://www.cisco.com/web/software/282074295/93949/cucm-readme-862asu2.pdf this bug should be resolved in 8.6(2a) SU2. Is that right? Does anyone have experience with this bugfix?

Regards,

Ruud van Strijp

Hi Ruud,

Yes, that is the "fixed-in" 8.6(2) version that is available for download

8.6(2a)su2  US Export Restricted - full encryption capabilities (non-bootable) -  For upgrade from 8.x+. Upgrades from 6.1(4)+, 7.1(3), 7.1(5) need to be  requested via PUT (www.cisco.com/upgrade) or purchased to obtain  necessary license

UCSInstall_UCOS_8.6.2.22900-9.sgn.iso

CSCty36110 - CUCM 8.6 Tomcat OOM with "com.rsa.sslj.x.cu" suspect under high AXL Load

Fixed in:                          (17)

9.0(1.98000.1),9.0(1.10000.6),9.0(1.10000.37)

9.0(1.10000.2),9.0(1.10000.15),9.0(0.99091.6)

9.0(0.99091.2),9.0(0.98000.93),9.0(0.98000.52)

9.0(0.98000.47),9.0(0.98000.25),9.0(0.98000.186)

8.6(4.10000.15),8.6(3.98000.206),8.6(2.22900.9)

8.6(2.22028.1),1.9(9.98000.16)

Cheers!

Rob

"May your heart always be joyful
May your song always be sung" - Bob Dylan

Hello Everyone,

I hope You are doing well, may be this will help, I'm trying to hit the bug on the currently installed 8.6.1.20000-1 before proceeding with the upgrade to the 8.6.2.22900-9 as a Proof of concept for our customer, we have tens of servers to Upgrade in 4 clusters, so it's a long way to go, I'm trying to ask Cisco TAC to help me to regenerate the issue on the LAB we created specially for it, if You would like, I can tell You the results of the LAB results. (it would be nice if You have any ideas or scenarios to try to regenerate the issue, I'm trying to perform excessive AXL communications with 2000 users between a CUCM and a Cisco Unity Connection)

We have another customer who faced the same issue and it was resolved with the 8.6.2.22900-9.

Thanks and Best Regards,

Muhammad