What steps will reproduce the problem?
1. Configure a simple jdiameter connection
2. Do not use this connection
What is the expected output? What do you see instead?
Connection switches from OKAY to SUSPECT randomly
What version of the product are you using? On what operating system?
1.6 FINAL
Please provide any additional information below.
I was experiencing some problems in a LAB environment with some random
disconnections. Obviously there were no connection problems.
Using debug logs and looking at source code I discovered the use of multiple
threads and a queue to process incoming messages.
Looking at the attached log, FSM switches to SUSPECT state.
According to source code this should occur when watchdogSent==true and a new
DWR message is being sent.
But according to logs this should never occur because when a DWA is received
watchdogSent is set to false.
This behavior is related to multithreading implementation. Variable
watchdogSent is not volatile and threads see different values:
FSM-aaa://peer.example.com:3868_3-2 -> watchdogSent = false;
FSM-aaa://peer.example.com:3868_2-1 -> if (watchdogSent)
switchToNextState(FsmState.SUSPECT);
it seems however that this is not the only problem. Each thread process a
message from a single queue, this could change the order of messages processing
depending on the load of each task. See
https://code.google.com/p/jdiameter/issues/detail?id=69
For now the only workaround i have found is to disable multithreading
implementation using the undocumented PeerFSMThreadCount parameter in xml
configuration with value="1"
Original issue reported on code.google.com by flavioba...@gmail.com on 3 Jun 2015 at 8:32
Original issue reported on code.google.com by
flavioba...@gmail.comon 3 Jun 2015 at 8:32Attachments: