[
https://issues.apache.org/jira/browse/JENA-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174020#comment-13174020
]
Andy Seaborne commented on JENA-181:
------------------------------------
Checking the Jetty source code, it looks like closing the implementation of
ServletOutputStream is not going to affect any HTTP connection resources like
direct memory in any way. .close() flushes the stream and sets a flag, nothing
else.
package org.eclipse.jetty.server
HttpConnection$Output extends HttpOutput
> 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
