search

RestComm / gmlc

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

onDialogTimeout is unconditionally sending http response #83

Open jaimecasero opened 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#L228

this logic should check if an http response was already sent!!!

jaimecasero commented 7 years ago

potentially reuse http://docs.oracle.com/javaee/6/api/javax/servlet/ServletResponse.html#isCommitted() so no new flag is required

vetss commented 7 years ago

@jaimecasero

this logic should check if an http response was already sent!!!

I am trying to understand why "http response was already sent". DialogTimeout means that we have not received a resposne from SS7 network and therefore not generated any HTTP response. May it be that this response may be already generated by HTTP RA because of it's timeout for example ?

jaimecasero commented 7 years ago

well we were chcecking tracing from SBB that showed DialogTimeout was creating the "additional" response. Anyway, it may be worth investigating the SS7 beahvior, so we may need to add traces to thsi ticket...

Vanit commented 7 years ago

I have seen this happen before if jss7 is not configured. The 503 it throws does infact conflict with the resulting dialogtimeout, but I wouldn't call this a bug.

vetss commented 7 years ago

JSS7 DialogTimout event comes in some delays like a minute. We may have DialogTimout events in case of SS7 stack is not properly configured (and therefore no response form a ss7 peer). So may it be HTTP request is already timed out at the time of JSS7 DialogTimout event is coming ?

FerUy commented 7 years ago

@Monix would you like to take care of this?

Vanit commented 7 years ago

@FerUy I've been reassigned to other projects at work so I won't have time to help out, sorry! Was just passing through and saw something I could comment on. :)

FerUy commented 7 years ago

No worries @Monix, thanks for your comment!

Vanit commented 7 years ago

@FerUy No problem, of course :) It's been a while since I looked at the code, but when I was investigating this the conflicting 503's were thrown from pretty deep in the jss7 stack. I suspect the bug is better placed in that repo, where it should be firing an appropriate dialog response back up to the GMLC instead of directly outputting its own 503 http response.