Issue with concurrent requests

Jun 17, 2010 at 3:14 PM
Edited Jun 17, 2010 at 3:23 PM

I seem have an issue when IE issues concurrent requests to a Jetty server using WAFFLE.

I'm using a servlet that delivers an HTML page which has referenced resources.  For some reason, it fails to read just one of the referenced resources; the flow is this for the resource:

  1. IE sends the request without authentication.
  2. WAFFLE responds with 401.
  3. IE sends the first part of the authentication (keep in mind I'm not 100% familiar with the challenge-response mechanism).
  4. WAFFLE responds.
  5. IE then fails to request the resource with authentication.

Not only does it not request the resource, it spins, failing to load.  It doesn't even time out.

If I swap the servlet for something that delivers a small, static HTML page, then it *sometimes* happens.  It's usually the first or second referenced resource that fails to load.

My suspicion is that IE is eagerly requesting resources whilst the HTML is being downloaded -- hence, using a complex servlet that does processing will increase the probability that it will occur.

Any suggestions?  I can open an issue if required.

I also notice that in NegotiateSecurityFilter.doFilter(), request.getUserPrincipal() always returns null -- there is no cross-request authentication going on.  I'm not sure of the effect of that, except that loading each resource requires an authorization check (and slows it down slightly).

Thank you in advance.

 

(Edit:  Apparently, marking NegotiateSecurityFilter.doFilter() synchronized reduces the frequency of problems, but does not eliminate it.  Sorry.)

Coordinator
Jun 17, 2010 at 3:26 PM

Looks like there's a bug (or two) somewhere.

First for the background. NTLM needs to remember a security context from a previous call and I use a ConcurrentHashMap for this. It's not possible to bind it to a session, because you may have concurrent requests, so it has to be per-connection.

The first thought is that the ConcurrentHashMap in WindowsAuthProviderImpl.java has behavior that I don't understand (not so concurrent). Start by moving the lock down into this code around those places that add/remove items from _continueContexts. I would start by swapping the map by something more stupid with a lock and see if that just fixes the problem. This is a total guess, but that's the only place where concurrency or load matters, IMHO. The rest of the code doesn't interact across threads.

I'll start writing a threaded test to stress the provider, then the filter.

For the getUserPrincipal(), just file a bug, I think it's an easy one.

Coordinator
Jun 17, 2010 at 9:17 PM

Can you please collect the HTTP trace from the IE hang? You can use fiddler/whatever. Thx. File a bug and you can attach a file to it.

Coordinator
Jun 18, 2010 at 12:03 PM

Thanks for the bug report. I've uploaded build 1.3.4275.0 that corrects the keep-alive problem. Lets see if it fixes it.

Jun 18, 2010 at 1:01 PM

Thank you!  That's fantastic.  It now works every time, even if I use keep-alive in my servlets.

Coordinator
Jun 18, 2010 at 4:28 PM

Good. Do try 1.3.4277.0 (or latest source code trunk build), tell me if the other issue with getUserPrincipal is fixed or causing any trouble, especially.