Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <12295831.1187394990526.JavaMail.jira@brutus>
Date: Fri, 17 Aug 2007 16:56:30 -0700 (PDT)
From: "Alex Karasulu (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Subject: [jira] Commented: (DIRSERVER-731) Streaming big objects
In-Reply-To: <28637746.1157609062394.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DIRSERVER-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520713 ] 

Alex Karasulu commented on DIRSERVER-731:
-----------------------------------------

I agree that this is the ultimate way to solve the issue however this might take considerable
time to implement.  Perhaps the best strategy for the moment is to create a special configuration
parameter for the twix decoder that limits the size of a TLV length to some value.  This would 
help prevent potential DoS attacks that flood the server with massive attributes which will 
eventually result in OutOfMemoryErrors.  Using a configurable parameter  
like a max TLV length limit parameter in theory could be easily implemented.  I was looking
at the code to see how this would be done but I must admit I was just confused by the code
which has gotten more complex than I can handle.  However the key to doing this may be in
the Asn1Decoder in the shared-asn1 (org.apache.directory.shared.asn1.ber package).  If it
could take this parameter and limit the length of the TLV by throwing a special exception for
this case then we would be able to prevent this kind of DoS attack.

Emmanuel if you can assess just how much effort this workaround would take then we can
decide whether or not we should implement it and create a separate issue for it.  Then we 
can just move this issue to be thoroughly handled in a 2.0 or 3.0 release where we have the
time to cleanup and redesign the codec with these advanced features in mind.  

How does this sound?
  

> Streaming big objects
> ---------------------
>
>                 Key: DIRSERVER-731
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-731
>             Project: Directory ApacheDS
>          Issue Type: Improvement
>            Reporter: Emmanuel Lecharny
>            Priority: Critical
>             Fix For: 1.5.1
>
>
> We really need to implement a streming of big objects, like JpegPhoto, otherwise the server can be killed trying to manage them.
> The problem is that they are stored entirely in memory, and this is not an option for megabytes of data in a JVM. We should find a way to work with MINA to send bytes on the fly (for instance by packets of 8kb). The very same when we receive huge data : we should store them somwhere on the disk instead of creating a byte[] large enough to store the data.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.