Do you still experience this today?  Thanks.

I tried it just recently and it works as expected - for now.

We had a new deployment last night. The machine resources have stayed flat so far.  Let's see how it goes next couple days.  Thanks.

Reproduced again by one of my colleagues with Win Vista and FF 3.6.3.
He wasn't able to login because of PROXY ERROR. It was 23/06 at 14:43 PRG time - login name was "jpospisil".
Helped deleting of domain cookies as usually. 

BTH also another users on @nb mailing list write about troubles by logging in or logout on the site. I hope that could help some information from today logs.

Hello,
we just have another round of reports on this issue from users from yesterday. 

Still the very same problem - login pages give user 502 proxy error, Date: 30 March 2011 2:19:39 AM AEDT

Can you please investigate and let us know what is causing that?

honza

Was happening to me yesterday as well; was logged out (for no clear reason) and was getting 502s when I tried to log back in. Deleting all my cookies from netbeans.org fixed the problem.

I am pretty sure this has been reported at least once before, but there was no real resolution other than a recommendation to delete cookies. I thought that the issue was that certain actions in BugZilla respond with a very long Set-Cookie value such as for BUGLIST, or perhaps just a lot of cookies such as VERSION-${componentName}, and something in Kenai infrastructure has a low fixed limit on Cookie headers it accepts before it crashes. However BZ does seem to correctly set Path: /bugzilla/ which should prevent such cookies from being passed to e.g. /people/login so perhaps some non-BZ-related cookies are causing the issue.

The cookie path for BZ cookies was changed with the deployment yesterday. I believe it really was (mostly) the BUGLIST cookie that could create problems for GlassFish:-( It's actually the sum of all cookies >4k, but BUGLIST is by far the biggest normally.

But since I can't control the cookies out there in the browsers of different users, I'll leave this open for a bit longer.

If the server cannot handle that many cookies, is there some way for it to detect this early and fail with a helpful HTML page that tells you how to work around the problem? Otherwise your assumption is just that the server is down, and to wait a few hours.

I agree with Jesse.  While there is a workaround, I think very few people know about it and deleting my cookies is not something even an experienced person would instinctively try.  As evidence, look at issue #197854.

Kenai team: When can we expect this to get fixed?

*** Bug 197854 has been marked as a duplicate of this bug. ***

I am really curious what the Kenai's team (consisting of 1 person :( will be.

Actually, the Kenai team are still three people. But the problem is, I'm the only one who does not fear to touch all parts:-(

This particular problem is either a Bugzilla problem, or a Glassfish problem or a JRuby problem or a Rails problem:-(

The little specs about HTTP cookies say that clients and servers should handle cokkies with a combined size >= 4k. But BZ seems to create very long BUGLIST cookies when it wants to. That's the BZ problem part:-( But we sit on a EndOfLived BZ branch and nobody has time to upgrade:-(

Somewhere between GF/JRuby & Rails things fall over when the cookies get too large. But so far I don't know where:-( And all pieces are already very dated. So there is not much hope for help either:-(

Welcome to the fruits of two years under-staffing:-(

Is there any kind of web proxy being used in front of the site, where you could just script something to strip out overly large buglist cookies from the HTTP headers at the front door, before they get passed along to whatever chokes on them?

Is this still a problem or was setting the cookie path to /bugzilla/ good here?