[
https://issues.apache.org/jira/browse/JENA-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13173963#comment-13173963
]
Andy Seaborne commented on JENA-181:
------------------------------------
I've looked at the Fuseki side. The code flushes the servlet output stream.
I'm unclear as to whether the server code should call .close() , or leave the
stream along, or if it makes no difference. Jetty is responsible for managing
the HTTP connection, sending the headers and then the body. It may then do
some connection caching.
> 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
> Assignee: Andy Seaborne
> 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
