Last updated on MARCH 27, 2015
Applies to:Oracle Communications Network Charging and Control - Version: 2.4.0
Oracle Communications Network Charging and Control - Version: 2.2.0 to 3.1.0 [Release: 2.2 to 3.1.0]
Information in this document applies to any platform.
#0 cmn::escher::MapImpl::isAnyDirty (pickle=0x2f0770, offset=212) at
#1 0xfef87e3c in cmn::escher::MapImpl::isAnyDirty (pickle=0x0, offset=0) at
The backtrace is indeed mentioning a problem in the interpretation of an escher message.
ESCHER is the name given to the message format used by the VWS (Voucher and Wallet Server) for communication with other entities.
Another symptom is that as this process core dumps, upon core dumping, the different beClient processes on the Service Logic Controller and the Service Management System (PIBeClient) log an error message about a lost connection to the Voucher And Wallet Server (beServer in our case) :
Apr 9 15:55:06.616910 BeClient(20272) ERROR: Connection to BE 41:10.2.3.4-1500 has failed.
And reconnects a few after :
Apr 9 15:55:16.632202 BeClient(20272) NOTICE: Connection to BE 41:10.2.3.4-1500 is established.
This is due to the beServer core dumping.
The beServer is the process handling the requests (in the form of Escher messages) towards the VWS, and as it is core dumping it is not handling any requests anymore. After a few, it is restarted by the watchdog and starts handling requests again (see the notice message above).
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms