You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Andrea Gariboldi <an...@gmail.com> on 2009/04/02 23:10:56 UTC
ldap server buffers search results?
Hi guys,
i was testing the oracle partition and it looks like the mina filter chain
buffers the search results until
the search ends and then starts message encoding end sending... Is this a
protocol constraint or a bug?
(org.apache.directory.server.ldap.handlers.SearchHandler : 326 snippet:
while ( (count < sizeLimit ) && cursor.next() )
{
if ( session.getIoSession().isClosing() )
{
break;
}
ClonedServerEntry entry = cursor.get();
session.getIoSession().write( generateResponse( session, req,
entry ) ); // here the message is "writed" trought mina filters, but is not
encoded until the end of this loop...
count++;
}
)
Doing a long search (1000+ entries) results in long waits for the first
result on the client and java heap consumption.
am i missing something?
Andrea
Re: ldap server buffers search results?
Posted by Emmanuel Lecharny <el...@apache.org>.
Andrea Gariboldi wrote:
> Hi guys,
> i was testing the oracle partition and it looks like the mina filter chain
> buffers the search results until
> the search ends and then starts message encoding end sending... Is this a
> protocol constraint or a bug?
>
Hi Andrea,
this is a bug which has been fixed in MINA. The related JIRA is this one :
https://issues.apache.org/jira/browse/DIRSERVER-1161
It took months to find a solution...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: ldap server buffers search results?
Posted by Alex Karasulu <ak...@gmail.com>.
On Sun, Apr 5, 2009 at 11:57 AM, Emmanuel Lecharny <el...@apache.org>wrote:
> Alex Karasulu wrote:
>
>> On Sat, Apr 4, 2009 at 6:41 PM, Emmanuel Lecharny <elecharny@apache.org
>> >wrote:
>>
>>
>>
>>> Some follow-up :
>>>
>>> I have done many tests, and I successfully got a working server without
>>> having all the messages stored in memory, simply by changing the way the
>>> ExecutorFilter is instanciated. In LdapService, line 361, instead of :
>>>
>>> // Now inject an ExecutorFilter for the write operations
>>> // We use the same number of thread than the number of IoProcessor
>>> // (NOTE : this has to be double checked)
>>> ((DefaultIoFilterChainBuilder)chain).addLast( "executor",
>>> new ExecutorFilter( new OrderedThreadPoolExecutor(
>>> getTcpTransport().getNbThreads() ),
>>> IoEventType.WRITE ) );
>>>
>>> use :
>>>
>>> // Now inject an ExecutorFilter for the write operations
>>> // We use the same number of thread than the number of IoProcessor
>>> // (NOTE : this has to be double checked)
>>> ((DefaultIoFilterChainBuilder)chain).addLast( "executor",
>>> new ExecutorFilter( new OrderedThreadPoolExecutor(
>>> getTcpTransport().getNbThreads() ) ) );
>>>
>>> Now, the executor is used in both ways, and it seems to work much better.
>>>
>>>
>>>
>>
>> So the Executor is not being used for all event types: reads, and writes.
>> How is this effecting the dynamic. I think it's very important for us to
>> have a good written characterization of the problem before hand. Then we
>> can follow up with a summary of what each approach does.
>>
>>
> There is a bit of an issue : you can just have one single executor in the
> chain. Right now, I'm analysing the MINA internals to see what are the
> reason why limitating the IoEvent to WRITE only leads to OOM, or at least,
> late sending of all the messages, when accepting all the events is just
> ok...
>
>> The reason why I'm being a bit anal about this is because I know the
>> dynamics of MINA are going to be dramatically impacted when ApacheDS is
>> put
>> under heavy load.
>>
>>
> I'm also really scared about what could happen in a real environment (ie
> thousands of clients, with some of them sending more than one request at the
> same time).
>
> This is painful ...
>
>
Oh yes I know it must be very painful but it is perhaps the most important
work anyone can be doing for ApacheDS.
Alex
Re: ldap server buffers search results?
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> On Sat, Apr 4, 2009 at 6:41 PM, Emmanuel Lecharny <el...@apache.org>wrote:
>
>
>> Some follow-up :
>>
>> I have done many tests, and I successfully got a working server without
>> having all the messages stored in memory, simply by changing the way the
>> ExecutorFilter is instanciated. In LdapService, line 361, instead of :
>>
>> // Now inject an ExecutorFilter for the write operations
>> // We use the same number of thread than the number of IoProcessor
>> // (NOTE : this has to be double checked)
>> ((DefaultIoFilterChainBuilder)chain).addLast( "executor",
>> new ExecutorFilter( new OrderedThreadPoolExecutor(
>> getTcpTransport().getNbThreads() ),
>> IoEventType.WRITE ) );
>>
>> use :
>>
>> // Now inject an ExecutorFilter for the write operations
>> // We use the same number of thread than the number of IoProcessor
>> // (NOTE : this has to be double checked)
>> ((DefaultIoFilterChainBuilder)chain).addLast( "executor",
>> new ExecutorFilter( new OrderedThreadPoolExecutor(
>> getTcpTransport().getNbThreads() ) ) );
>>
>> Now, the executor is used in both ways, and it seems to work much better.
>>
>>
>
> So the Executor is not being used for all event types: reads, and writes.
> How is this effecting the dynamic. I think it's very important for us to
> have a good written characterization of the problem before hand. Then we
> can follow up with a summary of what each approach does.
>
There is a bit of an issue : you can just have one single executor in
the chain. Right now, I'm analysing the MINA internals to see what are
the reason why limitating the IoEvent to WRITE only leads to OOM, or at
least, late sending of all the messages, when accepting all the events
is just ok...
> The reason why I'm being a bit anal about this is because I know the
> dynamics of MINA are going to be dramatically impacted when ApacheDS is put
> under heavy load.
>
I'm also really scared about what could happen in a real environment (ie
thousands of clients, with some of them sending more than one request at
the same time).
This is painful ...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: ldap server buffers search results?
Posted by Alex Karasulu <ak...@gmail.com>.
On Sat, Apr 4, 2009 at 6:41 PM, Emmanuel Lecharny <el...@apache.org>wrote:
> Some follow-up :
>
> I have done many tests, and I successfully got a working server without
> having all the messages stored in memory, simply by changing the way the
> ExecutorFilter is instanciated. In LdapService, line 361, instead of :
>
> // Now inject an ExecutorFilter for the write operations
> // We use the same number of thread than the number of IoProcessor
> // (NOTE : this has to be double checked)
> ((DefaultIoFilterChainBuilder)chain).addLast( "executor",
> new ExecutorFilter( new OrderedThreadPoolExecutor(
> getTcpTransport().getNbThreads() ),
> IoEventType.WRITE ) );
>
> use :
>
> // Now inject an ExecutorFilter for the write operations
> // We use the same number of thread than the number of IoProcessor
> // (NOTE : this has to be double checked)
> ((DefaultIoFilterChainBuilder)chain).addLast( "executor",
> new ExecutorFilter( new OrderedThreadPoolExecutor(
> getTcpTransport().getNbThreads() ) ) );
>
> Now, the executor is used in both ways, and it seems to work much better.
>
So the Executor is not being used for all event types: reads, and writes.
How is this effecting the dynamic. I think it's very important for us to
have a good written characterization of the problem before hand. Then we
can follow up with a summary of what each approach does.
The reason why I'm being a bit anal about this is because I know the
dynamics of MINA are going to be dramatically impacted when ApacheDS is put
under heavy load.
Alex
Re: ldap server buffers search results?
Posted by Emmanuel Lecharny <el...@apache.org>.
> On Mon, Apr 6, 2009 at 1:18 PM, Emmanuel Lecharny <el...@apache.org>
> wrote:
>>
>> > Now I just need to figure out what makes this work so I can back port it
>> > to
>> > my project (based on ApacheDS 1.5.1)...
>>
>> You will need a new version of MINA 1.1... Not likely to happens soon :/
>>
>> You'd probably better to move to 1.5.5 when we will release it in the
>> next few weeks (days ?)
>
> We should release 1.5.5 as soon as MINA 2.0.0-M5 is out the door. I'll take
> care of the release. Let's also make sure Emm that you have all the other
> work you've done merged back into trunk.
MINA 2.0.0-M5 release is currently being voted on. The vote will be
closed by thursday afternoon.
Thanks Alex !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ldap server buffers search results?
Posted by Alex Karasulu <ak...@gmail.com>.
On Mon, Apr 6, 2009 at 1:18 PM, Emmanuel Lecharny <el...@apache.org>wrote:
> > Now I just need to figure out what makes this work so I can back port it
> to
> > my project (based on ApacheDS 1.5.1)...
>
> You will need a new version of MINA 1.1... Not likely to happens soon :/
>
> You'd probably better to move to 1.5.5 when we will release it in the
> next few weeks (days ?)
>
We should release 1.5.5 as soon as MINA 2.0.0-M5 is out the door. I'll take
care of the release. Let's also make sure Emm that you have all the other
work you've done merged back into trunk.
Alex
Re: ldap server buffers search results?
Posted by Emmanuel Lecharny <el...@apache.org>.
> Now I just need to figure out what makes this work so I can back port it to
> my project (based on ApacheDS 1.5.1)...
You will need a new version of MINA 1.1... Not likely to happens soon :/
You'd probably better to move to 1.5.5 when we will release it in the
next few weeks (days ?)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ldap server buffers search results?
Posted by Alex Karasulu <ak...@gmail.com>.
Nice! Thanks Emmanuel.
Alex
On Mon, Apr 6, 2009 at 12:43 PM, Martin Alderson <eq...@planetquake.com>wrote:
> Hi Emmanuel,
>
> That seems to have done the trick! A search in my test server returned
> 25000 users pretty quickly with no problems.
>
> Now I just need to figure out what makes this work so I can back port it to
> my project (based on ApacheDS 1.5.1)...
>
> Thanks for looking into this!
>
> Martin
>
>
>
> Emmanuel Lecharny wrote:
>
>> I have removed the CircularQueue from MINA 2.0.0-trunk, because it was
>> not thread safe, and replaced it with a ConcurrentQueue.
>>
>> That might change something...
>>
>> Now, I have to check that once the events are dequeued, they are
>> correctly removed from the queue.
>>
>> Can you give the server a try with a fresh version of MINA ? (there
>> are some binary for MINA-2.0.0-M5 available, just rename them 2.0.0-M4
>> and put them in your .m2 repo. The binary are available here :
>> http://people.apache.org/~jvermillard/mina-2.0.0-M5-SNAPSHOT/<http://people.apache.org/%7Ejvermillard/mina-2.0.0-M5-SNAPSHOT/>
>> )
>>
>>
>
Re: ldap server buffers search results?
Posted by Martin Alderson <eq...@planetquake.com>.
Hi Emmanuel,
That seems to have done the trick! A search in my test server returned
25000 users pretty quickly with no problems.
Now I just need to figure out what makes this work so I can back port it
to my project (based on ApacheDS 1.5.1)...
Thanks for looking into this!
Martin
Emmanuel Lecharny wrote:
> I have removed the CircularQueue from MINA 2.0.0-trunk, because it was
> not thread safe, and replaced it with a ConcurrentQueue.
>
> That might change something...
>
> Now, I have to check that once the events are dequeued, they are
> correctly removed from the queue.
>
> Can you give the server a try with a fresh version of MINA ? (there
> are some binary for MINA-2.0.0-M5 available, just rename them 2.0.0-M4
> and put them in your .m2 repo. The binary are available here :
> http://people.apache.org/~jvermillard/mina-2.0.0-M5-SNAPSHOT/)
>
Re: ldap server buffers search results?
Posted by Emmanuel Lecharny <el...@apache.org>.
I have removed the CircularQueue from MINA 2.0.0-trunk, because it was
not thread safe, and replaced it with a ConcurrentQueue.
That might change something...
Now, I have to check that once the events are dequeued, they are
correctly removed from the queue.
Can you give the server a try with a fresh version of MINA ? (there
are some binary for MINA-2.0.0-M5 available, just rename them 2.0.0-M4
and put them in your .m2 repo. The binary are available here :
http://people.apache.org/~jvermillard/mina-2.0.0-M5-SNAPSHOT/)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ldap server buffers search results?
Posted by Martin Alderson <eq...@planetquake.com>.
Emmanuel Lecharny wrote:
> On Mon, Apr 6, 2009 at 3:59 PM, Martin Alderson <eq...@planetquake.com> wrote:
>> Hi Emmanuel,
>>
>> I've just tested with this change (on the latest trunk) and while the
>> results seem to be streamed to the client immediately they are still cached
>> in the server until the end.
>
> Do you have any clue where the data are being cached ? I can't chekc
> the code right now (i'm working for a customer), but I would be
> interesting to get the information before I come back home.
Sorry, forgot to add that:
org.apache.directory.shared.ldap.message.SearchResponseEntryImpl
org.apache.mina.core.write.DefaultWriteRequest.message
org.apache.mina.core.filterchain.IoFilterEvent.parameter
Object[427]
org.apache.mina.util.CircularQueue.items
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$SessionBuffer.queue
Martin
Re: ldap server buffers search results?
Posted by Emmanuel Lecharny <el...@apache.org>.
On Mon, Apr 6, 2009 at 3:59 PM, Martin Alderson <eq...@planetquake.com> wrote:
> Hi Emmanuel,
>
> I've just tested with this change (on the latest trunk) and while the
> results seem to be streamed to the client immediately they are still cached
> in the server until the end.
Do you have any clue where the data are being cached ? I can't chekc
the code right now (i'm working for a customer), but I would be
interesting to get the information before I come back home.
Thanks Martin !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ldap server buffers search results?
Posted by Martin Alderson <eq...@planetquake.com>.
Hi Emmanuel,
I've just tested with this change (on the latest trunk) and while the
results seem to be streamed to the client immediately they are still
cached in the server until the end. This means it is still very easy to
get an OutOfMemoryError.
Thanks,
Martin
> Some follow-up :
>
> I have done many tests, and I successfully got a working server without
> having all the messages stored in memory, simply by changing the way the
> ExecutorFilter is instanciated. In LdapService, line 361, instead of :
>
> // Now inject an ExecutorFilter for the write operations
> // We use the same number of thread than the number of IoProcessor
> // (NOTE : this has to be double checked)
> ((DefaultIoFilterChainBuilder)chain).addLast( "executor",
> new ExecutorFilter( new OrderedThreadPoolExecutor(
> getTcpTransport().getNbThreads() ),
> IoEventType.WRITE ) );
>
> use :
>
> // Now inject an ExecutorFilter for the write operations
> // We use the same number of thread than the number of IoProcessor
> // (NOTE : this has to be double checked)
> ((DefaultIoFilterChainBuilder)chain).addLast( "executor",
> new ExecutorFilter( new OrderedThreadPoolExecutor(
> getTcpTransport().getNbThreads() ) ) );
>
> Now, the executor is used in both ways, and it seems to work much better.
>
> I still have to understand how the ExecutorFilter() is working in MINA,
> but at least, I think we cant release MINA 2.0.0 without a clear
> documentation about the way to use this executor filter !
Re: ldap server buffers search results?
Posted by Emmanuel Lecharny <el...@apache.org>.
Some follow-up :
I have done many tests, and I successfully got a working server without
having all the messages stored in memory, simply by changing the way the
ExecutorFilter is instanciated. In LdapService, line 361, instead of :
// Now inject an ExecutorFilter for the write operations
// We use the same number of thread than the number of IoProcessor
// (NOTE : this has to be double checked)
((DefaultIoFilterChainBuilder)chain).addLast( "executor",
new ExecutorFilter( new OrderedThreadPoolExecutor(
getTcpTransport().getNbThreads() ),
IoEventType.WRITE ) );
use :
// Now inject an ExecutorFilter for the write operations
// We use the same number of thread than the number of IoProcessor
// (NOTE : this has to be double checked)
((DefaultIoFilterChainBuilder)chain).addLast( "executor",
new ExecutorFilter( new OrderedThreadPoolExecutor(
getTcpTransport().getNbThreads() ) ) );
Now, the executor is used in both ways, and it seems to work much better.
I still have to understand how the ExecutorFilter() is working in MINA,
but at least, I think we cant release MINA 2.0.0 without a clear
documentation about the way to use this executor filter !
Andrea Gariboldi wrote:
> Hi Martin,
> Emmanuel found that there is a threading design problem within MINA:
>
> The IoProcessor that is handling the search request and putting the encoded
> results in the WriteQueue,
> is the same that should dequeue those results from the queue and send it. So
> once it has finished
> with the request processing it checks for things to write and write all the
> results in the queue, but
> if you have long searches you will most likely get an OOM exception, because
> of the growing queue.
>
> Andrea
>
> 2009/4/3 Martin Alderson <eq...@planetquake.com>
>
>
>> Hi Andrea,
>>
>> Just to let you know, this looks to be the same problem that is being
>> discussed in my OutOfMemoryError thread on the users mailing list.
>>
>> It still seems to be happening in the latest ApacheDS trunk. I don't
>> really understand why it is happening yet though.
>>
>> Martin
>>
>>
>>
>> Andrea Gariboldi wrote:
>>
>>
>>> Hi guys,
>>> i was testing the oracle partition and it looks like the mina filter
>>> chain
>>> buffers the search results until
>>> the search ends and then starts message encoding end sending... Is this a
>>> protocol constraint or a bug?
>>> (org.apache.directory.server.ldap.handlers.SearchHandler : 326 snippet:
>>>
>>> while ( (count < sizeLimit ) && cursor.next() )
>>> {
>>> if ( session.getIoSession().isClosing() )
>>> {
>>> break;
>>> }
>>>
>>> ClonedServerEntry entry = cursor.get();
>>> session.getIoSession().write( generateResponse( session, req,
>>> entry ) ); // here the message is "writed" trought mina filters, but is
>>> not
>>> encoded until the end of this loop...
>>> count++;
>>> }
>>>
>>> )
>>>
>>>
>>> Doing a long search (1000+ entries) results in long waits for the first
>>> result on the client and java heap consumption.
>>>
>>> am i missing something?
>>>
>>> Andrea
>>>
>>>
>>>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: ldap server buffers search results?
Posted by Emmanuel Lecharny <el...@apache.org>.
Hi,
I have created a JIRA on MINA :
https://issues.apache.org/jira/browse/DIRMINA-682
I'm currently trying to see what happens if we use a
simpleExecutorFilter() instead of the same object with some
OrdederThreadPoolExecutor. I'm currently running integration tests. I'm
afraid that it kills scalability, but at least, I have checked that it
returns messages one by one.
Andrea Gariboldi wrote:
> Hi Martin,
> Emmanuel found that there is a threading design problem within MINA:
>
> The IoProcessor that is handling the search request and putting the encoded
> results in the WriteQueue,
> is the same that should dequeue those results from the queue and send it. So
> once it has finished
> with the request processing it checks for things to write and write all the
> results in the queue, but
> if you have long searches you will most likely get an OOM exception, because
> of the growing queue.
>
> Andrea
>
> 2009/4/3 Martin Alderson <eq...@planetquake.com>
>
>
>> Hi Andrea,
>>
>> Just to let you know, this looks to be the same problem that is being
>> discussed in my OutOfMemoryError thread on the users mailing list.
>>
>> It still seems to be happening in the latest ApacheDS trunk. I don't
>> really understand why it is happening yet though.
>>
>> Martin
>>
>>
>>
>> Andrea Gariboldi wrote:
>>
>>
>>> Hi guys,
>>> i was testing the oracle partition and it looks like the mina filter
>>> chain
>>> buffers the search results until
>>> the search ends and then starts message encoding end sending... Is this a
>>> protocol constraint or a bug?
>>> (org.apache.directory.server.ldap.handlers.SearchHandler : 326 snippet:
>>>
>>> while ( (count < sizeLimit ) && cursor.next() )
>>> {
>>> if ( session.getIoSession().isClosing() )
>>> {
>>> break;
>>> }
>>>
>>> ClonedServerEntry entry = cursor.get();
>>> session.getIoSession().write( generateResponse( session, req,
>>> entry ) ); // here the message is "writed" trought mina filters, but is
>>> not
>>> encoded until the end of this loop...
>>> count++;
>>> }
>>>
>>> )
>>>
>>>
>>> Doing a long search (1000+ entries) results in long waits for the first
>>> result on the client and java heap consumption.
>>>
>>> am i missing something?
>>>
>>> Andrea
>>>
>>>
>>>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: ldap server buffers search results?
Posted by Emmanuel Lecharny <el...@apache.org>.
Andrea Gariboldi wrote:
> Hi Martin,
> Emmanuel found that there is a threading design problem within MINA:
>
> The IoProcessor that is handling the search request and putting the encoded
> results in the WriteQueue,
> is the same that should dequeue those results from the queue and send it. So
> once it has finished
> with the request processing it checks for things to write and write all the
> results in the queue, but
> if you have long searches you will most likely get an OOM exception, because
> of the growing queue.
>
I'm working on the problem. I don't know if there is a simple solution,
or if we should use two different IoProcessor (one for the read, one for
the write).
I first have to write a very simple use case on MINA to see if it's a
problem in MINA or if we are doing something wrong in the server.
Thanks Andrea !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: ldap server buffers search results?
Posted by Andrea Gariboldi <an...@gmail.com>.
Hi Martin,
Emmanuel found that there is a threading design problem within MINA:
The IoProcessor that is handling the search request and putting the encoded
results in the WriteQueue,
is the same that should dequeue those results from the queue and send it. So
once it has finished
with the request processing it checks for things to write and write all the
results in the queue, but
if you have long searches you will most likely get an OOM exception, because
of the growing queue.
Andrea
2009/4/3 Martin Alderson <eq...@planetquake.com>
> Hi Andrea,
>
> Just to let you know, this looks to be the same problem that is being
> discussed in my OutOfMemoryError thread on the users mailing list.
>
> It still seems to be happening in the latest ApacheDS trunk. I don't
> really understand why it is happening yet though.
>
> Martin
>
>
>
> Andrea Gariboldi wrote:
>
>> Hi guys,
>> i was testing the oracle partition and it looks like the mina filter
>> chain
>> buffers the search results until
>> the search ends and then starts message encoding end sending... Is this a
>> protocol constraint or a bug?
>> (org.apache.directory.server.ldap.handlers.SearchHandler : 326 snippet:
>>
>> while ( (count < sizeLimit ) && cursor.next() )
>> {
>> if ( session.getIoSession().isClosing() )
>> {
>> break;
>> }
>>
>> ClonedServerEntry entry = cursor.get();
>> session.getIoSession().write( generateResponse( session, req,
>> entry ) ); // here the message is "writed" trought mina filters, but is
>> not
>> encoded until the end of this loop...
>> count++;
>> }
>>
>> )
>>
>>
>> Doing a long search (1000+ entries) results in long waits for the first
>> result on the client and java heap consumption.
>>
>> am i missing something?
>>
>> Andrea
>>
>>
>
Re: ldap server buffers search results?
Posted by Alex Karasulu <ak...@gmail.com>.
Hi guys,
On Sat, Apr 4, 2009 at 2:56 AM, Andrea Gariboldi <andrea.gariboldi@gmail.com
> wrote:
> Emmanuel,
> here is where the buffer is finally wrote:
>
> org.apache.mina.core.polling.AbstractPollingIoProcessor [line: 758] :
> localWrittenBytes = write(session, buf, length);
>
Yeah but this should be called when each SearchResultEntry is written back
to the client. It's really worrisome that a session.write() is not
resulting in a processor write back to the client on it's socket.
>
> It looks like this is not called until a SearchResponseDoneImpl
> is writed and encoded here:
>
Yep this is the problem.
>
> org.apache.directory.server.ldap.handlers-SearchHandler [line: 951] :
> session.getIoSession().write( done );
>
We properly perform a session.write() here:
org.apache.directory.server.ldap.handlers-SearchHandler [line: 326] :
session.getIoSession().write( generateResponse( session, req, entry
) );
If this is not trigger a processor write() on the client socket, then we
might want to consider using a WriteFuture to force a write before
continuing. However I think this may hide the true problem in MINA.
Regardless give that a try and see if it prevents entry responses from
collecting in the queue. Here's what the patch might look like below. NOTE
this is not the best way to handle this but just something used to test. I
would use a timeout.
<idea>
Time out based wait on WriteFuture might be a crude yet easy way to
throttle responses to slow clients.
</idea>
Alex
-----------
Index:
protocol-ldap/src/main/java/org/apache/directory/server/ldap/handlers/SearchHandler.java
===================================================================
---
protocol-ldap/src/main/java/org/apache/directory/server/ldap/handlers/SearchHandler.java
(revision 761433)
+++
protocol-ldap/src/main/java/org/apache/directory/server/ldap/handlers/SearchHandler.java
(working copy)
@@ -59,6 +59,7 @@
import org.apache.directory.shared.ldap.schema.AttributeType;
import org.apache.directory.shared.ldap.util.LdapURL;
import org.apache.directory.shared.ldap.util.StringTools;
+import org.apache.mina.core.future.WriteFuture;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -323,7 +324,9 @@
}
ClonedServerEntry entry = cursor.get();
- session.getIoSession().write( generateResponse( session, req,
entry ) );
+ WriteFuture future = session.getIoSession().write(
+ generateResponse( session, req, entry ) );
+ future.await();
count++;
}
Re: ldap server buffers search results?
Posted by Andrea Gariboldi <an...@gmail.com>.
Emmanuel,
here is where the buffer is finally wrote:
org.apache.mina.core.polling.AbstractPollingIoProcessor [line: 758] :
localWrittenBytes = write(session, buf, length);
It looks like this is not called until a SearchResponseDoneImpl
is writed and encoded here:
org.apache.directory.server.ldap.handlers-SearchHandler [line: 951] :
session.getIoSession().write( done );
Andrea
2009/4/3, Andrea Gariboldi <an...@gmail.com>:
>
> Ok ! Sure ! I hope i'll find something usefull this night to make you start
> from a forward point.
>
> 2009/4/3, Emmanuel Lecharny <el...@apache.org>:
>>
>> Andrea Gariboldi wrote:
>>
>>> Ok i'am going to dig it...
>>>
>>>
>> Andrea, I also want to give it a try tomorrow, as soon as I'm done with
>> what I'm currently working on. That would be a pleasure to do that together.
>> In this case, the best would probably to hang on IRC [1] or IM (gmail), just
>> to exchange in real time info while debugging. Mail is a bit too
>> asynchronous for peer debugging session ;)
>>
>> Thanks for the proposal !
>>
>> PS : tomorrow I may be logged late, as Alex has a plane at 9am (what a
>> shmuck !) so we have to leave at 5am, which means wake up at 4am. That to
>> say we are unlikely to sleep at all ;)
>>
>> --
>> --
>> cordialement, regards,
>> Emmanuel Lécharny
>> www.iktek.com
>> directory.apache.org
>>
>>
>>
>
Re: ldap server buffers search results?
Posted by Andrea Gariboldi <an...@gmail.com>.
Ok ! Sure ! I hope i'll find something usefull this night to make you start
from a forward point.
2009/4/3, Emmanuel Lecharny <el...@apache.org>:
>
> Andrea Gariboldi wrote:
>
>> Ok i'am going to dig it...
>>
>>
> Andrea, I also want to give it a try tomorrow, as soon as I'm done with
> what I'm currently working on. That would be a pleasure to do that together.
> In this case, the best would probably to hang on IRC [1] or IM (gmail), just
> to exchange in real time info while debugging. Mail is a bit too
> asynchronous for peer debugging session ;)
>
> Thanks for the proposal !
>
> PS : tomorrow I may be logged late, as Alex has a plane at 9am (what a
> shmuck !) so we have to leave at 5am, which means wake up at 4am. That to
> say we are unlikely to sleep at all ;)
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: ldap server buffers search results?
Posted by Emmanuel Lecharny <el...@apache.org>.
Andrea Gariboldi wrote:
> Ok i'am going to dig it...
>
Andrea, I also want to give it a try tomorrow, as soon as I'm done with
what I'm currently working on. That would be a pleasure to do that
together. In this case, the best would probably to hang on IRC [1] or IM
(gmail), just to exchange in real time info while debugging. Mail is a
bit too asynchronous for peer debugging session ;)
Thanks for the proposal !
PS : tomorrow I may be logged late, as Alex has a plane at 9am (what a
shmuck !) so we have to leave at 5am, which means wake up at 4am. That
to say we are unlikely to sleep at all ;)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: ldap server buffers search results?
Posted by Andrea Gariboldi <an...@gmail.com>.
Ok i'am going to dig it...
Andrea
2009/4/3, Alex Karasulu <ak...@gmail.com>:
>
> This is something we really need to fix before we release a 1.5.5.
>
> Alex
>
> On Fri, Apr 3, 2009 at 1:11 PM, Martin Alderson <eq...@planetquake.com>wrote:
>
>> Hi Andrea,
>>
>> Just to let you know, this looks to be the same problem that is being
>> discussed in my OutOfMemoryError thread on the users mailing list.
>>
>> It still seems to be happening in the latest ApacheDS trunk. I don't
>> really understand why it is happening yet though.
>>
>> Martin
>>
>>
>>
>> Andrea Gariboldi wrote:
>>
>>> Hi guys,
>>> i was testing the oracle partition and it looks like the mina filter
>>> chain
>>> buffers the search results until
>>> the search ends and then starts message encoding end sending... Is this a
>>> protocol constraint or a bug?
>>> (org.apache.directory.server.ldap.handlers.SearchHandler : 326 snippet:
>>>
>>> while ( (count < sizeLimit ) && cursor.next() )
>>> {
>>> if ( session.getIoSession().isClosing() )
>>> {
>>> break;
>>> }
>>>
>>> ClonedServerEntry entry = cursor.get();
>>> session.getIoSession().write( generateResponse( session, req,
>>> entry ) ); // here the message is "writed" trought mina filters, but is
>>> not
>>> encoded until the end of this loop...
>>> count++;
>>> }
>>>
>>> )
>>>
>>>
>>> Doing a long search (1000+ entries) results in long waits for the first
>>> result on the client and java heap consumption.
>>>
>>> am i missing something?
>>>
>>> Andrea
>>>
>>>
>>
>
Re: ldap server buffers search results?
Posted by Alex Karasulu <ak...@gmail.com>.
This is something we really need to fix before we release a 1.5.5.
Alex
On Fri, Apr 3, 2009 at 1:11 PM, Martin Alderson <eq...@planetquake.com>wrote:
> Hi Andrea,
>
> Just to let you know, this looks to be the same problem that is being
> discussed in my OutOfMemoryError thread on the users mailing list.
>
> It still seems to be happening in the latest ApacheDS trunk. I don't
> really understand why it is happening yet though.
>
> Martin
>
>
>
> Andrea Gariboldi wrote:
>
>> Hi guys,
>> i was testing the oracle partition and it looks like the mina filter
>> chain
>> buffers the search results until
>> the search ends and then starts message encoding end sending... Is this a
>> protocol constraint or a bug?
>> (org.apache.directory.server.ldap.handlers.SearchHandler : 326 snippet:
>>
>> while ( (count < sizeLimit ) && cursor.next() )
>> {
>> if ( session.getIoSession().isClosing() )
>> {
>> break;
>> }
>>
>> ClonedServerEntry entry = cursor.get();
>> session.getIoSession().write( generateResponse( session, req,
>> entry ) ); // here the message is "writed" trought mina filters, but is
>> not
>> encoded until the end of this loop...
>> count++;
>> }
>>
>> )
>>
>>
>> Doing a long search (1000+ entries) results in long waits for the first
>> result on the client and java heap consumption.
>>
>> am i missing something?
>>
>> Andrea
>>
>>
>
Re: ldap server buffers search results?
Posted by Martin Alderson <eq...@planetquake.com>.
Hi Andrea,
Just to let you know, this looks to be the same problem that is being
discussed in my OutOfMemoryError thread on the users mailing list.
It still seems to be happening in the latest ApacheDS trunk. I don't
really understand why it is happening yet though.
Martin
Andrea Gariboldi wrote:
> Hi guys,
> i was testing the oracle partition and it looks like the mina filter chain
> buffers the search results until
> the search ends and then starts message encoding end sending... Is this a
> protocol constraint or a bug?
> (org.apache.directory.server.ldap.handlers.SearchHandler : 326 snippet:
>
> while ( (count < sizeLimit ) && cursor.next() )
> {
> if ( session.getIoSession().isClosing() )
> {
> break;
> }
>
> ClonedServerEntry entry = cursor.get();
> session.getIoSession().write( generateResponse( session, req,
> entry ) ); // here the message is "writed" trought mina filters, but is not
> encoded until the end of this loop...
> count++;
> }
>
> )
>
>
> Doing a long search (1000+ entries) results in long waits for the first
> result on the client and java heap consumption.
>
> am i missing something?
>
> Andrea
>