transaction not removed in gov.nist.javax.sip.stack.SIPTransactionStack.findTransaction

[laurent]

Hello all,

after many calls I see that mobicents is no more processing SIP INVITE
request or processing them with many time and create a timeout .

in mobicents log (Debug level) I have no info so I enable debug of
the NIST sip stack.

to test, I have started diffents instance of pjsua that do diffrents
calls. (succesfull call of diffrents time, canceled calls, ...)

before that the problem hapends, I have terminated all calls , then I
have waited about 20 minutes and send only 1 calls to see log of SIP
stack.

in this log as you can see, the stack calls the method findTransaction
and this method do a comaparaison with many transaction, the problem
is that is this state it must not have any more transaction in
memory !

http://pastebin.com/m5e6ff1b4

any idea why transaction are not removed ?

Laurent

[laurent]

Hello all,

I think that I have found the problem, I was not sending correctly
back the "487 Request Terminated." to the initial Invite after a
Cancel.

Regards

Laurent

[Bartosz Baranowski]

Hi
iirc it still should clean memory, will look once I get some time for jsip.
Thanks for pointing us here.

--
Bartosz Baranowski
JBoss R & D
==================================
Word of criticism meant to improve is always step forward.

[laurent]

Hi,

I just do more check and I see an other case where the same hapends.

I start a call and the called party send back an reinvite that I
resend to the caller.

the caller only send me a 100 trying and then stop the call, so I
never answer correctly to the reInvite of the called party and I see
that this transaction is never removed fro the list.

so I think that, if for any reason we don't send any answer (200 OK or
any error) to a Invite request, the transaction is not removed from
the list.

Laurent

> Word of criticism meant to improve is always step forward.- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -

[laurent]

hello,


I see that problem, the params MAX_LISTENER_RESPONSE_TIME is not
defined so transaction are never removed from the stack.


* <li><b>gov.nist.javax.sip.MAX_LISTENER_RESPONSE_TIME = Integer </b>
<br/>Max time (seconds)
* before sending a response to a server transaction. If a response is
not sent within this time
* period, the transaction will be deleted by the stack. Default time
is "infinity" - i.e. if the
* listener never responds, the stack will hang on to a reference for
the transaction and result
* in a memory leak.

> > - Afficher le texte des messages précédents -- Masquer le texte des messages précédents -

[laurent]

Hi,

so now with MAX_LISTENER_RESPONSE_TIME set, runTask() of
ListenerExecutionMaxTimer is executed.

the problem is that he never go in the " if
(serverTransaction.getState() == null) " , getSate() is not null, for
the cancel request state is: "Terminated Transaction" and for the
invite transaction state is: "Proceeding Transaction".



/**
* This timer task will terminate the transaction if the listener
does not respond in a
* pre-determined time period. This helps prevent buggy listeners
(who fail to respond) from
* causing memory leaks. This allows a container to protect itself
from buggy code ( that
* fails to respond to a server transaction).
*
*/
class ListenerExecutionMaxTimer extends SIPStackTimerTask {
SIPServerTransaction serverTransaction =
SIPServerTransaction.this;

ListenerExecutionMaxTimer() {

sipStack.logWriter.logDebug(" create
ListenerExecutionMaxTimer() " + getTransactionId());
}

protected void runTask() {
sipStack.logWriter.logDebug(" TransactionTimer()
runTask ListenerExecutionMaxTimer() : " + getTransactionId() + "
state:" + serverTransaction.getState() );
try {
if (serverTransaction.getState() == null) {
sipStack.logWriter.logDebug(" in if " +
getTransactionId());
serverTransaction.terminate();
SIPTransactionStack sipStack =
serverTransaction.getSIPStack();
sipStack.removePendingTransaction
(serverTransaction);
sipStack.removeTransaction(serverTransaction);

}
} catch (Exception ex) {
sipStack.getLogWriter().logError("unexpected
exception", ex);

[laurent]

hello,

did you found time to check this case ?

Laurent

> > On 6 juil, 10:46,laurent<laurent.schwei...@gmail.com> wrote:
>
> > > Hi,
>
> > > I just do more check and I see an other case where the same hapends.
>
> > > I start a call and the called party send back an reinvite that I
> > > resend to the caller.
>
> > > the caller only send me a 100 trying and then stop the call, so I
> > > never answer correctly to the reInvite of the called party and I see
> > > that this transaction is never removed fro the list.
>
> > > so I think that, if for any reason we don't send any answer (200 OK or
> > > any error) to a Invite request, the transaction is not removed from
> > > the list.
>
> > >Laurent
>
> > > On 6 juil, 10:22, Bartosz Baranowski <baran...@gmail.com> wrote:
>
> > > > Hi
> > > > iirc it still should clean memory, will look once I get some time for jsip.
> > > > Thanks for pointing us here.
>

> > > > On Mon, Jul 6, 2009 at 2:28 AM,laurent<laurent.schwei...@gmail.com> wrote:
>
> > > > > Hello all,
>
> > > > > I think that I have found the problem, I was not sending  correctly
> > > > > back the "487 Request Terminated." to the initial Invite after a
> > > > > Cancel.
>
> > > > > Regards
>
> > > > >Laurent
>

[Bartosz Baranowski]

Actually I ran against sip b2b scenario and it works ok, tx linger a bit there but are removed at some point, number decreeses.
Regarding that timer - its intended to remove txs that has not been answeed in any way, INVITE has 100 timer, which sends 100 if lisnter does not, thus its "answered" I think.

So I think error is in full matching tx? Can You send sipp/app that will show this problem?

[laurent]

Hello,

I have just terminated some change to remove DB dependency ,
Can I send you my application directly to your email ?

just you told me that don't see any problem with your test. But as I
explain before this is not hapening in every scenario.
If I just start and connect call I don't have any propblem, I see this
problem with Canceled calls.

Regards

Laurent

On 29 juil, 15:50, Bartosz Baranowski <baran...@gmail.com> wrote:
> Actually I ran against sip b2b scenario and it works ok, tx linger a bit
> there but are removed at some point, number decreeses.
> Regarding that timer - its intended to remove txs that has not been answeed
> in any way, INVITE has 100 timer, which sends 100 if lisnter does not, thus
> its "answered" I think.
>
> So I think error is in full matching tx? Can You send sipp/app that will
> show this problem?
>

[Bartosz Baranowski]

You can send it. I will try to give it a look, though right now we are all a bit bussy.