I've just tried this on b58 with the same results.
On 8/5/07, Kem Elbrader <kem.elbrader_at_gmail.com> wrote:
> Ah, looks like what I experience might be a little different than that
> reported in the issue. When I run the telnet command the app server
> consumes 100% of the CPU. Note that for some reason I have to press
> enter in the telnet window after connecting. I don't know why this is.
> Also, note that if you're attempting to reproduce this using a dual
> core system it can be easy to miss because only one of the cores will
> be consumed for the request and the rest of the system will continue
> to respond normally.
>
> I can produce this using Java 1.6 on both b50g and b57 running either
> Ubuntu 7.04 or Windows XP Pro SP2.
>
> We are running the app server for long periods of time and on occasion
> a request comes in that shoots the CPU up to 100%. I've assumed that
> this was the cause.
>
> On 8/5/07, Jan.Luehe_at_sun.com <Jan.Luehe_at_sun.com> wrote:
> > Hi Kem,
> >
> > Kem Elbrader wrote:
> >
> > >Looks like I'm not allowed to reopen the issue myself. Can someone
> > >who does have permission verify that the bug still exists and then
> > >reopen the issue if so. This seems to be a very critical issue as it
> > >would prevent Glassfish V2 from being a viable option when using
> > >Grizzly.
> > >
> > >On 8/3/07, Kem Elbrader <kem.elbrader_at_gmail.com> wrote:
> > >
> > >
> > >>I'm still experiencing SSL blocking issue reported on Glassfish issue 1710.
> > >>I get the same problem on both b57 and b50g.
> > >>
> > >>https://glassfish.dev.java.net/issues/show_bug.cgi?id=1710
> > >>
> > >>Use telnet to block the connection
> > >>telnet localhost 8181
> > >>
> > >>Is anyone else getting this? I wanted to make sure here before I
> > >>reopened the issue.
> > >>
> > >>
> >
> > I'm not sure I'm able to reproduce the issue.
> >
> > Here's what I did:
> >
> > 1. telnet localhost <https-port>
> > 2. In parallel, access https://localhost:<https-port>/ from browser
> >
> > In 2., I was prompted to inspect the server's SSL cert, and after
> > accepting it,
> > the server's index.html page was served, as expected.
> >
> > I've tried this with the https listener's "blocking-enabled" attribute
> > set to
> > "true", and tried it again after restarting the server with this
> > attribute set to
> > "false". Either case worked fine for me.
> >
> > I've tried this with GlassFish v2 b57 on Solaris.
> >
> > Can you tell me if I've missed any steps in trying to reproduce the issue?
> >
> > Thanks,
> >
> >
> > Jan
> >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> > For additional commands, e-mail: users-help_at_glassfish.dev.java.net
> >
> >
>