On Fri, Apr 16, 2010 at 3:02 PM, Rich Megginson <rmeggins@xxxxxxxxxx> wrote:
Chun Tat David Chu wrote:From looking at the code, it looks as though the only way the error 1
> Aaron,
>
> I read thru the e-mail chain but perhaps I missed it. What exactly is
> the issue you are having regarding startTLS, ABANDON request and 389
> Directory? Is it causing some unexpected behavior?
>
> I too use startTLS in my JNDI client but I don't recall seeing
> anything that you are experiencing except the persistent search that
> Rich was talking about.
>
> FYI (For your information), I narrowed down what triggers an ABANDON
> request within JNDI for persistent search by tracing the JNDI code
> that came as part of OpenJDK.
LDAP_OPERATIONS_ERROR Other operations are still pending on the
connection can be returned is if there are pending operations that have
not completed sending results to the client. In this case, it looks as
though new InitialLdapContext() with a
javax.naming.Context.SECURITY_AUTHENTICATION of "simple", and a
javax.naming.Context.SECURITY_PRINCIPAL of a valid DN, and a
javax.naming.Context.SECURITY_CREDENTIALS of a valid password does an
LDAP BIND operation, which could be the operation still incomplete when
the server receives the startTLS request.
Is it possible that tomcat is accessing the JNDI ldap context from more
than one thread at once? One way this might happen is if one thread is
attempting to complete reading the bind response, but is swapped out,
and another thread issues the starttls request on the same connection.
I have not been able to reproduce this. I've tried python-ldap and a
small test program using JNDI, to hammer the server with new
InitialLdapContext + starttls requests - running up to 100 at the same
time in separate threads. I have not been able to reproduce the error.
According to http://www.ietf.org/rfc/rfc4513.txt, it is recommended that
the client _not_ send a bind request, that the first operation on the
connection should be the startTLS operation. However, I don't know very
much about JNDI - I don't know how to turn off that implicit bind operation.
By not initializing the principle and credentials it will do an anonymous bind. I am initializing these first and then sending the startTLS operation so I will try to just do the bind afterwards and see if that helps. The other threads are using a pool so at first I thought that was the problem but I put on the pool logging to debug level and the startTLS is definitely not using one of the connections from the pool.
In response to David we are using the official sun JVM and not openJDK on our production servers and the ABANDON requests are there too. We are also not using persistent searches, just regular JNDI LdapContext.search() calls. Also these errors do seem related to system load since on normal operations everything works fine so it is possible the connections are being swapped and creating an issue. As I mentioned for now we've moved forward with just using an SSL connection all the time but after we get to a stable point I will move us back to the startTLS and see what else I can dig up.
>
> - David
>
> 2010/4/15 Aaron Hagopian <airhead1@xxxxxxxxx <mailto:airhead1@xxxxxxxxx>>
>
> I am having a hard time programmatically getting the ABANDON
> requests to show up. In my local environment I cannot reproduce
> at all (Fedora 12 x86_64) but on all our server environments I see
> these in the logs. The oddest thing about it is I only see these
> when running in tomcat on either our CentOS or RHEL machines
> (i386 and x86_64 platforms). Running a standalone java program
> does not create the ABANDON requests, only in tomcat. A little
> research shows that tomcat does have its own implementation of
> JNDI but that doesn't then explain why in my local environment
> (running same versions of java/tomcat/389ds) this does not happen.
> I will try to find any further relevant differences between my
> local environment and the servers where the messages show up.
>
> For now we are just going SSL all the time on our connections
> which seems to fix the problem since we no longer need the startTLS.
>
>
> On Wed, Apr 14, 2010 at 5:57 PM, Rich Megginson
> <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>> <rmeggins@xxxxxxxxxx <mailto:rmeggins@xxxxxxxxxx>> wrote:
>
> Aaron Hagopian wrote:
> >
> >
> > It's JNDI itself. JNDI uses ABANDON requests. Are you
> using
> > persistent
> > search at all? Another 389 user reported similar
> problems caused by
> > improper handling of JNDI persistent searches + ABANDON
> requests.
> > Although this looks different, both issues have JNDI and
> ABANDON
> > in common.
> >
> >
> > We are not using persistent search at all. I will try to
> track down
> > what in our code creates the ABANDON requests but might take
> me a bit.
> I think it's JNDI itself - you probably won't find anything
> explicitly
> calling an ABANDON request in your code.
> > Once successfull I'll get you something that causes the
> ABANDON to
> > show up followed by a startTLS.
> >
> ------------------------------------------------------------------------
> >
> > --
> > 389 users mailing list
> > 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> > https://admin.fedoraproject.org/mailman/listinfo/389-users> <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>
> --
> 389 users mailing list
> 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/389-users> <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>
>
>
> --
> 389 users mailing list
> 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
> ------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
