xinbc / jdiameter

Automatically exported from code.google.com/p/jdiameter
0 stars 0 forks source link

RouterImpl very bad reacting on burst load #68

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Problem:
If load increases very fast, but not on long time, then I expect that all 
requests will be correct handled and all answers will sent. Just some answers 
will be precessing longer than usually.

But actually in this case:
1. Size of requestEntryMap very fast becomes greater than 
REQUEST_TABLE_CLEAR_SIZE and REQUEST_TABLE_SIZE.
2. First thread goes to sleep on 5 second.
3. All following requests fail with timeout (because threads wait on 
requestEntryTableLock). But I actually expect that server will sent response 
with error result code (for example, 3004 DIAMETER_TOO_BUSY).
4. The worst moment, thread from point 2 wake up and call 
requestEntryMap.clear(). And all answers for all last requests cannot will be 
sent.

After that, all requests fail with timeout and I lost very big part of traffic.

Probably solution:
In my fork of JDiameter, I just:
1. Full remove requestEntryMap variable (method registerRequestRouteInfo now 
empty).
2. In method getRequestRouteInfo I return DESTINATION_HOST and 
DESTINATION_REALM Avp value.
3. While create Answer, set this Avp from ORIGIN_* in Request.

I know that this Avp marked as MUST NOT in specification, but Diameter client, 
which works with my server, ignoring this error.

Maybe, may apply my solution with small fix: remove DESTINATION_HOST and 
DESTINATION_REALM Avp from answer before send but after getting RouteInfo. 
Another solution is save route info data not in requestEntryMap but attach some 
object for Message.

Original issue reported on code.google.com by grinch...@gmail.com on 20 Nov 2014 at 2:11