[
https://issues.apache.org/jira/browse/JENA-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172641#comment-13172641
]
Andy Seaborne commented on JENA-181:
------------------------------------
A patch would be great - for all input forms, once the logical end is seen,
then the code can and should .close().
Even for a stream passed in to be read, the state of the stream is undefined
after the parser code has done it's stuff (read ahead buffering if nothing
else). I guess that keeping the HTTP/TCP connection delays recycling resources
in the Jetty server.
> Fuseki starts producing 500 errors if rapidly sent a sequence of queries
> ------------------------------------------------------------------------
>
> Key: JENA-181
> URL: https://issues.apache.org/jira/browse/JENA-181
> Project: Jena
> Issue Type: Bug
> Components: Fuseki
> Affects Versions: Fuseki 0.2.1
> Environment: Mac OS X Lion
> Reporter: Rob Vesse
> Attachments: FusekiDOSAttack.java
>
>
> It is fairly trivial to cause Fuseki to start generating a 500 : Direct
> buffer memory error code in response to queries simply by sending a sequence
> of queries to it with no delays between them, even with a short delay e.g.
> 0.5 seconds Fuseki will typically get into this state at a similar point.
> Attached is a simple test case which fires SELECT * WHERE { } queries at a
> local Fuseki instance, for me this reliably fails on the 25th iteration,
> turning on --debug and --verbose for Fuseki and modifying the
> log4j.properties file to set DEBUG level for everything didn't show anything
> particularly useful on the command line so I have no idea what the cause of
> this may be beyond something related to java.nio.HeapByteBuffer
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
