CCX Engine status shutdown

[pkolenichev]

Hi

in UCCX 8.5 Cisco Unified CCX Engine  is in shutdown status from CCX Serviceability. I added CM Telephony Call Control Group with 10 CTI ports. I can see CTI port in CUCM that are created, but their registration status keep state "unknown"

I am using UCCX 8.5.1.10000-37 and CUCM  8.6.2.20000-2.

Please for your suggestion what I am missing. I am attaching a MIVR log.

Thank you,

Petko

[anchoudh]

Hi,

Please run the Data resync operation from UCCX, to check any inconsistancies between UCCX and CUCM and see if that helps.

Meanwhile I will try to see the logs attached.

Thanks,

Anand

Please rate helpful posts !!

[pkolenichev]

Hi Anand,

I run Data Synchronization

everything is in sync:

Call Control Group(s)
0 - Unified CM Telephony Group #0
CTI Ports		In Sync

CM Telephony User(s)
User ID		cc__1 - In Sync
Device Association		In Sync

I restart Cisco Unified CCX Engine, but after 2 minutes all subsystems of CCX Engine went to shutdown state.

[anchoudh]

Hi,

If this is not in production, please try upgrading it to the latest SU on this version and check.

Thanks,

Anand

[2147RAFmil]

Hey All,

Did we ever get an answer for this, besides 'Upgrade'. I am finding it hard to swallow that Cisco would market these two together without them playing well together.

Freddie Mac

[pkolenichev]

Hi,

the problem turn out to be that our VMware was running on AMD processors. It should be Intel. Please note that those limitation is fixed with latest UCCX.

Best Regards,

Petko

[gdosa]

Hi Anand,

I'm running into the same problem and I have the latest release 9.0.2SU1 ( 9.0.2.11001-24). Only the CM Telephony Subsystem stays in OUT OF SERVICE and therefore none of my CTI ports or Route points register.

124: Jan 09 13:17:47.709 CET %MIVR-MGR_MGR-7-UNK:        com.cisco.channel.impl.ChannelManagerImpl.mgrmgrstate=OUT_OF_SERVICE

125: Jan 09 13:17:47.709 CET %MIVR-MGR_MGR-7-UNK:        com.cisco.session.deadlock.count=10

Any idea? I'll check the bug toolkit as I understand this might be a wel-known deadlock issue.

Thanks!