Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 75 by
flavioba...@gmail.com: Multithread implementation
https://code.google.com/p/jdiameter/issues/detail?id=75
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"
Attachments:
new 6.txt 9.4 KB
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings