Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

onDialogTimeout is unconditionally sending http response #83

Open
jaimecasero opened this issue Sep 12, 2016 · 9 comments
Open

onDialogTimeout is unconditionally sending http response #83

jaimecasero opened this issue Sep 12, 2016 · 9 comments
Assignees
Labels

Comments

@jaimecasero
Copy link
Contributor

jaimecasero commented Sep 12, 2016

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!!!

@FerUy FerUy added this to the 1.0.0 milestone Sep 12, 2016
@FerUy FerUy self-assigned this Sep 12, 2016
@jaimecasero
Copy link
Contributor Author

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

@FerUy FerUy modified the milestones: 2.0.0, 1.0.0 Sep 14, 2016
@vetss
Copy link
Contributor

vetss commented Sep 19, 2016

@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
Copy link
Contributor Author

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
Copy link
Collaborator

Vanit commented Oct 6, 2016

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
Copy link
Contributor

vetss commented Oct 6, 2016

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
Copy link
Contributor

FerUy commented Oct 6, 2016

@monix would you like to take care of this?

@Vanit
Copy link
Collaborator

Vanit commented Oct 6, 2016

@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
Copy link
Contributor

FerUy commented Oct 6, 2016

No worries @monix, thanks for your comment!

@Vanit
Copy link
Collaborator

Vanit commented Oct 6, 2016

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants