Summary: | Cannot obtain idempotent information from Session in onError method after session closed | ||
---|---|---|---|
Product: | Tomcat 8 | Reporter: | Nick Williams <nicholas> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED WONTFIX | ||
Severity: | major | ||
Priority: | P2 | ||
Version: | 8.0.x-trunk | ||
Target Milestone: | ---- | ||
Hardware: | All | ||
OS: | All |
Description
Nick Williams
2013-03-24 01:37:16 UTC
More information here: http://java.net/jira/browse/WEBSOCKET_SPEC-174 That is error handling rather than a normal close. If you are going to try and access the session from an error handler you need to take account of the fact that the container may already have closed the connection in response to the error or, equally, that the error could be that the connection was dropped by the client / network / take your pick. I understand your point that this happens in onError and not onClose (my bad for mis-reporting), but I think that highlights a problem with the spec. I have commented on http://java.net/jira/browse/WEBSOCKET_SPEC-174 to request further clarification, and request that this Bugzilla remain open until the spec issue is further clarified. The final WebSocket spec is very clear on the required behaviour and this is what Tomcat implements. I've looked through the code and the only time I can find where Endpoint.onError() is called after the session has been closed is if for the following sequence of events: - Server receives close message - server fires session.onClose() - session is marked as closed - server echos close message back to the client - the sending of that message fails This is easily detected via the onOpen() method of the session and isn't - given that as far as the app is concerned it was a normal shutdown - something I am too concerned about. It could be argued that it would be reasonable in this case to just swallow the error. It would be useful to get some clarity on this from the EG but I don't see it as a bug issue. I also took a look at how things like network errors are handled. In that case onClose() is triggered with a suitable close code. If you have a test case (other than the one above) that demonstrates onClose() being called before onError() I'd be happy to take look. Just re-open this and provide some steps to reproduce. |