[
https://issues.apache.org/jira/browse/TINKERPOP-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187989#comment-17187989
]
ASF GitHub Bot commented on TINKERPOP-2410:
-------------------------------------------
spmallette commented on pull request #1318:
URL: https://github.com/apache/tinkerpop/pull/1318#issuecomment-684011732
Getting a failing test:
```
[ERROR] Failures:
[ERROR]
GremlinServerSessionIntegrateTest.shouldBlockAdditionalRequestsDuringClose:209
Expected: a collection containing "INFO - Rolling back open transactions on
graph before killing session: shouldBlockAdditionalRequestsDuringClose\n"
but: was "WARN - Timeout while trying to close connection on
shouldBlockAdditionalRequestsDuringClose - force closing - server will close
session on shutdown or expiration.\n"
[INFO]
[ERROR] Tests run: 270, Failures: 1, Errors: 0, Skipped: 1
```
I think you just need to rebase since you fixed this on 3.4-dev right?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Free up server threads when client is closed
> --------------------------------------------
>
> Key: TINKERPOP-2410
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2410
> Project: TinkerPop
> Issue Type: Bug
> Components: server
> Affects Versions: 3.4.8
> Reporter: Divij Vaidya
> Priority: Minor
>
> Consider a situation where the server has sent some results back to the
> client and is waiting for Netty channel to be writable again before sending
> rest of the results. Let's assume that the client dies (or is closed) at this
> instant without consuming the entire set of results.
> In this case, the server threads will continue to wait for the channel to
> become writable (which it never will since client is dead) until the timeout
> is hit.
> We need to change the behaviour such that the waiting thread loop breaks if
> the channel becomes inactive. Such loop exists at TraversalOpProcessor (for
> bytecode execution) and AbstractOpProcessor(for string execution) in the
> server.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
