Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Diameter Ro RA - race when creating DiameterActivity #31

Open
duyanh030 opened this issue Oct 12, 2017 · 1 comment
Open

Diameter Ro RA - race when creating DiameterActivity #31

duyanh030 opened this issue Oct 12, 2017 · 1 comment

Comments

@duyanh030
Copy link

Exception bt
2017-09-06 14:13:27,281 ERROR [javax.slee.RAEntityNotification[entity=DiameterRo].DiameterRoResourceAdaptor] [ApplicationSession-1] [TracerImpl::severe::412] Error firing event.
java.lang.IllegalStateException: No activity for handle: Diameter Session ID[localhost;350;1460764936]
at org.mobicents.slee.resource.diameter.ro.DiameterRoResourceAdaptor.fireEvent(DiameterRoResourceAdaptor.java:608)
at org.mobicents.slee.resource.diameter.ro.DiameterRoResourceAdaptor.fireEvent(DiameterRoResourceAdaptor.java:635)
at org.mobicents.slee.resource.diameter.ro.handlers.RoSessionFactory.doCreditControlAnswer(RoSessionFactory.java:64)
at org.jdiameter.client.impl.app.ro.ClientRoSessionImpl.deliverRoAnswer(ClientRoSessionImpl.java:1158)
at org.jdiameter.client.impl.app.ro.ClientRoSessionImpl.handleEventForSessionBased(ClientRoSessionImpl.java:344)
at org.jdiameter.client.impl.app.ro.ClientRoSessionImpl.handleEvent(ClientRoSessionImpl.java:196)
at org.jdiameter.client.impl.app.ro.ClientRoSessionImpl$AnswerDelivery.run(ClientRoSessionImpl.java:1340)
at org.jdiameter.common.impl.concurrent.DefaultRunnable.run(DefaultRunnable.java:47)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

How to reproduce issue.

// -------------------------------------------------------------------------------------
Step by step operations (relevant) flow

  1. SBB: Create client activity [RoClientSessionActivity session = roProvider.createRoClientSessionActivity();]
  2. SBB: Create aci
  3. SBB: attach sbbLocalObject to aci
  4. Create CCR-I object [ RoCreditControlRequest creditControlRequest = session.createRoCreditControlRequest(ccRequestType);]
  5. Send CCR-I to OCS: [session.sendInitialRoCreditControlRequest(creditControlRequestHw);]
  6. Some loging and data persisting operations (make this step time consuming to reproduce issue)
  7. OCS responds before step 6) ends.
  8. RA receives CCA and attempts to fire it
    8.1) activieties.getActivity(ActivityHandle) fails, stacktrace in attached log
  9. SBB finishes operations, SLEE Transaction commits

// -------------------------------------------------------------------------------------

Analisys:
The creation of ACH in jboss cache with suspending and resumming the transaction. But the creation of Activity is put in transaction (without suspend and resume). The result is ACH is in cache immediately while Activity wait until the transaction is committed. If the CCR response come back quickly, Then we have another thread will trying to fetch the information of ACH and activity in jboss cache. At this time we have no Activity because the transaction is not comited in thread 1.

duyanh030 pushed a commit to duyanh030/jain-slee.diameter that referenced this issue Oct 12, 2017
 - Don't store and get activity as a transaction
@mwarpechowski
Copy link

If I may join discussion I would like to ask:
"What will happen if there will be transaction rollback after activity creation?"

My first impression is that ACH may still persist in jboss cache after transaction invalidation (because it was added outside transaction). This may cause memory leak.
Have you addressed this topic?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants