I am able to reproduce this problem using the steps that Kem has used
below. I have a dual core processor and when I run telnet over ssl on
windows the java process for glassfish immediately consumes 50% of my
processing power(indefinitely). I have been running an application on
glassfish v1 for 6 months now. I had to use the Coyote Connector instead of
grizzly because of this issue. It looks as if this issue still isn't
resolved in glassfish v2 and if it is not it will make grizzly unacceptable
for any application that needs to provide ssl support. After reproducing
this problem I then added the following jvm option -
Dcom.sun.enterprise.web.connector.useCoyoteConnector=true, which similar to
glassfish v1 fixed the problem. I will gladly provide any futher
information I can to assist in reproducing this issue.
Thanks.
Andy
On 8/6/07, Kem Elbrader <kem.elbrader_at_gmail.com> wrote:
>
> 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
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>