[
https://issues.apache.org/jira/browse/TINKERPOP3-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP3-849.
---------------------------------------
Resolution: Implemented
I noticed this the other day (as a result of the issue you were noticing with
titan+berkeley) and was kinda surprised that this was another instance where we
didn't have a clean close of the session. Anyway, I've made some changes in
tp30/master to allow you to send a "close" op code with a request message that
uses the "session" processor. That "close" op will rollback any open
transactions. The "close" op code should still be followed by a websocket close
frame to client-side kill the websocket itself.
I thought about trying to allow one to embed the payload directly into the
close frame, but that some problems in that i wanted the subprotocol to be
protocol agnostic, so it should work with or without knowledge of websockets.
I kinda found a way around that which was workable, but then i hit problems
with the serialization model which expected all requests with payload to be
either text or binary framed and so if the close frame included a payload,
which serializer would it use?
In the end I just left it as having to send two separate frames to fully close.
In either case, I would expect the server to clean up if one message was sent
but not the other. There would just be some dangling resources hanging around
until that happened.
> gremlin-server doesn't close sessions on 'close' opcode
> -------------------------------------------------------
>
> Key: TINKERPOP3-849
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-849
> Project: TinkerPop 3
> Issue Type: Bug
> Components: server
> Affects Versions: 3.0.1-incubating
> Reporter: Dylan Millikin
> Assignee: stephen mallette
> Fix For: 3.1.0-incubating, 3.0.2-incubating
>
>
> When sending a packet with a {{close}} opcode ({{0x8}}). One would expect the
> server to terminate the socket and all sessions created through it.
> Currently this is not the case and this can be tested by doing the following:
> - Open websocket (handshake etc..)
> - Send a message with a session UUID (that we'll call {{x}}) and a script :
> {{cal = 5+5}}
> - Send a 'close' request and terminate the socket.
> - Open another websocket connection
> - Send a message with a session UUID of {{x}} and a script : {{cal}}
> This last event should generate an error ({{cal}} shouldn't be defined).
> Instead it continues by sending back {{10}} as if the session were still
> alive.
> -------------------------
> Alternatively:
> If there is no tracking of the sessions opened through a specific socket
> connection, then perhaps we can join the following payload to the 'close'
> packet:
> {code}
> { "requestId":"1d6d02bd-8e56-421d-9438-3bd6d0079ff1",
> "op":"eval",
> "processor":"session",
> "args":{"gremlin":"",
> "session":"x"}
> }
> {code}
> The server will know to terminate session {{x}} at this stage.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
