You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Filip Hanik - Dev Lists <de...@hanik.com> on 2006/06/19 15:31:16 UTC
NIO Connector, please review
gents,
I've worked on an NIO connector, since the NIO and APR model can be/are
very similar, this is a fairly straightforward port.
I'd like for you to review and then continue this as work, as this would
allow me to have Comet support without the need for native libraries.
After review, please suggest where I can continue the work, trunk or
sandbox?
If the attachments don't make it, here is a link
http://www.halosg.com/connectors.zip
This is not worked completed, but working, I wanna see if I can make
optimizations, and of course, SSL support
thanks
Filip
--
Filip Hanik
Re: NIO Connector, please review
Posted by de...@hanik.com.
I would love to backport it to Tc5.5 and that way also have Comet support
in tc5.5.x
Filip
> +1 - I'm also working on a nio connector ( it is in sandbox ), but the
> goals
> are quite different,
> I want to have it simpler and smaller than the apr model. I think
> old-style
> connector
> should be deprecated, since JDK1.5 is now required there is no point in
> having it.
>
> ( I assume this is intended for tomcat6 ? It could be backported to 5.x,
> but
> I'm not sure it's a good idea)
>
> Costin
>
> On 6/19/06, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
>>
>> gents,
>> I've worked on an NIO connector, since the NIO and APR model can be/are
>> very similar, this is a fairly straightforward port.
>> I'd like for you to review and then continue this as work, as this would
>> allow me to have Comet support without the need for native libraries.
>> After review, please suggest where I can continue the work, trunk or
>> sandbox?
>>
>> If the attachments don't make it, here is a link
>> http://www.halosg.com/connectors.zip
>>
>> This is not worked completed, but working, I wanna see if I can make
>> optimizations, and of course, SSL support
>>
>> thanks
>> Filip
>>
>> --
>>
>>
>> Filip Hanik
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Mladen Turk <mt...@apache.org>.
Costin Manolache wrote:
> On 6/19/06, Mladen Turk <mt...@apache.org> wrote:
>
> I agree - it's good to have a single codebase !
>
> But I strongly disagree that we should have one big bloated release that
> includes
> everything in the codebase.
>
Look, all that I'm saying is that the code that is
inside /tc6.0.x/trunk/ should always compile before
any release, and that we do not 'componetisize' that
code base. We can have as many builds with various
parts from that code base as we wish, but not as
an independent modules in a sense of being able
to work with previous versions released.
Anything else should IMHO go outside that tree, like
jasper, commons, etc.. (as we do nowadays after all).
If there is a need to make something completely
independent of the core build, then this must not be the
part of the core itself thought.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Costin Manolache <co...@gmail.com>.
On 6/19/06, Mladen Turk <mt...@apache.org> wrote:
>
> Costin Manolache wrote:
> >
> > Of course - all stuff must compile at least - but I don't think it's a
> > reasonable
> > requirement to have all modules or other things that are not part of
> tomcat
> > tested in order to do a release.
> >
>
> But in that case, they could not be the part of the Tomcat code.
> If you think that we can release the clustering independently of
> the Tomcat, then it's a separate project that only uses Tomcat,
> and it is not part of it. The same applies to any other 'module'.
What do you mean ? Tomcat code ( i.e. whatever modules the tomcat pmc
maintains ) can include multiple componets, as long as they are within the
scope. Admin, cluster, etc are closely related with tomcat - I don't think
you
are arguing that they are not in the project scope.
Tomcat code includes all the files in all svn repositories - and we can pick
and chose what we release and how.
Yes, the cluster/admin/etc can live on sourceforge or a separate apache
project, but
it's our choice if we want it in tomcat codebase, and how to release it.
The thing I like with TC6 is that it treats its codebase as an
> entity. Having separate independent 'modules' makes it even
> worse compared with the current stuff we have.
I agree - it's good to have a single codebase !
But I strongly disagree that we should have one big bloated release that
includes
everything in the codebase.
We can discuss what exactly makes the Tomcat. If it's not the
> Clustering or Admin or what ever, then they'll need to be the
> separate projects that 'use Tomcat', and then and only then,
> we can version them separately.
There is no requirement for a source file to be in a separate svn module
or tree, or even separate project in order to have it's own separate release
version and cycle.
You can have files in the svn that are not included in the release, you can
have
files that are used in a different release, you can have multiple labels.
There are many apache projects that release more than one thing, and code
organization ( as svn repositories or source trees ) is orthogonal to
release content
and organization.
( and there is no rule that a release of cluster or admin must support only
the last
version of tomcat - but that's yet-another independent issue )
Costin
Re: NIO Connector, please review
Posted by Mladen Turk <mt...@apache.org>.
Costin Manolache wrote:
>
> Of course - all stuff must compile at least - but I don't think it's a
> reasonable
> requirement to have all modules or other things that are not part of tomcat
> tested in order to do a release.
>
But in that case, they could not be the part of the Tomcat code.
If you think that we can release the clustering independently of
the Tomcat, then it's a separate project that only uses Tomcat,
and it is not part of it. The same applies to any other 'module'.
The thing I like with TC6 is that it treats its codebase as an
entity. Having separate independent 'modules' makes it even
worse compared with the current stuff we have.
We can discuss what exactly makes the Tomcat. If it's not the
Clustering or Admin or what ever, then they'll need to be the
separate projects that 'use Tomcat', and then and only then,
we can version them separately.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Costin Manolache <co...@gmail.com>.
On 6/19/06, Mladen Turk <mt...@apache.org> wrote:
>
> Costin Manolache wrote:
> >
> > I don't see the benefit of having things like cluster support in the
> tomcat
> > release -
> > if someone does want a cluster, they can easily download an additional
> > jar -
> > setting
> > up a cluster involves a lot of work, we won't make it much simpler by
> > bundling the jar with
> > tomcat.
> >
>
> Well, I agree with you. We can have a build like:
> ant core, ant clustering, etc... No problem with that.
> What I'm saying is that if the clustering is broken,
> we should not have an release. First of all the release
> requires a SVN tag, and just imagine if someone wishes
> to create a build for some tagged release, and some
> 'module' is broken. It's simply confusing.
The tomcat release has a SVN tag - and the release includes all
the tomcat files. Cluster and other modules can be broken - and can
be released later, with their own SVN release tags.
Of course - all stuff must compile at least - but I don't think it's a
reasonable
requirement to have all modules or other things that are not part of tomcat
tested in order to do a release.
Costin
Re: NIO Connector, please review
Posted by Mladen Turk <mt...@apache.org>.
Costin Manolache wrote:
>
> I don't see the benefit of having things like cluster support in the tomcat
> release -
> if someone does want a cluster, they can easily download an additional
> jar -
> setting
> up a cluster involves a lot of work, we won't make it much simpler by
> bundling the jar with
> tomcat.
>
Well, I agree with you. We can have a build like:
ant core, ant clustering, etc... No problem with that.
What I'm saying is that if the clustering is broken,
we should not have an release. First of all the release
requires a SVN tag, and just imagine if someone wishes
to create a build for some tagged release, and some
'module' is broken. It's simply confusing.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Costin Manolache <co...@gmail.com>.
On 6/19/06, Mladen Turk <mt...@apache.org> wrote:
>
> Costin Manolache wrote:
> >
> > By modules/ I mean mostly release units - so maybe a build.xml to create
> > build and package the module, some readme, manifest,
> etc. Tomcat normal
> > release wouldn't include the module, but it can be released
> independently,
> > maybe
> > for multiple versions of tomcat.
> >
>
> Look, if someone is willing to break the build it will do it
> no mater what. Like said, having multiple builds is fine with
> me, but having multiple builds just for the sake of some broken
> module is not. If the module is part of the Tomcat, then there
> can be no release if its build fails. It is just the same as
> for the Httpd etc.
This is not an issue of 'broken build', it's an issue of release units
and lifecycle.
A module release cycle should not block the release of tomcat - it's just an
optional add-on that has it's own life and version number.
Also, I see no purpose of backporting the modules separately
> to the previous versions. If we have a product, then we can
> either provide the patch to the previous version as a whole,
> or simply say to the people to use the current stable version.
> If the patch will only relate to the module A, then it will
> be treated as a patch to the Tomcat6.x.y no to the module A
> for the Tomcat6.x.y. IMHO that'll be less confusing to the
> end users.
Ok. That's a separate issue as well, sorry for mixing it up.
What I would like is for tomcat6 release to not include all possible
features.
Maybe for backward compatibility we need to include all that tomcat5
includes,
maybe we can move out some large ones or things that are still
refactored ( like cluster support ).
I don't see the benefit of having things like cluster support in the tomcat
release -
if someone does want a cluster, they can easily download an additional jar -
setting
up a cluster involves a lot of work, we won't make it much simpler by
bundling the jar with
tomcat.
Costin
Re: NIO Connector, please review
Posted by Mladen Turk <mt...@apache.org>.
Costin Manolache wrote:
>
> By modules/ I mean mostly release units - so maybe a build.xml to create
> build and package the module, some readme, manifest, etc. Tomcat normal
> release wouldn't include the module, but it can be released independently,
> maybe
> for multiple versions of tomcat.
>
Look, if someone is willing to break the build it will do it
no mater what. Like said, having multiple builds is fine with
me, but having multiple builds just for the sake of some broken
module is not. If the module is part of the Tomcat, then there
can be no release if its build fails. It is just the same as
for the Httpd etc.
Also, I see no purpose of backporting the modules separately
to the previous versions. If we have a product, then we can
either provide the patch to the previous version as a whole,
or simply say to the people to use the current stable version.
If the patch will only relate to the module A, then it will
be treated as a patch to the Tomcat6.x.y no to the module A
for the Tomcat6.x.y. IMHO that'll be less confusing to the
end users.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Costin Manolache <co...@gmail.com>.
On 6/19/06, Mladen Turk <mt...@apache.org> wrote:
>
> Costin Manolache wrote:
> > Maybe create a modules/ under tomcat6 - with the definition 'stuff that
> can
> > be
> > released independently, and may support older versions of tomcat as
> well'
> > Or just 'can be released independently'.
> >
>
> Hmm, I'm not very much in favor of that.
> If the 'module' is mature enough it commit frequency
> will be much lower then the rest of the project,
> and thats it. IMHO TC6 should be maintained as an
> entity. We can have multiple builds of course;
> light, medium, full, etc.. but the code should be
> once and for all in the common tree.
> It would require more responsibility from all the
> commiters, not to break other commiters code, but
> at the and of the day we should be OK with that.
I wasn't talking about code location - java code can still be in
the java/ directory, and should at least compile ( or be excluded in
the javac statement ).
By modules/ I mean mostly release units - so maybe a build.xml to create
build and package the module, some readme, manifest, etc. Tomcat normal
release wouldn't include the module, but it can be released independently,
maybe
for multiple versions of tomcat.
Costin
Re: NIO Connector, please review
Posted by Mladen Turk <mt...@apache.org>.
Costin Manolache wrote:
> Maybe create a modules/ under tomcat6 - with the definition 'stuff that can
> be
> released independently, and may support older versions of tomcat as well'
> Or just 'can be released independently'.
>
Hmm, I'm not very much in favor of that.
If the 'module' is mature enough it commit frequency
will be much lower then the rest of the project,
and thats it. IMHO TC6 should be maintained as an
entity. We can have multiple builds of course;
light, medium, full, etc.. but the code should be
once and for all in the common tree.
It would require more responsibility from all the
commiters, not to break other commiters code, but
at the and of the day we should be OK with that.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Costin Manolache <co...@gmail.com>.
On 6/19/06, Mladen Turk <mt...@apache.org> wrote:
>
> Costin Manolache wrote:
> >
> > What about finally creating tomcat-modules or tomcat-addons ( or any
> other
> > name ),
> > for stuff that is (more or less) tomcat version independent, or at least
> > works for
> > multiple recent versions, and can be released independently ?
> >
> > This way the cluster stuff would have a better home too.
> >
>
> Agreed, but that would probably lead to the same thing
> we already have, multiple connectors, etc..
> I think we can make some effort and better integrate the
> stuff, without going again to separation that would end
> up with confusing versions.
> The thing I like with TC6.X is that its entire functionality
> is integrated for the fist time.
Yes - that's why I jumped when I heard about having some stuff in j-t-c :-)
( the native code is still there actually, but I see an empty native in tc6
)
Maybe create a modules/ under tomcat6 - with the definition 'stuff that can
be
released independently, and may support older versions of tomcat as well'
Or just 'can be released independently'.
( the code can still be in java/ - or under modules, it doesn't matter as
long
as the actual realease of tomcat doesn't include it, and a separate release
of
the module can be made )
BTW - how is mod_ajp_proxy doing ?
Costin
Re: NIO Connector, please review
Posted by Mladen Turk <mt...@apache.org>.
Costin Manolache wrote:
>
> What about finally creating tomcat-modules or tomcat-addons ( or any other
> name ),
> for stuff that is (more or less) tomcat version independent, or at least
> works for
> multiple recent versions, and can be released independently ?
>
> This way the cluster stuff would have a better home too.
>
Agreed, but that would probably lead to the same thing
we already have, multiple connectors, etc..
I think we can make some effort and better integrate the
stuff, without going again to separation that would end
up with confusing versions.
The thing I like with TC6.X is that its entire functionality
is integrated for the fist time.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Costin Manolache <co...@gmail.com>.
On 6/19/06, Mladen Turk <mt...@apache.org> wrote:
>
> Costin Manolache wrote:
> > are quite different,
> > I want to have it simpler and smaller than the apr model. I think
> old-style
> > connector
> > should be deprecated, since JDK1.5 is now required there is no point in
> > having it.
> >
>
> Sorry for stealing the thread ;)
>
> What about old jk2 connectors found again in the tc6.x
> branch. I would hate to have multiple AJP flavors once again
> (except the transport layer dependent: JIO, NIO, APR)
I think jk2 was deprecated ( at least the native part ), and anything
specific to the native2
should be removed.
Can we once and for all remove those obsolete stuff or make
> some merge if something is missing?
+1
The mod_jk config generation stuff should not be the part
> of tc6.x branch (eventually a separate thing under tomcat-connectors),
> so that we have a single http core, ajp core, and stuff that is
> transport layer dependent. I would not be in favor to see multiple
> http protocol parsers, etc. It would only make the assurance for
> the RFC harder.
+1 - but now tomcat-connectors is a bit confusing in context of tomcat6,
where
the java code is branched.
What about finally creating tomcat-modules or tomcat-addons ( or any other
name ),
for stuff that is (more or less) tomcat version independent, or at least
works for
multiple recent versions, and can be released independently ?
This way the cluster stuff would have a better home too.
Costin
Re: NIO Connector, please review
Posted by Mladen Turk <mt...@apache.org>.
Costin Manolache wrote:
> are quite different,
> I want to have it simpler and smaller than the apr model. I think old-style
> connector
> should be deprecated, since JDK1.5 is now required there is no point in
> having it.
>
Sorry for stealing the thread ;)
What about old jk2 connectors found again in the tc6.x
branch. I would hate to have multiple AJP flavors once again
(except the transport layer dependent: JIO, NIO, APR)
Can we once and for all remove those obsolete stuff or make
some merge if something is missing?
The mod_jk config generation stuff should not be the part
of tc6.x branch (eventually a separate thing under tomcat-connectors),
so that we have a single http core, ajp core, and stuff that is
transport layer dependent. I would not be in favor to see multiple
http protocol parsers, etc. It would only make the assurance for
the RFC harder.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Costin Manolache <co...@gmail.com>.
+1 - I'm also working on a nio connector ( it is in sandbox ), but the goals
are quite different,
I want to have it simpler and smaller than the apr model. I think old-style
connector
should be deprecated, since JDK1.5 is now required there is no point in
having it.
( I assume this is intended for tomcat6 ? It could be backported to 5.x, but
I'm not sure it's a good idea)
Costin
On 6/19/06, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
>
> gents,
> I've worked on an NIO connector, since the NIO and APR model can be/are
> very similar, this is a fairly straightforward port.
> I'd like for you to review and then continue this as work, as this would
> allow me to have Comet support without the need for native libraries.
> After review, please suggest where I can continue the work, trunk or
> sandbox?
>
> If the attachments don't make it, here is a link
> http://www.halosg.com/connectors.zip
>
> This is not worked completed, but working, I wanna see if I can make
> optimizations, and of course, SSL support
>
> thanks
> Filip
>
> --
>
>
> Filip Hanik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
Re: NIO Connector, please review
Posted by Costin Manolache <co...@gmail.com>.
On 6/22/06, Remy Maucherat <re...@apache.org> wrote:
>
> Filip Hanik - Dev Lists wrote:
> > Ok, I have a non SSL enabled Java NIO connector created and checked in.
> > It works in the exact way as APR, meaning it blocks on read and write,
> > So its no true NIO, but close enough to handle comet style traffic, and
> > to increase the connection count without increasing thread count.
>
> I really see no usefulness in such a connector (even if it did work).
> The one and only benefit is that you get to use the JVM native vendor
> network proprietary code rather than the ASF open source code. Really
> cool :)
We also use JVM native code for java.lang, and in the old java.io connector
:-)
NIO code is open source as well - Classpath includes a decent
implementation.
The benefit is that nio, even if lower performance than APR, is part of the
jre and so it's slightly easier to use.
I think after the NIO connector is stable we should start deprecating the
old java.io connector.
Costin
UNSUBSCRIBE PLEASE..............................
Posted by hamood rehman <ha...@hotmail.com>.
>From: Filip Hanik - Dev Lists <de...@hanik.com>
>Reply-To: "Tomcat Developers List" <de...@tomcat.apache.org>
>To: Tomcat Developers List <de...@tomcat.apache.org>
>Subject: Re: NIO Connector, please review
>Date: Thu, 22 Jun 2006 11:25:59 -0500
>
>Remy Maucherat wrote:
>>Filip Hanik - Dev Lists wrote:
>>>Alright, fixed, my last night checkin, the one I was unable to diff,
>>>caused the problem, I have reverted that one, and the Connector since we
>>>can use the fully qualified classname here.
>>
>>I am able to diff to see what got fixed, and it's trivial: all requests
>>were processed as Comet events.
>yup, noticed that when I ran it in a debugger, I wanted to consolidate the
>two processSocket method into one, i did it wrong.
>
>Filip
>
>
>--
>
>
>Filip Hanik
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO vs BIO speed
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
https://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?view=log
https://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?view=log
https://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java?view=log
https://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java?view=log
https://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java?view=log
Dakota Jack wrote:
> I am interested in this code. Is there a way I can see the code? Thanks.
>
>
>
> On 6/22/06, *Filip Hanik - Dev Lists* <devlists@hanik.com
> <ma...@hanik.com>> wrote:
>
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>>> Here is another test that I ran from a remote machine, setting
>>> maxThreads="25" and ab concurrency to 50 and keepalive on.
>>> In this case, NIO is a lot faster. Turn off keepalive on ab, and
>>> we get similar results to previous run, where BIO is a tad faster.
>>
>> Scaling the thread per connection model is done by increasing the
>> amount of threads. This particular test demonstrates the obvious.
> yes, what is interesting though, is my NIO connector is not really
> true NIO, as it ties up a thread while polling for data. The true
> implementation would have not invoked that thread yet, but for
> that I would have had to rewritten the connector from scratch as I
> couldn't have taken advantage of code already written and tested.
> The reason it was done like this, is cause that way I could use
> almost all the code from the APR connector.
> So you could call it a semi-"thread-per-connection" model, yet
> handles better than the true thread per connection model.
> APR does the same thing.
>
>
>>
>> If I understand the results correctly, the results would be
>> acceptable on Unix.
> yes, I think they are looking pretty good. And I am fairly
> confident in this new code, as most of it, is old tested APR code.
>
> Filip
>
> --
>
>
> Filip Hanik
>
>
>
>
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.9.2/372 - Release Date: 6/21/2006
>
--
Filip Hanik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO vs BIO speed
Posted by Dakota Jack <da...@gmail.com>.
I am interested in this code. Is there a way I can see the code? Thanks.
On 6/22/06, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
>
> Remy Maucherat wrote:
>
> Filip Hanik - Dev Lists wrote:
>
> Here is another test that I ran from a remote machine, setting
> maxThreads="25" and ab concurrency to 50 and keepalive on.
> In this case, NIO is a lot faster. Turn off keepalive on ab, and we get
> similar results to previous run, where BIO is a tad faster.
>
>
> Scaling the thread per connection model is done by increasing the amount
> of threads. This particular test demonstrates the obvious.
>
> yes, what is interesting though, is my NIO connector is not really true
> NIO, as it ties up a thread while polling for data. The true implementation
> would have not invoked that thread yet, but for that I would have had to
> rewritten the connector from scratch as I couldn't have taken advantage of
> code already written and tested.
> The reason it was done like this, is cause that way I could use almost all
> the code from the APR connector.
> So you could call it a semi-"thread-per-connection" model, yet handles
> better than the true thread per connection model.
> APR does the same thing.
>
>
>
> If I understand the results correctly, the results would be acceptable on
> Unix.
>
> yes, I think they are looking pretty good. And I am fairly confident in
> this new code, as most of it, is old tested APR code.
>
> Filip
>
> --
>
>
> Filip Hanik
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: NIO vs BIO speed
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> I haven't tested Filip's connector yet, but that's also my experience with
> the AJP/NIO connector: NIO is pretty much useless on Windows.
That's what I see, then, but it's not what Sun says.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: NIO vs BIO speed
Posted by Bill Barker <wb...@wilshire.com>.
I haven't tested Filip's connector yet, but that's also my experience with
the AJP/NIO connector: NIO is pretty much useless on Windows.
> -----Original Message-----
> From: Remy Maucherat [mailto:remm@apache.org]
> Sent: Monday, June 26, 2006 4:58 AM
> To: Tomcat Developers List
> Subject: Re: NIO vs BIO speed
>
> Filip Hanik - Dev Lists wrote:
> > yes, I think they are looking pretty good. And I am fairly
> confident in
> > this new code, as most of it, is old tested APR code.
>
> (Of course, there hasn't been any new changes, so it's not a
> surprise it
> not working any better for me; I did reboot in the meantime,
> though, and
> I am running JRE 1.5.0_06)
>
> Performance with NIO is still bad for me (3 times slower than
> the other
> connectors) with /usr/sbin/ab.exe -n 5000 -c 20 -k
> http://127.0.0.1:8081/tomcat.gif. Throughput seems to vary
> wildly during
> the test. With /usr/sbin/ab.exe -n 5000 -c 20
> http://127.0.0.1:8081/tomcat.gif (no keepalive), performance is
> horrible, and kills the poller thread after a few hundred iterations
> with the exception I reported earlier:
> Exception in thread "http-8081-Poller-0"
> java.lang.NullPointerException
> at
> sun.nio.ch.WindowsSelectorImpl$FdMap.remove(Unknown Source)
> at
> sun.nio.ch.WindowsSelectorImpl$FdMap.access$3000(Unknown Source)
> at sun.nio.ch.WindowsSelectorImpl.implDereg(Unknown Source)
> at
> sun.nio.ch.SelectorImpl.processDeregisterQueue(Unknown Source)
> at sun.nio.ch.WindowsSelectorImpl.doSelect(Unknown Source)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)
> at sun.nio.ch.SelectorImpl.select(Unknown Source)
> at
> org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.
> java:1189)
> at java.lang.Thread.run(Unknown Source)
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO vs BIO speed
Posted by de...@hanik.com.
man that sucks,
I can run the same tests, even hundred thousand iterations, I get a little
worse performance than the blocking connector and a little better than the
APR connector, and it never crashes for me.
I'm in dublin at apachecon this week, but will continue as soon I get back,
have a good week!
> Filip Hanik - Dev Lists wrote:
>> yes, I think they are looking pretty good. And I am fairly confident in
>> this new code, as most of it, is old tested APR code.
>
> (Of course, there hasn't been any new changes, so it's not a surprise it
> not working any better for me; I did reboot in the meantime, though, and
> I am running JRE 1.5.0_06)
>
> Performance with NIO is still bad for me (3 times slower than the other
> connectors) with /usr/sbin/ab.exe -n 5000 -c 20 -k
> http://127.0.0.1:8081/tomcat.gif. Throughput seems to vary wildly during
> the test. With /usr/sbin/ab.exe -n 5000 -c 20
> http://127.0.0.1:8081/tomcat.gif (no keepalive), performance is
> horrible, and kills the poller thread after a few hundred iterations
> with the exception I reported earlier:
> Exception in thread "http-8081-Poller-0" java.lang.NullPointerException
> at sun.nio.ch.WindowsSelectorImpl$FdMap.remove(Unknown Source)
> at sun.nio.ch.WindowsSelectorImpl$FdMap.access$3000(Unknown
> Source)
> at sun.nio.ch.WindowsSelectorImpl.implDereg(Unknown Source)
> at sun.nio.ch.SelectorImpl.processDeregisterQueue(Unknown Source)
> at sun.nio.ch.WindowsSelectorImpl.doSelect(Unknown Source)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)
> at sun.nio.ch.SelectorImpl.select(Unknown Source)
> at
> org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1189)
> at java.lang.Thread.run(Unknown Source)
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO vs BIO speed
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> yes, I think they are looking pretty good. And I am fairly confident in
> this new code, as most of it, is old tested APR code.
(Of course, there hasn't been any new changes, so it's not a surprise it
not working any better for me; I did reboot in the meantime, though, and
I am running JRE 1.5.0_06)
Performance with NIO is still bad for me (3 times slower than the other
connectors) with /usr/sbin/ab.exe -n 5000 -c 20 -k
http://127.0.0.1:8081/tomcat.gif. Throughput seems to vary wildly during
the test. With /usr/sbin/ab.exe -n 5000 -c 20
http://127.0.0.1:8081/tomcat.gif (no keepalive), performance is
horrible, and kills the poller thread after a few hundred iterations
with the exception I reported earlier:
Exception in thread "http-8081-Poller-0" java.lang.NullPointerException
at sun.nio.ch.WindowsSelectorImpl$FdMap.remove(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl$FdMap.access$3000(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl.implDereg(Unknown Source)
at sun.nio.ch.SelectorImpl.processDeregisterQueue(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl.doSelect(Unknown Source)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)
at sun.nio.ch.SelectorImpl.select(Unknown Source)
at
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1189)
at java.lang.Thread.run(Unknown Source)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO vs BIO speed
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Here is another test that I ran from a remote machine, setting
>> maxThreads="25" and ab concurrency to 50 and keepalive on.
>> In this case, NIO is a lot faster. Turn off keepalive on ab, and we
>> get similar results to previous run, where BIO is a tad faster.
>
> Scaling the thread per connection model is done by increasing the
> amount of threads. This particular test demonstrates the obvious.
yes, what is interesting though, is my NIO connector is not really true
NIO, as it ties up a thread while polling for data. The true
implementation would have not invoked that thread yet, but for that I
would have had to rewritten the connector from scratch as I couldn't
have taken advantage of code already written and tested.
The reason it was done like this, is cause that way I could use almost
all the code from the APR connector.
So you could call it a semi-"thread-per-connection" model, yet handles
better than the true thread per connection model.
APR does the same thing.
>
> If I understand the results correctly, the results would be acceptable
> on Unix.
yes, I think they are looking pretty good. And I am fairly confident in
this new code, as most of it, is old tested APR code.
Filip
--
Filip Hanik
Re: NIO vs BIO speed
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> Here is another test that I ran from a remote machine, setting
> maxThreads="25" and ab concurrency to 50 and keepalive on.
> In this case, NIO is a lot faster. Turn off keepalive on ab, and we get
> similar results to previous run, where BIO is a tad faster.
Scaling the thread per connection model is done by increasing the amount
of threads. This particular test demonstrates the obvious.
If I understand the results correctly, the results would be acceptable
on Unix.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO vs BIO speed
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Here is another test that I ran from a remote machine, setting
maxThreads="25" and ab concurrency to 50 and keepalive on.
In this case, NIO is a lot faster. Turn off keepalive on ab, and we get
similar results to previous run, where BIO is a tad faster.
[filip@fedora4 bin]$ ./ab -n 20000 -k -c 50
http://192.168.3.105:8080/tomcat.gif (BIO)
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation,
http://www.apache.org/
Benchmarking 192.168.3.105 (be patient)
Completed 2000 requests
Completed 4000 requests
Completed 6000 requests
Completed 8000 requests
Completed 10000 requests
Completed 12000 requests
Completed 14000 requests
Completed 16000 requests
Completed 18000 requests
Finished 20000 requests
Server Software: Apache-Coyote/1.1
Server Hostname: 192.168.3.105
Server Port: 8080
Document Path: /tomcat.gif
Document Length: 1934 bytes
Concurrency Level: 50
Time taken for tests: 7.41056 seconds
Complete requests: 20000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 10028
Total transferred: 43239331 bytes
HTML transferred: 38687126 bytes
Requests per second: 2840.48 [#/sec] (mean)
Time per request: 17.603 [ms] (mean)
Time per request: 0.352 [ms] (mean, across all concurrent requests)
Transfer rate: 5996.97 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 5 22.1 0 3009
Processing: 0 11 5.8 11 273
Waiting: 0 10 5.4 11 226
Total: 0 16 22.9 16 3027
Percentage of the requests served within a certain time (ms)
50% 16
66% 21
75% 23
80% 24
90% 26
95% 28
98% 30
99% 32
100% 3027 (longest request)
[filip@fedora4 bin]$ ./ab -n 20000 -k -c 50
http://192.168.3.105:8081/tomcat.gif
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation,
http://www.apache.org/
Benchmarking 192.168.3.105 (be patient)
Completed 2000 requests
Completed 4000 requests
Completed 6000 requests
Completed 8000 requests
Completed 10000 requests
Completed 12000 requests
Completed 14000 requests
Completed 16000 requests
Completed 18000 requests
Finished 20000 requests
Server Software: Apache-Coyote/1.1
Server Hostname: 192.168.3.105
Server Port: 8081
Document Path: /tomcat.gif
Document Length: 1934 bytes
Concurrency Level: 50
Time taken for tests: 5.526996 seconds
Complete requests: 20000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 20000
Total transferred: 43281248 bytes
HTML transferred: 38681018 bytes
Requests per second: 3618.60 [#/sec] (mean)
Time per request: 13.817 [ms] (mean)
Time per request: 0.276 [ms] (mean, across all concurrent requests)
Transfer rate: 7647.19 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 3
Processing: 1 13 3.7 13 220
Waiting: 1 13 3.7 13 220
Total: 1 13 3.8 13 220
Percentage of the requests served within a certain time (ms)
50% 13
66% 14
75% 15
80% 16
90% 17
95% 19
98% 21
99% 22
100% 220 (longest request)
[filip@fedora4 bin]$
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO vs BIO speed
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Remy, can you run your tests again, are you still seeing a huge
>> difference?
>
> Obviously, you did not change anything.
yes, I changed from busy read to polling, I wasn't sure if you ran your
tests after that.
I've ran my tests both on Windows and on Fedora Core 4, same results on
both machines.
if the concurrency is lower than maxThreads, bio has between a 1-10% gain.
But as soon as the concurrency goes higher than maxThreads the nio
connector is way faster, in my case 66% faster.
In the concurrency>maxThreads, my NIO connector is slightly faster than
the APR connector as well.
Filip
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Filip Hanik
Re: NIO vs BIO speed
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> Remy, can you run your tests again, are you still seeing a huge difference?
Obviously, you did not change anything.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
NIO vs BIO speed
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
I've attached two test runs NIO vs BIO.
The results are very similar, in a regular scenario, blocking IO should
be a little bit faster, cause it doesn't have to poll, and then hand off
to a separate thread before reading.
Benefit of the NIO is of course that the number of open sockets are no
longer limited by thread count.
Remy, can you run your tests again, are you still seeing a huge difference?
thanks
Filip
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>>> That's unfortunate. So regular is better? What are they doing with
>>> Grizzly?
>> no, its me :)
>> I need to come up with a non cpu sucking wait algorithm for the wait.
>>
>> once that is fixed, the performance should be close to identical
>
> For some reason, the performance went down further for me with that
> patch (although I noticed the CPU is being used properly this time,
> while before Tomcat was not using all the CPU available).
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Filip Hanik
Re: NIO Connector, please review
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>>> That's unfortunate. So regular is better? What are they doing with
>>> Grizzly?
>> no, its me :)
>> I need to come up with a non cpu sucking wait algorithm for the wait.
>>
>> once that is fixed, the performance should be close to identical
>
> For some reason, the performance went down further for me with that
> patch (although I noticed the CPU is being used properly this time,
> while before Tomcat was not using all the CPU available).
that's strange, mine went up to the same level as the java.io connector,
I'm not completely done with it though.
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Filip Hanik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
>> That's unfortunate. So regular is better? What are they doing with
>> Grizzly?
> no, its me :)
> I need to come up with a non cpu sucking wait algorithm for the wait.
>
> once that is fixed, the performance should be close to identical
For some reason, the performance went down further for me with that
patch (although I noticed the CPU is being used properly this time,
while before Tomcat was not using all the CPU available).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Jess Holle wrote:
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>>> Remy Maucherat wrote:
>>>> Filip Hanik - Dev Lists wrote:
>>>>> Alright, fixed, my last night checkin, the one I was unable to
>>>>> diff, caused the problem, I have reverted that one, and the
>>>>> Connector since we can use the fully qualified classname here.
>>>>
>>>> I am able to diff to see what got fixed, and it's trivial: all
>>>> requests were processed as Comet events.
>>> yup, noticed that when I ran it in a debugger, I wanted to
>>> consolidate the two processSocket method into one, i did it wrong.
>> I can confirm it now works. The two methods are fundamentally
>> different, and one of them was actually named processSocketEvent
>> until I changed it back to processSocket.
>>
>> However, the throughput is very bad at the moment (/usr/sbin/ab.exe
>> -n 20000 -c 10 -k http://127.0.0.1:8081/tomcat.gif):
>> 800 req/s (with keepalive actually working) vs 6000+ for regular
>> java.io.
> That's unfortunate. So regular is better? What are they doing with
> Grizzly?
no, its me :)
I need to come up with a non cpu sucking wait algorithm for the wait.
once that is fixed, the performance should be close to identical
Filip
>
> --
> Jess Holle
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Filip Hanik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Remy Maucherat wrote:
>>> Filip Hanik - Dev Lists wrote:
>>>> Alright, fixed, my last night checkin, the one I was unable to
>>>> diff, caused the problem, I have reverted that one, and the
>>>> Connector since we can use the fully qualified classname here.
>>>
>>> I am able to diff to see what got fixed, and it's trivial: all
>>> requests were processed as Comet events.
>> yup, noticed that when I ran it in a debugger, I wanted to
>> consolidate the two processSocket method into one, i did it wrong.
> I can confirm it now works. The two methods are fundamentally
> different, and one of them was actually named processSocketEvent until
> I changed it back to processSocket.
>
> However, the throughput is very bad at the moment (/usr/sbin/ab.exe -n
> 20000 -c 10 -k http://127.0.0.1:8081/tomcat.gif):
> 800 req/s (with keepalive actually working) vs 6000+ for regular java.io.
That's unfortunate. So regular is better? What are they doing with
Grizzly?
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>>> Alright, fixed, my last night checkin, the one I was unable to diff,
>>> caused the problem, I have reverted that one, and the Connector since
>>> we can use the fully qualified classname here.
>>
>> I am able to diff to see what got fixed, and it's trivial: all
>> requests were processed as Comet events.
> yup, noticed that when I ran it in a debugger, I wanted to consolidate
> the two processSocket method into one, i did it wrong.
I can confirm it now works. The two methods are fundamentally different,
and one of them was actually named processSocketEvent until I changed it
back to processSocket.
However, the throughput is very bad at the moment (/usr/sbin/ab.exe -n
20000 -c 10 -k http://127.0.0.1:8081/tomcat.gif):
800 req/s (with keepalive actually working) vs 6000+ for regular java.io.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Alright, fixed, my last night checkin, the one I was unable to diff,
>> caused the problem, I have reverted that one, and the Connector since
>> we can use the fully qualified classname here.
>
> I am able to diff to see what got fixed, and it's trivial: all
> requests were processed as Comet events.
yup, noticed that when I ran it in a debugger, I wanted to consolidate
the two processSocket method into one, i did it wrong.
Filip
--
Filip Hanik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> Alright, fixed, my last night checkin, the one I was unable to diff,
> caused the problem, I have reverted that one, and the Connector since we
> can use the fully qualified classname here.
I am able to diff to see what got fixed, and it's trivial: all requests
were processed as Comet events.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Filip Hanik - Dev Lists wrote:
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>>> I did, just check
>>> http://marc.theaimsgroup.com/?l=tomcat-dev&m=115064982127403&w=2
>>> In terms of negativity, not sure where your head is at, but there is
>>> none here.
>>
>> This was quite a subtle mention. The plan is that the socket will not
>> get destroyed and deallocated before the error method of the servlet
>> is called. If this is indeed done properly, then it is the
>> application's fault and the Java code should not change. At the same
>> time, I would like to get more robustness and add code for that in
>> the native code, because in a very similar way, it is currently
>> possible to crash Tomcat with APR using Java2D, which writes stuff
>> asynchronously when finalizing its objects.
> yes, and I offered to help track these down and will do so.
>>
>>>> I quickly tested your NIO connector, and on Windows, it closes the
>>>> connection after getting the first byte. I didn't have time to test
>>>> further.
>>> Really, I ran through a large set of tests here and they all worked
>>> fine, both chunked encoding and content length based data.
>>
>> I am not able to get any requests served at all right now (as I said,
>> using a telnet, the connection gets closed without an error being
>> logged after getting the first byte), while the other connectors work
>> fine. The configuration is:
>>
>> <Connector port="8080" />
>>
>> <Connector port="8081"
>> protocol="org.apache.coyote.http11.Http11NioProtocol" />
>>
>> <Connector port="8082"
>> protocol="org.apache.coyote.http11.Http11Protocol" />
> ok, lemme get on that one
Alright, fixed, my last night checkin, the one I was unable to diff,
caused the problem, I have reverted that one, and the Connector since we
can use the fully qualified classname here.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> I did, just check
>> http://marc.theaimsgroup.com/?l=tomcat-dev&m=115064982127403&w=2
>> In terms of negativity, not sure where your head is at, but there is
>> none here.
>
> This was quite a subtle mention. The plan is that the socket will not
> get destroyed and deallocated before the error method of the servlet
> is called. If this is indeed done properly, then it is the
> application's fault and the Java code should not change. At the same
> time, I would like to get more robustness and add code for that in the
> native code, because in a very similar way, it is currently possible
> to crash Tomcat with APR using Java2D, which writes stuff
> asynchronously when finalizing its objects.
yes, and I offered to help track these down and will do so.
>
>>> I quickly tested your NIO connector, and on Windows, it closes the
>>> connection after getting the first byte. I didn't have time to test
>>> further.
>> Really, I ran through a large set of tests here and they all worked
>> fine, both chunked encoding and content length based data.
>
> I am not able to get any requests served at all right now (as I said,
> using a telnet, the connection gets closed without an error being
> logged after getting the first byte), while the other connectors work
> fine. The configuration is:
>
> <Connector port="8080" />
>
> <Connector port="8081"
> protocol="org.apache.coyote.http11.Http11NioProtocol" />
>
> <Connector port="8082"
> protocol="org.apache.coyote.http11.Http11Protocol" />
ok, lemme get on that one
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Filip Hanik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> I did, just check
> http://marc.theaimsgroup.com/?l=tomcat-dev&m=115064982127403&w=2
> In terms of negativity, not sure where your head is at, but there is
> none here.
This was quite a subtle mention. The plan is that the socket will not
get destroyed and deallocated before the error method of the servlet is
called. If this is indeed done properly, then it is the application's
fault and the Java code should not change. At the same time, I would
like to get more robustness and add code for that in the native code,
because in a very similar way, it is currently possible to crash Tomcat
with APR using Java2D, which writes stuff asynchronously when finalizing
its objects.
>> I quickly tested your NIO connector, and on Windows, it closes the
>> connection after getting the first byte. I didn't have time to test
>> further.
> Really, I ran through a large set of tests here and they all worked
> fine, both chunked encoding and content length based data.
I am not able to get any requests served at all right now (as I said,
using a telnet, the connection gets closed without an error being logged
after getting the first byte), while the other connectors work fine. The
configuration is:
<Connector port="8080" />
<Connector port="8081"
protocol="org.apache.coyote.http11.Http11NioProtocol" />
<Connector port="8082"
protocol="org.apache.coyote.http11.Http11Protocol" />
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> you gotta look at the glass as half full, not half empty :), it also
>> doesn't crash the VM when the client aborts the connection on a comet
>> request ;)
>
> I know of no crash problems. I think there's a very negative
> development atmosphere in the components you become involved with, I
> am not going to tolerate this for much longer. If you know of
> problems, and for example have debugged them, you should disclose them.
I did, just check
http://marc.theaimsgroup.com/?l=tomcat-dev&m=115064982127403&w=2
In terms of negativity, not sure where your head is at, but there is
none here.
>
> I quickly tested your NIO connector, and on Windows, it closes the
> connection after getting the first byte. I didn't have time to test
> further.
Really, I ran through a large set of tests here and they all worked
fine, both chunked encoding and content length based data.
>
> Rémy
Filip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Filip Hanik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> you gotta look at the glass as half full, not half empty :), it also
> doesn't crash the VM when the client aborts the connection on a comet
> request ;)
I know of no crash problems. I think there's a very negative development
atmosphere in the components you become involved with, I am not going to
tolerate this for much longer. If you know of problems, and for example
have debugged them, you should disclose them.
I quickly tested your NIO connector, and on Windows, it closes the
connection after getting the first byte. I didn't have time to test further.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Ok, I have a non SSL enabled Java NIO connector created and checked
>> in. It works in the exact way as APR, meaning it blocks on read and
>> write,
>> So its no true NIO, but close enough to handle comet style traffic,
>> and to increase the connection count without increasing thread count.
>
> I really see no usefulness in such a connector (even if it did work).
> The one and only benefit is that you get to use the JVM native vendor
> network proprietary code rather than the ASF open source code. Really
> cool :)
you gotta look at the glass as half full, not half empty :), it also
doesn't crash the VM when the client aborts the connection on a comet
request ;)
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Filip Hanik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> Ok, I have a non SSL enabled Java NIO connector created and checked in.
> It works in the exact way as APR, meaning it blocks on read and write,
> So its no true NIO, but close enough to handle comet style traffic, and
> to increase the connection count without increasing thread count.
I really see no usefulness in such a connector (even if it did work).
The one and only benefit is that you get to use the JVM native vendor
network proprietary code rather than the ASF open source code. Really
cool :)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: NIO Connector, please review
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Ok, I have a non SSL enabled Java NIO connector created and checked in.
It works in the exact way as APR, meaning it blocks on read and write,
So its no true NIO, but close enough to handle comet style traffic, and
to increase the connection count without increasing thread count.
Filip
devlists@hanik.com wrote:
> let me fill in the other blanks,
> the connector will be modified so that it knows when it has enough data to
> proceed, ala, chunked encoding etc.
> that is still work to be done.
>
> but I wanted let you know how it conceptually could look similar to the
> APR connector, and how much of the code could be shared.
>
> Filip
>
>
>>>
>>>> -----Original Message-----
>>>> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
>>>> Sent: Monday, June 19, 2006 6:31 AM
>>>> To: Tomcat Developers List
>>>> Subject: NIO Connector, please review
>>>>
>>>> gents,
>>>> I've worked on an NIO connector, since the NIO and APR model
>>>> can be/are
>>>> very similar, this is a fairly straightforward port.
>>>> I'd like for you to review and then continue this as work, as
>>>> this would
>>>> allow me to have Comet support without the need for native libraries.
>>>> After review, please suggest where I can continue the work, trunk or
>>>> sandbox?
>>>>
>>>> If the attachments don't make it, here is a link
>>>> http://www.halosg.com/connectors.zip
>>>>
>>>> This is not worked completed, but working, I wanna see if I can make
>>>> optimizations, and of course, SSL support
>>>>
>>> I don't see how this could possibly work. You are using non-blocking
>>> sockets, but you consider it to be an error if readSocket returns false
>>> (when all it actually means is that the data hasn't arrived yet :).
>>>
>>> The APR Connector doesn't have this problem since it uses blocking
>>> sockets
>>> (for much this reason).
>>>
>> there is a discrepency, I need to fix the fill() method,
>> for the other methods, false means, return the socket to the poller, free
>> the thread and come back when you have more data. ala non blocking mode
>>
>> so there is some massaging to do, but they are not that different. And on
>> writing, it does busy loop until it flushed it all out to the os buffer.
>>
>>
>> Filip
>>
>>
>>>> thanks
>>>> Filip
>>>>
>>>> --
>>>>
>>>>
>>>> Filip Hanik
>>>>
>>>>
>>>
>>> This message is intended only for the use of the person(s) listed above
>>> as
>>> the intended recipient(s), and may contain information that is
>>> PRIVILEGED
>>> and CONFIDENTIAL. If you are not an intended recipient, you may not
>>> read,
>>> copy, or distribute this message or any attachment. If you received this
>>> communication in error, please notify us immediately by e-mail and then
>>> delete all copies of this message and any attachments.
>>>
>>> In addition you should be aware that ordinary (unencrypted) e-mail sent
>>> through the Internet is not secure. Do not send confidential or
>>> sensitive
>>> information, such as social security numbers, account numbers, personal
>>> identification numbers and passwords, to us via ordinary (unencrypted)
>>> e-mail.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Filip Hanik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: NIO Connector, please review
Posted by de...@hanik.com.
let me fill in the other blanks,
the connector will be modified so that it knows when it has enough data to
proceed, ala, chunked encoding etc.
that is still work to be done.
but I wanted let you know how it conceptually could look similar to the
APR connector, and how much of the code could be shared.
Filip
>>
>>
>>> -----Original Message-----
>>> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
>>> Sent: Monday, June 19, 2006 6:31 AM
>>> To: Tomcat Developers List
>>> Subject: NIO Connector, please review
>>>
>>> gents,
>>> I've worked on an NIO connector, since the NIO and APR model
>>> can be/are
>>> very similar, this is a fairly straightforward port.
>>> I'd like for you to review and then continue this as work, as
>>> this would
>>> allow me to have Comet support without the need for native libraries.
>>> After review, please suggest where I can continue the work, trunk or
>>> sandbox?
>>>
>>> If the attachments don't make it, here is a link
>>> http://www.halosg.com/connectors.zip
>>>
>>> This is not worked completed, but working, I wanna see if I can make
>>> optimizations, and of course, SSL support
>>
>> I don't see how this could possibly work. You are using non-blocking
>> sockets, but you consider it to be an error if readSocket returns false
>> (when all it actually means is that the data hasn't arrived yet :).
>>
>> The APR Connector doesn't have this problem since it uses blocking
>> sockets
>> (for much this reason).
>
> there is a discrepency, I need to fix the fill() method,
> for the other methods, false means, return the socket to the poller, free
> the thread and come back when you have more data. ala non blocking mode
>
> so there is some massaging to do, but they are not that different. And on
> writing, it does busy loop until it flushed it all out to the os buffer.
>
>
> Filip
>
>>
>>>
>>> thanks
>>> Filip
>>>
>>> --
>>>
>>>
>>> Filip Hanik
>>>
>>
>>
>>
>> This message is intended only for the use of the person(s) listed above
>> as
>> the intended recipient(s), and may contain information that is
>> PRIVILEGED
>> and CONFIDENTIAL. If you are not an intended recipient, you may not
>> read,
>> copy, or distribute this message or any attachment. If you received this
>> communication in error, please notify us immediately by e-mail and then
>> delete all copies of this message and any attachments.
>>
>> In addition you should be aware that ordinary (unencrypted) e-mail sent
>> through the Internet is not secure. Do not send confidential or
>> sensitive
>> information, such as social security numbers, account numbers, personal
>> identification numbers and passwords, to us via ordinary (unencrypted)
>> e-mail.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: NIO Connector, please review
Posted by de...@hanik.com.
So it uses NIO to increase concurrency, ie, have more connections open
than threads, same way as APR, but writing to the stream is not done non
blocking, it still follows the request/response/1-thread model
still lot of work to do
Filip
>>
>>
>>> -----Original Message-----
>>> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
>>> Sent: Monday, June 19, 2006 6:31 AM
>>> To: Tomcat Developers List
>>> Subject: NIO Connector, please review
>>>
>>> gents,
>>> I've worked on an NIO connector, since the NIO and APR model
>>> can be/are
>>> very similar, this is a fairly straightforward port.
>>> I'd like for you to review and then continue this as work, as
>>> this would
>>> allow me to have Comet support without the need for native libraries.
>>> After review, please suggest where I can continue the work, trunk or
>>> sandbox?
>>>
>>> If the attachments don't make it, here is a link
>>> http://www.halosg.com/connectors.zip
>>>
>>> This is not worked completed, but working, I wanna see if I can make
>>> optimizations, and of course, SSL support
>>
>> I don't see how this could possibly work. You are using non-blocking
>> sockets, but you consider it to be an error if readSocket returns false
>> (when all it actually means is that the data hasn't arrived yet :).
>>
>> The APR Connector doesn't have this problem since it uses blocking
>> sockets
>> (for much this reason).
>
> there is a discrepency, I need to fix the fill() method,
> for the other methods, false means, return the socket to the poller, free
> the thread and come back when you have more data. ala non blocking mode
>
> so there is some massaging to do, but they are not that different. And on
> writing, it does busy loop until it flushed it all out to the os buffer.
>
>
> Filip
>
>>
>>>
>>> thanks
>>> Filip
>>>
>>> --
>>>
>>>
>>> Filip Hanik
>>>
>>
>>
>>
>> This message is intended only for the use of the person(s) listed above
>> as
>> the intended recipient(s), and may contain information that is
>> PRIVILEGED
>> and CONFIDENTIAL. If you are not an intended recipient, you may not
>> read,
>> copy, or distribute this message or any attachment. If you received this
>> communication in error, please notify us immediately by e-mail and then
>> delete all copies of this message and any attachments.
>>
>> In addition you should be aware that ordinary (unencrypted) e-mail sent
>> through the Internet is not secure. Do not send confidential or
>> sensitive
>> information, such as social security numbers, account numbers, personal
>> identification numbers and passwords, to us via ordinary (unencrypted)
>> e-mail.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: NIO Connector, please review
Posted by de...@hanik.com.
>
>
>> -----Original Message-----
>> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
>> Sent: Monday, June 19, 2006 6:31 AM
>> To: Tomcat Developers List
>> Subject: NIO Connector, please review
>>
>> gents,
>> I've worked on an NIO connector, since the NIO and APR model
>> can be/are
>> very similar, this is a fairly straightforward port.
>> I'd like for you to review and then continue this as work, as
>> this would
>> allow me to have Comet support without the need for native libraries.
>> After review, please suggest where I can continue the work, trunk or
>> sandbox?
>>
>> If the attachments don't make it, here is a link
>> http://www.halosg.com/connectors.zip
>>
>> This is not worked completed, but working, I wanna see if I can make
>> optimizations, and of course, SSL support
>
> I don't see how this could possibly work. You are using non-blocking
> sockets, but you consider it to be an error if readSocket returns false
> (when all it actually means is that the data hasn't arrived yet :).
>
> The APR Connector doesn't have this problem since it uses blocking sockets
> (for much this reason).
there is a discrepency, I need to fix the fill() method,
for the other methods, false means, return the socket to the poller, free
the thread and come back when you have more data. ala non blocking mode
so there is some massaging to do, but they are not that different. And on
writing, it does busy loop until it flushed it all out to the os buffer.
Filip
>
>>
>> thanks
>> Filip
>>
>> --
>>
>>
>> Filip Hanik
>>
>
>
>
> This message is intended only for the use of the person(s) listed above as
> the intended recipient(s), and may contain information that is PRIVILEGED
> and CONFIDENTIAL. If you are not an intended recipient, you may not read,
> copy, or distribute this message or any attachment. If you received this
> communication in error, please notify us immediately by e-mail and then
> delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent
> through the Internet is not secure. Do not send confidential or sensitive
> information, such as social security numbers, account numbers, personal
> identification numbers and passwords, to us via ordinary (unencrypted)
> e-mail.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: NIO Connector, please review
Posted by Bill Barker <wb...@wilshire.com>.
> -----Original Message-----
> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com]
> Sent: Monday, June 19, 2006 6:31 AM
> To: Tomcat Developers List
> Subject: NIO Connector, please review
>
> gents,
> I've worked on an NIO connector, since the NIO and APR model
> can be/are
> very similar, this is a fairly straightforward port.
> I'd like for you to review and then continue this as work, as
> this would
> allow me to have Comet support without the need for native libraries.
> After review, please suggest where I can continue the work, trunk or
> sandbox?
>
> If the attachments don't make it, here is a link
> http://www.halosg.com/connectors.zip
>
> This is not worked completed, but working, I wanna see if I can make
> optimizations, and of course, SSL support
I don't see how this could possibly work. You are using non-blocking
sockets, but you consider it to be an error if readSocket returns false
(when all it actually means is that the data hasn't arrived yet :).
The APR Connector doesn't have this problem since it uses blocking sockets
(for much this reason).
>
> thanks
> Filip
>
> --
>
>
> Filip Hanik
>
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org