[
https://issues.apache.org/jira/browse/JENA-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172442#comment-13172442
]
Rob Vesse commented on JENA-181:
--------------------------------
Just to add a bit of mystery to this - running the same code with an
ASK/CONSTRUCT/DESCRIBE query will not hit this problem, so this must be a bug
somewhere in the code related to SELECT queries (or at least in the code that
serializes SPARQL Result Sets)
> 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
