A question regarding "org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper" class

[Michal Lefler <mi...@traffixsystems.com>]

Hi.

I was using JNDI, and I noticed that if I use JNDI connection pooling,
"ctx.close()" does not release the context back to the pool unless I
execute "System.gc()" explicitly.

I looked at your " JNDIConnectionWrapper" class as a reference, and I
saw that your "disconnect" method also executes "System.gc()".

Why did you add this call? 

Did you ran into the same problem? 

Isn't there a better solution? (it is pretty ugly...)

 

Thanks in advance,

Michal.

Re: A question regarding "org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper" class

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

Hi Michal,

I don't know exactly why our implementation does this. Stefan Seelmann, who implemented this part will probably have the good answer to this question.

However I came across the same problem you're experiencing with JNDI Connection pool on some client work. 
I figured out the connection was not released back to the pool because some of the Naming Enumerations I got from the connection were not explicitly closed.
You should make that you close all your Naming Enumerations

Hope this helps,
Pierre-Arnaud

On 10 mars 2010, at 16:03, Michal Lefler wrote:

> Hi.
> I was using JNDI, and I noticed that if I use JNDI connection pooling, "ctx.close()" does not release the context back to the pool unless I execute "System.gc()" explicitly.
> I looked at your " JNDIConnectionWrapper" class as a reference, and I saw that your "disconnect" method also executes "System.gc()".
> Why did you add this call?
> Did you ran into the same problem?
> Isn't there a better solution? (it is pretty ugly…)
>  
> Thanks in advance,
> Michal.

Re: A question regarding "org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper" class

[Emmanuel Lecharny <el...@gmail.com>]

On 3/10/10 4:03 PM, Michal Lefler wrote:
> Hi.
>
> I was using JNDI, and I noticed that if I use JNDI connection pooling,
> "ctx.close()" does not release the context back to the pool unless I
> execute "System.gc()" explicitly.
>    
There are two things that are not obvious when using a JNDI connection 
object :
- You have to close the connections when you are done with them (seems 
like you are)
- and you also *have* to close all the NamingEnumeration you are using, 
especially if you don't grab all the elements it returns, as it won't 
let you close the connection if the NamingEnumeration is not closed.

The second point is really annoying, and will lead you to the kind of 
problem you have. I would bet more on such a problem than a issue with 
the garbage collector...

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: A question regarding "org.apache.directory.studio.connection.core.io.jndi.JNDIConnectionWrapper" class

[Stefan Seelmann <se...@apache.org>]

Hi Michal,

Michal Lefler wrote:
> Hi.
> 
> I was using JNDI, and I noticed that if I use JNDI connection pooling,
> "ctx.close()" does not release the context back to the pool unless I
> execute "System.gc()" explicitly.

As Emmanuel and Pierre-Arnaud already said, make sure you close every
NamingEnumeration. Additionally, if you create a sub-context using
DirContext.createSubcontext() you also need to close that sub-context.

> I looked at your " JNDIConnectionWrapper" class as a reference, and I
> saw that your "disconnect" method also executes "System.gc()".
> 
> Why did you add this call?

Well, that is the last fallback for that issue. Another reason is that
we cache a lot of entries and this call cleans up the cached objects a
bit faster.

However that is not good practice. I won't encourage you to use it. In a
client application like Studio System.gc() works well. However if your
application runs in a managed environment like an application server you
should not use it.

> Did you ran into the same problem?
> 
> Isn't there a better solution? (it is pretty ugly…)

See above.

Kind Regards,
Stefan