search

RestComm / gmlc

Restcomm Location Server
http://www.restcomm.com/
GNU Affero General Public License v3.0
17 stars 40 forks source link

Dialog is never released #84

Closed jaimecasero closed 7 years ago

jaimecasero commented 7 years ago

https://github.com/RestComm/gmlc/blob/master/core/slee/services/sbbs/src/main/java/org/mobicents/gmlc/slee/MobileCoreNetworkInterfaceSbb.java#L330

after receiveng map response we should close dialog, by invoking dialog.release.

This will prevent to receive the dialogtimeout event, and free resources much previouslly

FerUy commented 7 years ago

@jaimecasero just added the dialog release. Let's see how it impacts the automated performance test before resolving #83.

FerUy commented 7 years ago

Consistently with GMLC-Performance-GetLoc/78, this is closed

vetss commented 7 years ago

@jaimecasero @FerUy

You do not need to add "close() / release()" staff to onAnyTimeInterrogationResponse() because a dialog is closed / released by a peer (a peer is sending TC-END message that just close / release this dialog)

The most probaly reason of "dialogtimeout event" - if you have too high message load then SCTP channel can not pass all load, then messages came to a peer with delays and when this delay increase invoke / dialog timeout margine then you can see many dialog timeout event in logs. Try to decrease a message load level.

FerUy commented 7 years ago

@vetss thanks! You're right, working on it

FerUy commented 7 years ago

Now MAP ATI is working as it expected (TC-BEG for request, TC-END for response) and dialog properly released. Local tests between posterior build 1.0.65 and MAP server stub are also OK as for the attached trace. MAP serverStub log looks fine in this regard as for http://ci.telestax.com/job/GMLC-Performance-GetLoc/85/artifact/results/serverStub.log (i.e. there are no more dialog timeouts, dialogs are released for each MAP ATI request for the whole test).

FerUy commented 7 years ago

Just for the record, http://ci.telestax.com/job/GMLC-Performance-GetLoc/90/ confirms this issue was properly closed as for it concern.