Pipeline Crash During CDR Processing Of Accounts Having Line Transfer Service
(Doc ID 1442862.1)
Last updated on MARCH 11, 2019
Applies to:
Oracle Communications Billing and Revenue Management - Version 7.4.0.0.0 to 7.4.0.0.0 [Release 7.4.0]Information in this document applies to any platform.
Symptoms
Pipeline is crashing during CDR processing of accounts having line transfer service.
Stack Trace:
----------------- lwp# 121 / thread# 121 --------------------
ffffffff783db6cc waitid (0, 320a, ffffffff40ffda60, 3)
ffffffff783ca178 waitpid (320a, ffffffff40ffdce0, 0, 0, ffffffff6e36d480, 0) + 64
ffffffff783bd07c system (ffffffff40ffde80, 1ad8, 1800, 0, ffffffff7853e000, ffffffff40ffdd48) + 394
ffffffff7edf1ef8 printExceptionReport (2, 21141265d0, ffffffff7ef8c288, ffffffff7ef54d70, b, ffffffffef8c2a8) + 1f0
ffffffff7edf201c printStackTrace (b, 10052cb68, ffffffff40ffe498, 162dbc, 21141265d0, ffffffff7ef8c2a8) + 6c
ffffffff7d6ed294 bool OMF::DiagnosticDataHandler::getDiagnosticData(const BAS::String&,const BAS::String&,bool,int)(100364950, ffffffff7d83f238, ffffffff40ffe588, 1, b, ffffffff7d8251a0) + 124 ffffffff7d6ed9d8 int OMF::DiagnosticDataHandler::handle_signal(int,siginfo*,ucontext*) (100364950, b, c00, 137804, 0, ffffffff7d8251a0) + 40 ffffffff7d6e9324 int OMF::SignalHandler::handle_signal(int,siginfo*,ucontext*) (100335cd0, b, ffffffff40ffee60, ffffffff40ffeb80, fffffff7d83f2d8, ffffffff40ffe658) + b4 ffffffff7f1fb72c void ACE_Sig_Handler::dispatch(int,siginfo*,ucontext*) (b, ffffffff40ffee60,ffffffff40ffeb80, 4000, ffffffff7f3e74d0, 100335d78) + 74 ffffffff7f1faebc ace_sig_handler_dispatch (b, ffffffff40ffee60,ffffffff40ffeb80, ffffffff7854eba0, 1b0c46000, 0) + cffffffff783d7498 __sighndlr (b, ffffffff40ffee60, ffffffff40ffeb80,ffffffff7f1faeb0, 0, a) + cffffffff783cb02c call_user_handler (ffffffff6690b440, ffffffff6690b440, ffffffff40ffeb80, 8, 0, 0)
+ 3e0 ffffffff783cb238 sigacthandler (0, ffffffff40ffee60, ffffffff40ffeb80, ffffffff6690b440, 0, ffffffff7853e000) + 68 --- called from signal handler with signal 0 (SIGEXIT) ---ffffffff70dc3758 bool BAS::KeyedObjectPoolObject<RWMutexLock>::removeReference() (0, ffffffff40fff428, ffffffff40fff0d0, ffffffff71554ce8
ffffffff783db6cc waitid (0, 320a, ffffffff40ffda60, 3)
ffffffff783ca178 waitpid (320a, ffffffff40ffdce0, 0, 0, ffffffff6e36d480, 0) + 64
ffffffff783bd07c system (ffffffff40ffde80, 1ad8, 1800, 0, ffffffff7853e000, ffffffff40ffdd48) + 394
ffffffff7edf1ef8 printExceptionReport (2, 21141265d0, ffffffff7ef8c288, ffffffff7ef54d70, b, ffffffffef8c2a8) + 1f0
ffffffff7edf201c printStackTrace (b, 10052cb68, ffffffff40ffe498, 162dbc, 21141265d0, ffffffff7ef8c2a8) + 6c
ffffffff7d6ed294 bool OMF::DiagnosticDataHandler::getDiagnosticData(const BAS::String&,const BAS::String&,bool,int)(100364950, ffffffff7d83f238, ffffffff40ffe588, 1, b, ffffffff7d8251a0) + 124 ffffffff7d6ed9d8 int OMF::DiagnosticDataHandler::handle_signal(int,siginfo*,ucontext*) (100364950, b, c00, 137804, 0, ffffffff7d8251a0) + 40 ffffffff7d6e9324 int OMF::SignalHandler::handle_signal(int,siginfo*,ucontext*) (100335cd0, b, ffffffff40ffee60, ffffffff40ffeb80, fffffff7d83f2d8, ffffffff40ffe658) + b4 ffffffff7f1fb72c void ACE_Sig_Handler::dispatch(int,siginfo*,ucontext*) (b, ffffffff40ffee60,ffffffff40ffeb80, 4000, ffffffff7f3e74d0, 100335d78) + 74 ffffffff7f1faebc ace_sig_handler_dispatch (b, ffffffff40ffee60,ffffffff40ffeb80, ffffffff7854eba0, 1b0c46000, 0) + cffffffff783d7498 __sighndlr (b, ffffffff40ffee60, ffffffff40ffeb80,ffffffff7f1faeb0, 0, a) + cffffffff783cb02c call_user_handler (ffffffff6690b440, ffffffff6690b440, ffffffff40ffeb80, 8, 0, 0)
+ 3e0 ffffffff783cb238 sigacthandler (0, ffffffff40ffee60, ffffffff40ffeb80, ffffffff6690b440, 0, ffffffff7853e000) + 68 --- called from signal handler with signal 0 (SIGEXIT) ---ffffffff70dc3758 bool BAS::KeyedObjectPoolObject<RWMutexLock>::removeReference() (0, ffffffff40fff428, ffffffff40fff0d0, ffffffff71554ce8
Reproduction Steps:-
1) Create account A1 with GSM/telephony service on 1st April 2012.
This is with separate Balance groups for Service and account.
2) Create another account A2 without GSM/telephony service on 5th April.
3) Use Line transfer opcode to transfer Service S1 created in step 1 from account A1 to account A2 on 6th April.
Execute PCM_OP_SUBSCRIPTION_TRANSFER_SUBSCRIPTION through testnap:
4) Rate CDRs of Service S1 on 14th April
-> Pipeline is crashing
This is with separate Balance groups for Service and account.
2) Create another account A2 without GSM/telephony service on 5th April.
3) Use Line transfer opcode to transfer Service S1 created in step 1 from account A1 to account A2 on 6th April.
Execute PCM_OP_SUBSCRIPTION_TRANSFER_SUBSCRIPTION through testnap:
0 PIN_FLD_POID POID [0] 0.0.0.1 /service/telco/gsm/telephony 8303845 0
0 PIN_FLD_BILLINFO ARRAY [0] allocated 7, used 7
1 PIN_FLD_POID POID [0] 0.0.0.1 /billinfo -1 0
1 PIN_FLD_BILLINFO_ID STR [0] "Bill Unit(2)"
1 PIN_FLD_CURRENCY_SECONDARY INT [0] 0
1 PIN_FLD_BILL_WHEN INT [0] 1
1 PIN_FLD_PAY_TYPE ENUM [0] 10001
1 PIN_FLD_PAYINFO_OBJ POID [0] 0.0.0.1 /payinfo/invoice 8308217 0
1 PIN_FLD_CURRENCY INT [0] 978
0 PIN_FLD_TO_OBJ POID [0] 0.0.0.1 /account 8307193 0
0 PIN_FLD_FROM_OBJ POID [0] 0.0.0.1 /account 8303717 0
0 PIN_FLD_PROGRAM_NAME STR [0] "testnap"
4) Rate CDRs of Service S1 on 14th April
-> Pipeline is crashing
Changes
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
| Symptoms |
| Changes |
| Cause |
| Solution |
| References |