You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rainer Jung <rj...@apache.org> on 2006/12/06 23:26:42 UTC
mod_jk release preparation: ready for test
Hi,
I think Mladen and I completed our code change plans for the next
release of mod_jk. Since over all we had more changes than we expected
when we started for 1.2.20 I would like to give the opportunity of
testing, before I do the tagging. In case no show stoppers will be found
I suggest tagging late saturday, or early sunday, so that we can finish
the release vote during the next week.
I produced a source tarball with the usual release script. It contains
everything similar to a release except for the final version number and
the correct release dates in the release docs.
You can find it under:
http://people.apache.org/~rjung/mod_jk-1.2.20-dev/
There is a directory docs containing the reorganized and slightly
extended docs, a directory source containing the .tar.gz, .zip, the
signature and checksum files and finally an empty directory binaries,
which might be filled tomorrow by Mladen with Windows build(s).
I would really appreciate, if some of our long term mod_jk experts could
have a look at it.
Major changes:
- improved IIS 6 support (e.g. shm, thread counts
- improved virtual host support for apache, also documented
- reworked status worker (see new docs page)
- reorganized docs, new pages for uriworkermap.properties and status worker
Minor features:
- fail_on_status attribute
- rename jvm_route -> route (but code still works with old config)
- uriworkermap reload interval configurable
- max_packet_size documented
- new uriworkermap reload semantics (delete old uriworkermap entries
from internal list during reload)
- load balancer strategy "Sessions"
- more flushing options
BZ fixes:
- 36121: Don't change main uri when mod_jk serves included uri. (markt)
- 40966: Fix socket descriptor checks on windows. (mturk)
- 40965: Initialize missing service parameters. (mturk)
- 40938: Fix releasing of rewrite map. Thanks to Chris Adams for
spotting that. (mturk)
- 40856: Fixing case sensitivity bug in URL mapping. (rjung)
- 40793: Documentation: Improvements to Apache HowTo provided by Paul
Charles Leddy. (markt)
- 40774: Fixing wrong recursion termination. This one restricted the
"reference" feature unintentionally to 20 workers. (rjung)
- 40716: Adding "reference" feature to IIS and Netscape. (rjung)
Have fun,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
Good explanation since I wondering why the jkstatus didn't see my
JKMount directive.
In my case the jkstatus is defined in the httpd.conf (common) and the
JKMounts in all VHost.
It's a very common configuration since Web admins don't want to
redifine a jkstatus for each vhost.
>2006/12/16, Rainer Jung <rj...@apache.org>:
> Hi David,
>
> this message means, that no forwarding rules (=map) have been found for
> that worker. So no JkMount, mount attribute in workers.properties or
> uriworkermap.properties applies to that worker.
>
> Important: maps are associated to virtual hosts in apache. The status
> worker can only see those maps, that belong to the same virtual host, it
> has been called in. So if you add all your maps to a vhost for
> production use, and add a status worker on a separate vhost for admin
> use, this status worker will not be able to see the maps from the
> production vhost. If you want to inhertif maps from the global server to
> vhosts, you need to set JkMountCopy for the vhost. More about that in
> the updated Apache docs page (reference guide) and the new
> uriworkermap.properties page.
>
> Could that be the reason for the message?
>
> We might improve the situation concerning the status worker in the
> future, but making available all the maps to it will be a major
> refactoring in the jk code (for apache, IIS can already see all the maps).
>
> Regards,
>
> Rainer
>
> David Rees schrieb:
> > On 12/6/06, Rainer Jung <rj...@apache.org> wrote:
> >> - reworked status worker (see new docs page)
> >
> > On my status worker page, I get the message:
> >
> > Warning: No URI Mappings defined for <workername> !
> >
> > Otherwise, everything seems to work OK so far in my limited testing.
> >
> > -Dave
> >
> > ---------------------------------------------------------------------
> > 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: mod_jk release preparation: ready for test
Posted by David Rees <dr...@gmail.com>.
On 12/16/06, Rainer Jung <rj...@apache.org> wrote:
> Important: maps are associated to virtual hosts in apache. The status
> worker can only see those maps, that belong to the same virtual host, it
> has been called in. So if you add all your maps to a vhost for
> production use, and add a status worker on a separate vhost for admin
> use, this status worker will not be able to see the maps from the
> production vhost. If you want to inhertif maps from the global server to
> vhosts, you need to set JkMountCopy for the vhost. More about that in
> the updated Apache docs page (reference guide) and the new
> uriworkermap.properties page.
>
> Could that be the reason for the message?
As Henri mentioned, that appears to be exactly why I am seeing that
message, I was not using the same virtual host to view the jkstatus
page as the JkMount directives are issued.
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_jk release preparation: ready for test
Posted by Rainer Jung <rj...@apache.org>.
Hi David,
this message means, that no forwarding rules (=map) have been found for
that worker. So no JkMount, mount attribute in workers.properties or
uriworkermap.properties applies to that worker.
Important: maps are associated to virtual hosts in apache. The status
worker can only see those maps, that belong to the same virtual host, it
has been called in. So if you add all your maps to a vhost for
production use, and add a status worker on a separate vhost for admin
use, this status worker will not be able to see the maps from the
production vhost. If you want to inhertif maps from the global server to
vhosts, you need to set JkMountCopy for the vhost. More about that in
the updated Apache docs page (reference guide) and the new
uriworkermap.properties page.
Could that be the reason for the message?
We might improve the situation concerning the status worker in the
future, but making available all the maps to it will be a major
refactoring in the jk code (for apache, IIS can already see all the maps).
Regards,
Rainer
David Rees schrieb:
> On 12/6/06, Rainer Jung <rj...@apache.org> wrote:
>> - reworked status worker (see new docs page)
>
> On my status worker page, I get the message:
>
> Warning: No URI Mappings defined for <workername> !
>
> Otherwise, everything seems to work OK so far in my limited testing.
>
> -Dave
>
> ---------------------------------------------------------------------
> 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: mod_jk release preparation: ready for test
Posted by David Rees <dr...@gmail.com>.
On 12/6/06, Rainer Jung <rj...@apache.org> wrote:
> - reworked status worker (see new docs page)
On my status worker page, I get the message:
Warning: No URI Mappings defined for <workername> !
Otherwise, everything seems to work OK so far in my limited testing.
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
Thanks
2006/12/8, Rainer Jung <rj...@apache.org>:
> Mladen made a win build available in the meantime (thanks!). You can
> find it under
>
> http://people.apache.org/~rjung/mod_jk-1.2.20-dev/binaries/
>
> Regards,
>
> Rainer
>
>
> ---------------------------------------------------------------------
> 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: mod_jk release preparation: ready for test
Posted by Rainer Jung <rj...@apache.org>.
Mladen made a win build available in the meantime (thanks!). You can
find it under
http://people.apache.org/~rjung/mod_jk-1.2.20-dev/binaries/
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_jk release preparation: ready for test
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
> it's a seems to be a tomcat-native (1.1.7) problem
>
> And since we discuss Tomcat 6.0.4 release, should we consider that
> error as a show stopper ?
>
No. It works quite fine on Solaris and RHEL, as well on HP-UX
and Windows. I simply cannot reproduce this problem.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
It may be the native side who drop some bytes under some circumstances
(need more expertise about Java / Native link).
It will be usefull to get the Socket.sendbb() return code for further study.
2006/12/7, Bill Barker <wb...@wilshire.com>:
>
>
> > -----Original Message-----
> > From: Remy Maucherat [mailto:remm@apache.org]
> > Sent: Thursday, December 07, 2006 6:08 AM
> > To: Tomcat Developers List
> > Subject: Re: mod_jk release preparation: ready for test
> >
> > Henri Gomez wrote:
> > > it's a seems to be a tomcat-native (1.1.7) problem
> > >
> > > And since we discuss Tomcat 6.0.4 release, should we consider that
> > > error as a show stopper ?
> >
> > No. It existed before, and it is not known if it's a problem with the
> > Java code or not.
> >
> > What I see is that there's an IO exception here, so it means the send
> > call returned a status error (or maybe it returned one of these
> > mysterious codes which are an error but are not actually an error):
>
> From Henri's logs, what happened is that mod_jk didn't see 0x4142 as the
> first two bytes of the message, and so it dropped the connection to Tomcat.
> Don't know how that could happen, but that is what his logs say :).
>
> > protected void flush()
> > throws IOException {
> > if (outputBuffer.position() > 0) {
> > if (Socket.sendbb(socket, 0,
> > outputBuffer.position()) < 0) {
> > >> throw new IOException();
> > }
> > outputBuffer.clear();
> > }
> > }
> >
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: mod_jk release preparation: ready for test
Posted by Bill Barker <wb...@wilshire.com>.
> -----Original Message-----
> From: Remy Maucherat [mailto:remm@apache.org]
> Sent: Thursday, December 07, 2006 6:08 AM
> To: Tomcat Developers List
> Subject: Re: mod_jk release preparation: ready for test
>
> Henri Gomez wrote:
> > it's a seems to be a tomcat-native (1.1.7) problem
> >
> > And since we discuss Tomcat 6.0.4 release, should we consider that
> > error as a show stopper ?
>
> No. It existed before, and it is not known if it's a problem with the
> Java code or not.
>
> What I see is that there's an IO exception here, so it means the send
> call returned a status error (or maybe it returned one of these
> mysterious codes which are an error but are not actually an error):
From Henri's logs, what happened is that mod_jk didn't see 0x4142 as the
first two bytes of the message, and so it dropped the connection to Tomcat.
Don't know how that could happen, but that is what his logs say :).
> protected void flush()
> throws IOException {
> if (outputBuffer.position() > 0) {
> if (Socket.sendbb(socket, 0,
> outputBuffer.position()) < 0) {
> >> throw new IOException();
> }
> outputBuffer.clear();
> }
> }
>
> 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: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
Remy what about loging this error code ?
I suspect something not directly related to an error and having the
error code will be valuable.
2006/12/7, Remy Maucherat <re...@apache.org>:
> Henri Gomez wrote:
> > it's a seems to be a tomcat-native (1.1.7) problem
> >
> > And since we discuss Tomcat 6.0.4 release, should we consider that
> > error as a show stopper ?
>
> No. It existed before, and it is not known if it's a problem with the
> Java code or not.
>
> What I see is that there's an IO exception here, so it means the send
> call returned a status error (or maybe it returned one of these
> mysterious codes which are an error but are not actually an error):
> protected void flush()
> throws IOException {
> if (outputBuffer.position() > 0) {
> if (Socket.sendbb(socket, 0, outputBuffer.position()) < 0) {
> >> throw new IOException();
> }
> outputBuffer.clear();
> }
> }
>
> 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: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
it works well even when your servlet is pushing PDF data ?
Did a tcpdump/ethereal could help you ?
>2006/12/7, Henri Gomez <he...@gmail.com>:
> In which project / class ?
>
>
>
> 2006/12/7, Remy Maucherat <re...@apache.org>:
> > Henri Gomez wrote:
> > > it's a seems to be a tomcat-native (1.1.7) problem
> > >
> > > And since we discuss Tomcat 6.0.4 release, should we consider that
> > > error as a show stopper ?
> >
> > No. It existed before, and it is not known if it's a problem with the
> > Java code or not.
> >
> > What I see is that there's an IO exception here, so it means the send
> > call returned a status error (or maybe it returned one of these
> > mysterious codes which are an error but are not actually an error):
> > protected void flush()
> > throws IOException {
> > if (outputBuffer.position() > 0) {
> > if (Socket.sendbb(socket, 0, outputBuffer.position()) < 0) {
> > >> throw new IOException();
> > }
> > outputBuffer.clear();
> > }
> > }
> >
> > 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: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
In which project / class ?
2006/12/7, Remy Maucherat <re...@apache.org>:
> Henri Gomez wrote:
> > it's a seems to be a tomcat-native (1.1.7) problem
> >
> > And since we discuss Tomcat 6.0.4 release, should we consider that
> > error as a show stopper ?
>
> No. It existed before, and it is not known if it's a problem with the
> Java code or not.
>
> What I see is that there's an IO exception here, so it means the send
> call returned a status error (or maybe it returned one of these
> mysterious codes which are an error but are not actually an error):
> protected void flush()
> throws IOException {
> if (outputBuffer.position() > 0) {
> if (Socket.sendbb(socket, 0, outputBuffer.position()) < 0) {
> >> throw new IOException();
> }
> outputBuffer.clear();
> }
> }
>
> 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: mod_jk release preparation: ready for test
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> it's a seems to be a tomcat-native (1.1.7) problem
>
> And since we discuss Tomcat 6.0.4 release, should we consider that
> error as a show stopper ?
No. It existed before, and it is not known if it's a problem with the
Java code or not.
What I see is that there's an IO exception here, so it means the send
call returned a status error (or maybe it returned one of these
mysterious codes which are an error but are not actually an error):
protected void flush()
throws IOException {
if (outputBuffer.position() > 0) {
if (Socket.sendbb(socket, 0, outputBuffer.position()) < 0) {
>> throw new IOException();
}
outputBuffer.clear();
}
}
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
it's a seems to be a tomcat-native (1.1.7) problem
And since we discuss Tomcat 6.0.4 release, should we consider that
error as a show stopper ?
>2006/12/7, Mladen Turk <mt...@apache.org>:
> Henri Gomez wrote:
> > Used :
> >
> > <Connector protocol="org.apache.coyote.ajp.AjpProtocol" port="18093"
> > redirectPort="8443" /
> >
> > And it works
> >
>
> So, it's either AjpAprProtocol or native fault.
> In any case its not mod_jk fault.
>
> Just file the BZ report.
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> 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: mod_jk release preparation: ready for test
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
> Used :
>
> <Connector protocol="org.apache.coyote.ajp.AjpProtocol" port="18093"
> redirectPort="8443" /
>
> And it works
>
So, it's either AjpAprProtocol or native fault.
In any case its not mod_jk fault.
Just file the BZ report.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
Used :
<Connector protocol="org.apache.coyote.ajp.AjpProtocol" port="18093"
redirectPort="8443" /
And it works
2006/12/7, Mladen Turk <mt...@apache.org>:
> Henri Gomez wrote:
> > As I said, when I removed APR, it works
> >
> > I commented APR listener and remove the libtcnative.so from LIBRARY_PATH
> >
>
> Yes, I figured that out, but when removing native, the
> org.apache.coyote.jk. will be used that is different
> from o.a.c.ajp
> so, just set
> protocol="org.apache.coyote.ajp.AjpProtocol"
>
> This is not APR protocol, it plain Java!
>
> Regards,
> Mladen
>
>
> > 2006/12/7, Mladen Turk <mt...@apache.org>:
> >> Henri Gomez wrote:
> >> > FYI, when I disable use of Apr, the problem disappears.
> >> >
> >>
> >> Does it works with AjpProtocol (not AjpAprProtocol)
> >> By default if native load fails, the JK connector is
> >> used, that is different then Ajp connector.
> >> Can you set the protocol="org.apache.coyote.ajp.AjpProtocol"
> >> and if is fails as well?
> >>
> >> In case it doesn't, then it's probably a native fault.
> >> Regards,
> >> Mladen.
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_jk release preparation: ready for test
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
> As I said, when I removed APR, it works
>
> I commented APR listener and remove the libtcnative.so from LIBRARY_PATH
>
Yes, I figured that out, but when removing native, the
org.apache.coyote.jk. will be used that is different
from o.a.c.ajp
so, just set
protocol="org.apache.coyote.ajp.AjpProtocol"
This is not APR protocol, it plain Java!
Regards,
Mladen
> 2006/12/7, Mladen Turk <mt...@apache.org>:
>> Henri Gomez wrote:
>> > FYI, when I disable use of Apr, the problem disappears.
>> >
>>
>> Does it works with AjpProtocol (not AjpAprProtocol)
>> By default if native load fails, the JK connector is
>> used, that is different then Ajp connector.
>> Can you set the protocol="org.apache.coyote.ajp.AjpProtocol"
>> and if is fails as well?
>>
>> In case it doesn't, then it's probably a native fault.
>> Regards,
>> Mladen.
>>
>> ---------------------------------------------------------------------
>> 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: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
As I said, when I removed APR, it works
I commented APR listener and remove the libtcnative.so from LIBRARY_PATH
2006/12/7, Mladen Turk <mt...@apache.org>:
> Henri Gomez wrote:
> > FYI, when I disable use of Apr, the problem disappears.
> >
>
> Does it works with AjpProtocol (not AjpAprProtocol)
> By default if native load fails, the JK connector is
> used, that is different then Ajp connector.
> Can you set the protocol="org.apache.coyote.ajp.AjpProtocol"
> and if is fails as well?
>
> In case it doesn't, then it's probably a native fault.
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> 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: mod_jk release preparation: ready for test
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
> FYI, when I disable use of Apr, the problem disappears.
>
Does it works with AjpProtocol (not AjpAprProtocol)
By default if native load fails, the JK connector is
used, that is different then Ajp connector.
Can you set the protocol="org.apache.coyote.ajp.AjpProtocol"
and if is fails as well?
In case it doesn't, then it's probably a native fault.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
FYI, when I disable use of Apr, the problem disappears.
My configuration is using, apr 1.2.7, libtcnative 1.1.7 and Tomcat 6.0.2
Question :
In Apr mode, what send to Java signal which trigg the ClientAbortException ?
Regards
2006/12/7, Henri Gomez <he...@gmail.com>:
> Well I do more tests and the problems occurs with LAN or localhost
> configuration.
>
> worker.w809.port=18093
> worker.w809.host=localhost
> worker.w809.type=ajp13
>
> <!-- Define an AJP 1.3 Connector on port 8009 -->
> <Connector port="18083" protocol="AJP/1.3" redirectPort="8443" />
>
> What's ServerTimeout ?
>
> 2006/12/7, Mladen Turk <mt...@apache.org>:
> > Henri Gomez wrote:
> > > There is still a serious problem in jk 1.2.20 when flushing some large
> > > file (ie: PDF).
> > >
> >
> > Hard to tell without some test case and config files.
> > What is the socket_timeout, what is the ServerTimeout?
> >
> > Regards,
> > Mladen.
> >
> > ---------------------------------------------------------------------
> > 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: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
Well I do more tests and the problems occurs with LAN or localhost
configuration.
worker.w809.port=18093
worker.w809.host=localhost
worker.w809.type=ajp13
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="18083" protocol="AJP/1.3" redirectPort="8443" />
What's ServerTimeout ?
2006/12/7, Mladen Turk <mt...@apache.org>:
> Henri Gomez wrote:
> > There is still a serious problem in jk 1.2.20 when flushing some large
> > file (ie: PDF).
> >
>
> Hard to tell without some test case and config files.
> What is the socket_timeout, what is the ServerTimeout?
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> 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: mod_jk release preparation: ready for test
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
> There is still a serious problem in jk 1.2.20 when flushing some large
> file (ie: PDF).
>
Hard to tell without some test case and config files.
What is the socket_timeout, what is the ServerTimeout?
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
There is still a serious problem in jk 1.2.20 when flushing some large
file (ie: PDF).
here is the dump :
file to be sent is 162748 long, iosize=8192
lReadLen=8192
lSentLen=8192
lReadLen=8192
lSentLen=16384
lReadLen=8192
lSentLen=24576
lReadLen=8192
lSentLen=32768
lReadLen=8192
lSentLen=40960
lReadLen=8192
lSentLen=49152
lReadLen=8192
lSentLen=57344
lReadLen=8192
lSentLen=65536
lReadLen=8192
lSentLen=73728
lReadLen=8192
lSentLen=81920
lReadLen=8192
lSentLen=90112
lReadLen=8192
lSentLen=98304
lReadLen=8192
lSentLen=106496
lReadLen=8192
lSentLen=114688
lReadLen=8192
lSentLen=122880
lReadLen=8192
lSentLen=131072
lReadLen=8192
lSentLen=139264
lReadLen=8192
stackTrace is ClientAbortException: java.io.IOException
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:357)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:434)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:349)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:380)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:369)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:89)
On the jk side :
[Thu Dec 07 11:50:19 2006] [28806:3264] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1029): 0360 33 33
20 32 35 30 20 32 37 38 20 0D 35 30 30 20 - 33.250.278..500.
[Thu Dec 07 11:50:19 2006] [28806:3264] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1029): 0370 35 30
30 20 35 30 30 20 35 30 30 20 35 30 30 20 - 500.500.500.500.
[Thu Dec 07 11:50:19 2006] [28806:3264] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1029): 0380 35 30
30 20 35 30 30 20 35 30 30 20 35 30 30 20 - 500.500.500.500.
[Thu Dec 07 11:50:19 2006] [28806:3264] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1029): 0390 35 30
30 20 33 33 33 20 33 33 33 20 36 37 35 20 - 500.333.333.675.
[Thu Dec 07 11:50:19 2006] [28806:3264] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1029): 03a0 36 37
35 20 36 37 35 20 35 30 30 20 0D 39 32 30 - 675.675.500..920
[Thu Dec 07 11:50:19 2006] [28806:3264] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1029): 03b0 20 36
31 31 20 36 31 31 20 36 36 37 20 37 32 32 - .611.611.667.722
[Thu Dec 07 11:50:19 2006] [28806:3264] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1029): 03c0 20 36
31 31 20 36 31 31 20 37 32 32 20 37 32 32 - .611.611.722.722
[Thu Dec 07 11:50:19 2006] [28806:3264] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1029): 03d0 20 33
33 33 20 34 34 34 20 36 36 37 20 35 35 36 - .333.444.667.556
[Thu Dec 07 11:50:19 2006] [28806:3264] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1029): 03e0 20 38
33 33 20 36 36 37 20 37 32 32 20 0D 36 31 - .833.667.722..61
[Thu Dec 07 11:50:19 2006] [28806:3264] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1029): 03f0 31 20
37 32 32 20 36 31 31 20 35 30 30 20 35 35 - 1.722.611.500.55
[Thu Dec 07 11:50:19 2006] [28806:3264] [debug] ws_write::mod_jk.c
(436): written 7252 out of 7252
[Thu Dec 07 11:50:19 2006] [28806:3264] [error]
ajp_connection_tcp_get_message::jk_ajp_common.c (970): wrong message
format 0x200d from 172.31.3.202:18093
[Thu Dec 07 11:50:19 2006] [28806:3264] [error]
ajp_get_reply::jk_ajp_common.c (1592): (w809) Tomcat is down or
network problems. Part of the response has already been sent to the
client
[Thu Dec 07 11:50:19 2006] [28806:3264] [info]
ajp_service::jk_ajp_common.c (1877): (w809) receiving from tomcat
failed, recoverable operation attempt=1
[Thu Dec 07 11:50:19 2006] [28806:3264] [info]
ajp_service::jk_ajp_common.c (1916): (w809) sending request to tomcat
failed, recoverable operation attempt=2
[Thu Dec 07 11:50:19 2006] [28806:3264] [error]
ajp_service::jk_ajp_common.c (1928): (w809) Connecting to tomcat
failed. Tomcat is probably not started or is listening on the wrong
port
[Thu Dec 07 11:50:19 2006] [28806:3264] [debug]
ajp_done::jk_ajp_common.c (2258): recycling connection pool slot=0 for
worker w809
I send block of 8k, could it be the problem ?
Also I'm using AjpApr
Regards
2006/12/7, Mladen Turk <mt...@apache.org>:
> Henri Gomez wrote:
> > BTW, windows binaries are very welcome !
> >
>
> I'll prepare them later today, and hand them
> over to the Rainer. (Well I'll put them on
> my people.a.o)
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> 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: mod_jk release preparation: ready for test
Posted by Mladen Turk <mt...@apache.org>.
Henri Gomez wrote:
> BTW, windows binaries are very welcome !
>
I'll prepare them later today, and hand them
over to the Rainer. (Well I'll put them on
my people.a.o)
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
BTW, windows binaries are very welcome !
2006/12/6, Henri Gomez <he...@gmail.com>:
> Mladen and you, are now our JK experts ;)
>
> BTW, I'll take a look at them and tests them on my dev and prod servers
>
> Good works !
>
> 2006/12/6, Rainer Jung <rj...@apache.org>:
> > Hi,
> >
> > I think Mladen and I completed our code change plans for the next
> > release of mod_jk. Since over all we had more changes than we expected
> > when we started for 1.2.20 I would like to give the opportunity of
> > testing, before I do the tagging. In case no show stoppers will be found
> > I suggest tagging late saturday, or early sunday, so that we can finish
> > the release vote during the next week.
> >
> > I produced a source tarball with the usual release script. It contains
> > everything similar to a release except for the final version number and
> > the correct release dates in the release docs.
> >
> > You can find it under:
> >
> > http://people.apache.org/~rjung/mod_jk-1.2.20-dev/
> >
> > There is a directory docs containing the reorganized and slightly
> > extended docs, a directory source containing the .tar.gz, .zip, the
> > signature and checksum files and finally an empty directory binaries,
> > which might be filled tomorrow by Mladen with Windows build(s).
> >
> > I would really appreciate, if some of our long term mod_jk experts could
> > have a look at it.
> >
> > Major changes:
> >
> > - improved IIS 6 support (e.g. shm, thread counts
> > - improved virtual host support for apache, also documented
> > - reworked status worker (see new docs page)
> > - reorganized docs, new pages for uriworkermap.properties and status worker
> >
> > Minor features:
> >
> > - fail_on_status attribute
> > - rename jvm_route -> route (but code still works with old config)
> > - uriworkermap reload interval configurable
> > - max_packet_size documented
> > - new uriworkermap reload semantics (delete old uriworkermap entries
> > from internal list during reload)
> > - load balancer strategy "Sessions"
> > - more flushing options
> >
> > BZ fixes:
> >
> > - 36121: Don't change main uri when mod_jk serves included uri. (markt)
> > - 40966: Fix socket descriptor checks on windows. (mturk)
> > - 40965: Initialize missing service parameters. (mturk)
> > - 40938: Fix releasing of rewrite map. Thanks to Chris Adams for
> > spotting that. (mturk)
> > - 40856: Fixing case sensitivity bug in URL mapping. (rjung)
> > - 40793: Documentation: Improvements to Apache HowTo provided by Paul
> > Charles Leddy. (markt)
> > - 40774: Fixing wrong recursion termination. This one restricted the
> > "reference" feature unintentionally to 20 workers. (rjung)
> > - 40716: Adding "reference" feature to IIS and Netscape. (rjung)
> >
> > Have fun,
> >
> > Rainer
> >
> > ---------------------------------------------------------------------
> > 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: mod_jk release preparation: ready for test
Posted by Henri Gomez <he...@gmail.com>.
Mladen and you, are now our JK experts ;)
BTW, I'll take a look at them and tests them on my dev and prod servers
Good works !
2006/12/6, Rainer Jung <rj...@apache.org>:
> Hi,
>
> I think Mladen and I completed our code change plans for the next
> release of mod_jk. Since over all we had more changes than we expected
> when we started for 1.2.20 I would like to give the opportunity of
> testing, before I do the tagging. In case no show stoppers will be found
> I suggest tagging late saturday, or early sunday, so that we can finish
> the release vote during the next week.
>
> I produced a source tarball with the usual release script. It contains
> everything similar to a release except for the final version number and
> the correct release dates in the release docs.
>
> You can find it under:
>
> http://people.apache.org/~rjung/mod_jk-1.2.20-dev/
>
> There is a directory docs containing the reorganized and slightly
> extended docs, a directory source containing the .tar.gz, .zip, the
> signature and checksum files and finally an empty directory binaries,
> which might be filled tomorrow by Mladen with Windows build(s).
>
> I would really appreciate, if some of our long term mod_jk experts could
> have a look at it.
>
> Major changes:
>
> - improved IIS 6 support (e.g. shm, thread counts
> - improved virtual host support for apache, also documented
> - reworked status worker (see new docs page)
> - reorganized docs, new pages for uriworkermap.properties and status worker
>
> Minor features:
>
> - fail_on_status attribute
> - rename jvm_route -> route (but code still works with old config)
> - uriworkermap reload interval configurable
> - max_packet_size documented
> - new uriworkermap reload semantics (delete old uriworkermap entries
> from internal list during reload)
> - load balancer strategy "Sessions"
> - more flushing options
>
> BZ fixes:
>
> - 36121: Don't change main uri when mod_jk serves included uri. (markt)
> - 40966: Fix socket descriptor checks on windows. (mturk)
> - 40965: Initialize missing service parameters. (mturk)
> - 40938: Fix releasing of rewrite map. Thanks to Chris Adams for
> spotting that. (mturk)
> - 40856: Fixing case sensitivity bug in URL mapping. (rjung)
> - 40793: Documentation: Improvements to Apache HowTo provided by Paul
> Charles Leddy. (markt)
> - 40774: Fixing wrong recursion termination. This one restricted the
> "reference" feature unintentionally to 20 workers. (rjung)
> - 40716: Adding "reference" feature to IIS and Netscape. (rjung)
>
> Have fun,
>
> Rainer
>
> ---------------------------------------------------------------------
> 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