AW: AW: mod_jk release policy - was: JK 1.2.9-dev test results

[Hans Schmid]

Thanks, Mladen,

as long as this disabled feature does not prevent the failover case, I am fine 
;)

See inline ...

> -Ursprüngliche Nachricht-
> Von: Mladen Turk [mailto:[EMAIL PROTECTED]
> Gesendet: Freitag, 18. Februar 2005 10:36
> An: Tomcat Developers List
> Betreff: Re: AW: mod_jk release policy - was: JK 1.2.9-dev test results
>
>
> Hans Schmid wrote:
> > Hi,
> >
> > I just want to describe our usecase because we make heavy use of the
> > local_worker and local_worker_only flags right now.
> >
>
>
> > We use those flags for 'maintenance' mode and failover very successfuly.
> >
>
> Cool ;).
>
>
> > But please see our setup and usecase below.
> >
> > We only use one tomcat at a time to get traffic with a standby tomcat for 
> > maineneance.
> > This scenario also covers failover. We do not use the loadbalancer to 
> > actually balance
> > by factors.
> >
>
> OK. So basically you have two tomcat boxes where the second is used
> only when you wish to put the first on maintenance?

Both Tomcats are always running, but the second one is used only for:
1.) Failover
2.) Maintenance switch -> after this the roles of both Tomcats have switched
(TC-01 becomes standby)


In fact our scenario is a little bit more complex (I just did not want to 
explain
it in the first place). This brings in Loadbalancing as well:

We actually have between 3 and 6 Tomcats running at the same time depending on 
our
load, which has high seasonal peeks. So November is usually 20 times as much as 
February.
We are talking about 500 concurrent users in our webapp plus many more on the
static apache pages.

Example: 4 Tomcats are running in parallel. Just TC-01 has local_worker=1, the 
other
ones have local_worker=0. Every 30 minutes we switch our worker.properties to 
activate
a different tomcat by setting its local_worker=1 and the old one to 0.
The new tomcat has been just restarted before.

TC-01 -> 30min. -> TC-02 -> 30min. -> TC-03 -> 30min. -> TC-04 -> 30min. -> 
TC-01 again 

That way, every Tomcat gets new sessions for about 30 minutes. The long lasting
ols sticky sessions of our users (avg. session time 30min.) stay active on the
Tomcat which was active before for the rest of their live.

This effectively generates a loadbalancing distribution of about

TC-01 = 55% (the currently active Tomcat)
TC-04 = 35% (the one which was active before but still handles sticky sessions)
TC-03 <= 10% (the one before TC-04, handling really long lasting old sessions)
TC-02 = 0%  (this one is the next candidate to restart and become active)


We can easily scale this approach by bringing in even more tomcats and shorter 
roll times (or less and longer times).

Works really well with our highly changing but well known traffic ;)
(and handles memory leaks as well ...)

Cheers Hans

>
> Using new config:
>
> worker.list=loadbalancer
> worker.loadbalancer.balanced_workers=ajp13-01,ajp13-02
> worker.loadbalancer.sticky_session=True
>
> worker.ajp13-01.disabled=0
> ...
> worker.ajp13-02.disabled=1
>
>
> Disabled flag initially mark the worker as disabled.
> It will not be used until:
>
> Use the jkstatus console and set the:
> worker.ajp13-02.disabled=0
> and
> worker.ajp13-01.disabled=1
>
> And that's it.
> Existing sessions will be forwarded to ajp13-01,
> while new will go to the ajp13-02.
> No need to make tricks with symlnks, graceful restarts, etc.
> What's more, it works on all platforms and all web servers.
>
>
> Also take a look at:
> http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html
> (Big red warning about worker names)
>
> Regards,
> Mladen.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: mod_jk release policy - was: JK 1.2.9-dev test results

[Hans Schmid]

Hi,

I just want to describe our usecase because we make heavy use of the
local_worker and local_worker_only flags right now.

We use those flags for 'maintenance' mode and failover very successfuly.

But please see our setup and usecase below.

> -Ursprüngliche Nachricht-
> Von: Mladen Turk [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 17. Februar 2005 20:34
> An: Tomcat Developers List
> Betreff: Re: mod_jk release policy - was: JK 1.2.9-dev test results
>
>
> Rainer Jung wrote:
> > Hi,
> >
> > first: thanks a lot to Mladen for adding all the beautiful features [and
> > removing CRLF :) ]. Big leap forward!
> >
>
> Still, I cope with those on a daily basis.
>
> > I think that until Monday we were still in the progress of adding
> > features, and fixing bugs. 1.2.8 changed a lot internally, but most was
> > functionally compatible to 1.2.6. Release 1.2.9 still supported all
> > features of 1.2.6.
> >
>
> Something similar I already explained discussing with guys interested
> on Netware platform.
>
> Something need to be done, and the obvious solution was not to reinvent
> the wheel, but rather use all the code and knowledge about the subject
> already present.
>
> To be able to use some new features like dynamic config, some things
> has to be changed internally, but nothing was touched in the protocol
> level, only how that protocol is managed.
>
> So I don't see the point of forking 1.3. Both config and core features
> are the same. Of course some advanced configuration properties where
> changes, lot new added, but from the outside its still old mod_jk.
>
> Further more adding shared memory and dynamic config I see as a final
> design change for mod_jk.
>
> > Now we are in the discussion of dropping features (and we even did drop
> > some like locality support) and I have the impresssion there should be a
> > separate discussion thread about the future of mod_jk:
> >
>
>
> Other thing is 'deprecating' certain thing.
> By that I don't mean deleting them or something like that, but rather
> marking them as 'no more developed'.
> The reason is for that is pure fact. For example we have lotus domino
> connector that works only for domino5. Think that later versions don't
> even have compatible api. I'm not aware anyone in the
> world used jk to connect domino with tomcat (at least never saw
> bugzilla entry on that). So it is deprecated by that fact.
> The same applies to JNI. Who uses that?
>
> Regarding locality, you mean local_worker and local_worker_only flags?
> IMHO that was one of the fuzziest things about jk that no one ever
> understood, not to mention that this never worked actually.
> Take for example the current documentation about local_worker:
>
> "If local_worker is set to True it is marked as local worker. If in
> minimum one worker is marked as local worker, lb_worker is in local
> worker mode. All local workers are moved to the beginning of the
> internal worker list in lb_worker during validation."
>
> Now what that means to the actual user? I reeded that zillion times
> and never understood.
> Also further more:

This one is crucial for our Maintenance switchover see later.

>
> "We need a graceful shut down of a node for maintenance. The balancer in
> front asks a special port on each node periodically. If we want to
> remove a node from the cluster, we switch off this port."
>
> WTF !? How? Which port? How to switch of this port?
>
> What counts the most is that you where unable to mark the node for
> shutdown, and not to accept new connections without session id.
> I suppose that was the purpose for those two directives, but I was
> never able to setup the jk in that direction.
>


First we use TC 3.3.2 (moving to 5.5.7)  behind Apache 1.3 on Solaris.
mod_jk version is a patched version based on mod_jk1.2.5

We only use one tomcat at a time to get traffic with a standby tomcat for 
maineneance.
This scenario also covers failover. We do not use the loadbalancer to actually 
balance
by factors.


We use sticky_sessions=true

This is our mod_jk setup if Tomcat-01 is serving the requests:

worker.list=loadbalancer
worker.loadbalancer.balanced_workers=ajp13-01, ajp13-02
worker.loadbalancer.local_worker_only=0

worker.ajp13-01.port=8009
worker.ajp13-01.host=tomcat-01
worker.ajp13-01.type=ajp13
worker.ajp13-01.lbfactor=1
worker.ajp13-01.local_worker=1

worker.ajp13-02.port=8019
worker.ajp13-02.host=tomcat-02
worker.ajp13-02.type=ajp13
worker.ajp13-02.lbfactor=1
worker.ajp13-02.local_worker=0


Now, all requests go to worker.ajp13-01, since local_worker=1 only for tomcat-01
so it "is first in the queue".

Failover (in case tomcat-01 crashes) works, since local_worker_only=0 meaning
"it also distributes the requests to the other machine if ajp13-01 is in error 
state"


Now lets do maintenance (tomcat-01 should be shut down, tomcat-02 shall take 
the load):

What we do is just link in an other worker.property file on the webserver and
gracefully restart Apache to take effect.

The

AW: Ready for mod_jk 1.2.6 release?

[Hans Schmid]

Hi,

a mod_jk 1.2.6 release would be highly welcome.
We are using cvs head in production for a couple of month now without
problems.

thanks,
Hans


> -Ursprungliche Nachricht-
> Von: Henri Gomez [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 8. Juli 2004 10:01
> An: Tomcat Developers List
> Betreff: Re: Ready for mod_jk 1.2.6 release?
>
>
> Rainer Jung wrote:
> > Hi,
> >
> > the last release of mod_jk 1.2.x (1.2.5) is more than 9 months old.
> > Since then there have been important improvements (CPing/CPong and
> > recovery_options). Especially recovery_options is very useful in
> > transparent administration (start/stop) of cluster nodes.
> >
> > The 1.2 branch is still the preferred branch for combination
> with apache
> > 1.3. Is there any volunteer to make an official 1.2.6 release?
> I do hope
> > so ;-)
>
> I could works on it if nobody else has time to act as release manager.
>
> Feedback welcome of course, especially on possible blocking bugs...
>
> > Another good argument: The documentation of the new features is already
> > there
> >
> (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/workershow
> to.html),
> > so no additional work and furthermore, the documentation up to now does
> > not mention, that all these features are still not available, because
> > 1.2.6 has never been released. Many thanks to whoever wrote
> that document.
> >
> > I worked with a cvs build under solaris for some weeks without
> problems,
> > but for production purposes people need an official release.
> >
> > The last changes in the native jk code is more then 6 weeks old and
> > there is no code change activity at the moment. So this might be a good
> > point in time to release mod_jk 1.2.6.
> >
> > Looking forward for positive feedback
> >
> > Rainer Jung
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Any news on mod_jk 1.2.6 realease plan?

[Hans Schmid]

Hi,

since mod_jk2 2.0.4 is now released for a couple of weeks,
are there any plans to release mod_jk 1.2.6 in the near future as mentioned
before the mod_jk2 release?

I would like to use the PING/PONG feature.

If not, I will try building HEAD.

Is anybody aware of pending showstoppers?

Thanks,
Hans Schmid

einsurance Agency AG
Information Technology
Bayerstrasse 33
80335 München

Tel: +49-89-55292-860
Fax: +49-89-55292-855


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with Coyote Connectors

[Hans Schmid]

Any other ideas what can cause this java.io.IOException?

I have tested my setup by just replacing the CoyoteConnector with the
corresponding
AJP13Connector in my server.xml (same settings) and everything works fine
again.







> -Ursprüngliche Nachricht-
> Von: Hans Schmid [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 22. April 2004 11:41
> An: Tomcat Developers List
> Betreff: AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with
> Coyote Connectors
>
>
> Sorry, I forgot to mention, that we are using mod_jk 1.2.5 on the Apache
> side
>
> > -Ursprüngliche Nachricht-
> > Von: Hans Schmid [mailto:[EMAIL PROTECTED]
> > Gesendet: Donnerstag, 22. April 2004 11:25
> > An: Tomcat-Dev
> > Betreff: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with
> > Coyote Connectors
> >
> >
> > Hello,
> >
> > we recently upgraded our production system from Tomcat 3.3.1 with AJP13
> > connectors to
> > Tomcat 3.3.2 with CoyoteConnectors (packaged with TC332)
> >
> > We are running behind Apache 1.3.29 on Solaris 9 64bit, J2SDK
> > 1.4.2_04 from
> > Sun.
> >
> > Monitoring the tomcat.log showed the following Exception which
> seems to be
> > CoyoteConnector related.
> >
> > java.io.IOException: Read bytes failed -1
> > at
> > org.apache.coyote.tomcat3.Tomcat3Request.readBytes(Tomcat3Request.
> > java:150)
> > at
> > org.apache.coyote.tomcat3.Tomcat3Request.doRead(Tomcat3Request.java:120)
> > at org.apache.tomcat.core.Request.readBody(Request.java:962)
> > at
> > org.apache.tomcat.core.Request.handlePostParameters(Request.java:388)
> > at
> > org.apache.tomcat.facade.HttpServletRequestFacade.getParameterName
> > s(HttpServ
> > letRequestFacade.java:254)
> > at
> > org.apache.struts.util.RequestUtils.populate(RequestUtils.java:743)
> > at
> > org.apache.struts.action.ActionServlet.processPopulate(ActionServl
> > et.java:20
> > 61)
> > at
> > de.einsurance.gui.framework.ExtendedActionServlet.processPopulate(
> > ExtendedAc
> > tionServlet.java:92)
> > at
> > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1564)
> > at
> > de.einsurance.gui.framework.ExtendedActionServlet.process(Extended
> > ActionServ
> > let.java:64)
> > at
> > org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java)
> > at
> >
> org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:534)
> > at org.apache.tomcat.core.Handler.invoke(Handler.java:280)
> > at org.apache.tomcat.core.Handler.service(Handler.java:193)
> > at
> > org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:445)
> > at
> > org.apache.tomcat.core.ContextManager.internalService(ContextManag
> > er.java:87
> > 4)
> > at
> > org.apache.tomcat.core.ContextManager.service(ContextManager.java:790)
> > at
> > org.apache.coyote.tomcat3.Tomcat3Adapter.service(Tomcat3Adapter.java:64)
> > at
> > org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:296)
> > at
> > org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:372)
> > at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:691)
> > at
> > org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket
> > .java:625)
> >     at
> > org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:804)
> > at
> > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(Thre
> > adPool.jav
> > a:644)
> > at java.lang.Thread.run(Thread.java:534)
> >
> >
> > This looks to me like a Coyote problem. Any Ideas?
> > What can I do to debug this further (It happen
> >
> > Should I file a Bugzilla Entry?
> >
> >
> > (we have 3+ years Experience with the Tomcat 3.3 series and
> > AJP13Connectors)
> >
> >
> >
> > Hans Schmid
> >
> > einsurance Agency AG
> > Information Technology
> > Bayerstrasse 33
> > 80335 München
> >
> > Tel: +49-89-55292-860
> > Fax: +49-89-55292-855
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: AW: AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with Coyote Connectors

[Hans Schmid]

> -Ursprungliche Nachricht-
> Von: Henri Gomez [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 22. April 2004 12:38
> An: Tomcat Developers List
> Betreff: Re: AW: AW: java.io.IOException: Read bytes failed in Tomcat
> 3.3.2 with Coyote Connectors
>
>
> Hans Schmid wrote:
>
> > Hi Henri,
> >
> > thanks for the quick reply.
> >
> > This is what is used (same config as the former AJP13Connector)
> >
> >  > processorClassName="org.apache.jk.server.JkCoyoteHandler"
> >   port="11019"
> >   maxThreads="2048"
> >   maxSpareThreads="80"
> >   minSpareThreads="40" />
> >
> > old was:
> >
> >  >  shutdownEnable="true"
> >  maxThreads="2048"
> >  maxSpareThreads="80"
> >  minSpareThreads="40" />
> >
> > served from 2 Apache Servers each with 1024 maxthreads. Threads
> should be
> > enough.
> >
> >
> > I saw 8 occurrences of the stacktrace within 2 Days, so it does
> not occur
> > often.
> > I can go back to my old server.xml with the AJP13Connectors as
> well, but I
> > would
> > love to run Coyote for a while in order to prepare a Tomcat 5 upgrade.
> >
> > We have up to 50 concurrent users and up to 80 req/day :)
> > But not now. this is in November :)
> >
> >
> > BTW. I am missing the shutdownEnabled feature :(
> > (One addional AJP12Connector and port per Tomcat Instance required)
>
> 2048 threads on both Tomcat and Apache2 ?
>
> I'm using only 150 threads on both end

1024 on each of the 2 Apaches and 2048 on Tomcat.

We ran into problems with 1024/512/512 setup on peek times, but this was
probably related to a
bug in mod_jk1.2.5, where apache 1.3 left open file handles when doing
graceful restarts.
This led to fork Errors on the Apache side and to hung Tomcat AJP13Connector
threads.

This is fixed in mod_jk 1.2.6-dev and we applied this patch successfully.

Just as Info:
We have 3 Tomcats running in parallel, which we restart hourly. Every hour
we shutdown the oldest Tomcat, start it up again, symlink a different
worker.properties on
our Apache and gracefully restart them. This way we use the lb worker to
switch load to a
newly started Tomcat and let old sticky sessions slowly finish on the older
instances.

This all is done due to a memory leak in a third party lib we can not
influence :(

More ideas?

Thanks a lot,
Hans


>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with Coyote Connectors

[Hans Schmid]

Hi Henri,

thanks for the quick reply.

This is what is used (same config as the former AJP13Connector)



old was:



served from 2 Apache Servers each with 1024 maxthreads. Threads should be
enough.


I saw 8 occurrences of the stacktrace within 2 Days, so it does not occur
often.
I can go back to my old server.xml with the AJP13Connectors as well, but I
would
love to run Coyote for a while in order to prepare a Tomcat 5 upgrade.

We have up to 50 concurrent users and up to 80 req/day :)
But not now. this is in November :)


BTW. I am missing the shutdownEnabled feature :(
(One addional AJP12Connector and port per Tomcat Instance required)



> -Ursprungliche Nachricht-
> Von: Henri Gomez [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 22. April 2004 11:46
> An: Tomcat Developers List
> Betreff: Re: AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2
> with Coyote Connectors
>
>
> Hans Schmid wrote:
> > Sorry, I forgot to mention, that we are using mod_jk 1.2.5 on the Apache
> > side
>
> I'm using the same config at works, jk 1.2.5 and TC 3.3.2 and didn't see
> such problem.
>
> Are you sure the number of ajp13 threads are correctly set, regarding
> the number of connections allowed on web server ?
>
> We have heavily loaded Tomcat/Apache couple (more than 30 req/day)
> and the only problem I could see is from time to time the :
>
> INFO: Unknown message 0
>
> This one is fixed in CVS (post 3.3.2 release).

Thanks, I know. Just testing that one.

>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with Coyote Connectors

[Hans Schmid]

Sorry, I forgot to mention, that we are using mod_jk 1.2.5 on the Apache
side

> -Ursprüngliche Nachricht-
> Von: Hans Schmid [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 22. April 2004 11:25
> An: Tomcat-Dev
> Betreff: java.io.IOException: Read bytes failed in Tomcat 3.3.2 with
> Coyote Connectors
>
>
> Hello,
>
> we recently upgraded our production system from Tomcat 3.3.1 with AJP13
> connectors to
> Tomcat 3.3.2 with CoyoteConnectors (packaged with TC332)
>
> We are running behind Apache 1.3.29 on Solaris 9 64bit, J2SDK
> 1.4.2_04 from
> Sun.
>
> Monitoring the tomcat.log showed the following Exception which seems to be
> CoyoteConnector related.
>
> java.io.IOException: Read bytes failed -1
>   at
> org.apache.coyote.tomcat3.Tomcat3Request.readBytes(Tomcat3Request.
> java:150)
>   at
> org.apache.coyote.tomcat3.Tomcat3Request.doRead(Tomcat3Request.java:120)
>   at org.apache.tomcat.core.Request.readBody(Request.java:962)
>   at
> org.apache.tomcat.core.Request.handlePostParameters(Request.java:388)
>   at
> org.apache.tomcat.facade.HttpServletRequestFacade.getParameterName
> s(HttpServ
> letRequestFacade.java:254)
>   at
> org.apache.struts.util.RequestUtils.populate(RequestUtils.java:743)
>   at
> org.apache.struts.action.ActionServlet.processPopulate(ActionServl
> et.java:20
> 61)
>   at
> de.einsurance.gui.framework.ExtendedActionServlet.processPopulate(
> ExtendedAc
> tionServlet.java:92)
>   at
> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1564)
>   at
> de.einsurance.gui.framework.ExtendedActionServlet.process(Extended
> ActionServ
> let.java:64)
>   at
> org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java)
>   at
> org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:534)
>   at org.apache.tomcat.core.Handler.invoke(Handler.java:280)
>   at org.apache.tomcat.core.Handler.service(Handler.java:193)
>   at
> org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:445)
>   at
> org.apache.tomcat.core.ContextManager.internalService(ContextManag
> er.java:87
> 4)
>   at
> org.apache.tomcat.core.ContextManager.service(ContextManager.java:790)
>   at
> org.apache.coyote.tomcat3.Tomcat3Adapter.service(Tomcat3Adapter.java:64)
>   at
> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:296)
>   at
> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:372)
>   at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:691)
>   at
> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket
> .java:625)
>   at
> org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:804)
>   at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(Thre
> adPool.jav
> a:644)
>   at java.lang.Thread.run(Thread.java:534)
>
>
> This looks to me like a Coyote problem. Any Ideas?
> What can I do to debug this further (It happen
>
> Should I file a Bugzilla Entry?
>
>
> (we have 3+ years Experience with the Tomcat 3.3 series and
> AJP13Connectors)
>
>
>
> Hans Schmid
>
> einsurance Agency AG
> Information Technology
> Bayerstrasse 33
> 80335 München
>
> Tel: +49-89-55292-860
> Fax: +49-89-55292-855
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

java.io.IOException: Read bytes failed in Tomcat 3.3.2 with Coyote Connectors

[Hans Schmid]

Hello,

we recently upgraded our production system from Tomcat 3.3.1 with AJP13
connectors to
Tomcat 3.3.2 with CoyoteConnectors (packaged with TC332)

We are running behind Apache 1.3.29 on Solaris 9 64bit, J2SDK 1.4.2_04 from
Sun.

Monitoring the tomcat.log showed the following Exception which seems to be
CoyoteConnector related.

java.io.IOException: Read bytes failed -1
at
org.apache.coyote.tomcat3.Tomcat3Request.readBytes(Tomcat3Request.java:150)
at org.apache.coyote.tomcat3.Tomcat3Request.doRead(Tomcat3Request.java:120)
at org.apache.tomcat.core.Request.readBody(Request.java:962)
at org.apache.tomcat.core.Request.handlePostParameters(Request.java:388)
at
org.apache.tomcat.facade.HttpServletRequestFacade.getParameterNames(HttpServ
letRequestFacade.java:254)
at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:743)
at
org.apache.struts.action.ActionServlet.processPopulate(ActionServlet.java:20
61)
at
de.einsurance.gui.framework.ExtendedActionServlet.processPopulate(ExtendedAc
tionServlet.java:92)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1564)
at
de.einsurance.gui.framework.ExtendedActionServlet.process(ExtendedActionServ
let.java:64)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at
org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:534)
at org.apache.tomcat.core.Handler.invoke(Handler.java:280)
at org.apache.tomcat.core.Handler.service(Handler.java:193)
at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:445)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:87
4)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:790)
at org.apache.coyote.tomcat3.Tomcat3Adapter.service(Tomcat3Adapter.java:64)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:296)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:372)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:691)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:625)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:804)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:644)
at java.lang.Thread.run(Thread.java:534)


This looks to me like a Coyote problem. Any Ideas?
What can I do to debug this further (It happen

Should I file a Bugzilla Entry?


(we have 3+ years Experience with the Tomcat 3.3 series and AJP13Connectors)



Hans Schmid

einsurance Agency AG
Information Technology
Bayerstrasse 33
80335 München

Tel: +49-89-55292-860
Fax: +49-89-55292-855


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: Bug report for Tomcat 3 [2004/02/15]

[Hans Schmid]

Hi,

this does not look like a Tomcat 3 buglist. More like Jetspeed or Velocity?
At least it is a completely different list as last week.

Something got mixed up in Bugzilla?

While speaking, would it be possible to set up an automated Bug report
for Tomcat 5 as well?

Thanks,
Hans

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Gesendet: Sonntag, 15. Februar 2004 16:18
> An: [EMAIL PROTECTED]
> Betreff: Bug report for Tomcat 3 [2004/02/15]
>
>
> +-
> --+
> | Bugzilla Bug ID
>   |
> |
> +-+
> | | Status: UNC=Unconfirmed NEW=New ASS=Assigned
>   |
> | | OPN=ReopenedVER=Verified(Skipped
> Closed/Resolved)   |
> | |
> +-+
> | |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major
>   |
> | |   |   MIN=Minor   NOR=Normal
> ENH=Enhancement   |
> | |   |
> +-+
> | |   |   | Date Posted
>   |
> | |   |   |
> +--+
> | |   |   |  | Description
>   |
> | |   |   |  |
>   |
> | 4144|Ver|Nor|2001-10-13|Portlet name in layout customiser may
> be incorrect|
> | 4147|Ver|Nor|2001-10-13| /> causes |
> | 5440|New|Enh|2001-12-15|Move localization property files to
> WEB-INF/conf  |
> | 5472|New|Enh|2001-12-17|EMail account changes to user.
>   |
> | 5474|New|Enh|2001-12-17|Account creation process should have a
> lifetime   |
> | 5475|Ass|Nor|2001-12-17|Cancel button on Edit Account and
> Confirm registra|
> | 5595|Ver|Nor|2001-12-27|typo in JetspeedResources.properties
>   |
> | 5610|Ass|Enh|2001-12-28|navigation of longer lists
>   |
> | 5803|New|Enh|2002-01-10|Forgotten-password functionality -
> version 2  |
> | 6815|Unc|Min|2002-03-02|Does not compile with 2.3 version of
> servlets.jar |
> | 6839|Unc|Maj|2002-03-04|jetspeed does not free allocated memory
> on tomcat |
> | 7667|New|Nor|2002-04-01|Customize Pane - action buttons don't
> work well fo|
> | 9057|New|Maj|2002-05-14|Creating New User PSML doesn't assign
> new portlet |
> | 9757|Ass|Nor|2002-06-10|Intake service not accessible from
> VelocityPortlet|
> |11184|New|Enh|2002-07-25|Email Sending using Authenticated SMTP
> server |
> |11535|Ass|Blk|2002-08-07|Jetspeed and DB2 field type mismatch
>   |
> |11705|New|Enh|2002-08-14|PSML duplication when registered
>   |
> |11830|Ass|Enh|2002-08-19|From TODO List : Create a e-mail
> example portlet  |
> |13255|New|Nor|2002-10-03|Sloppy XML encoding parsing in
> URLFetcher |
> |13696|New|Nor|2002-10-16|Cache trouble when using references to
> an abstract|
> |14422|Ass|Nor|2002-11-10|LDAP Security Service
>   |
> |14423|New|Nor|2002-11-10|Link Portlet
>   |
> |14424|Ass|Nor|2002-11-10|WebPagePortlet2
>   |
> |14425|New|Nor|2002-11-10|Start on Deprecation to complete clean
> up code by |
> |14426|New|Nor|2002-11-10|Convert current portlets to Velocity
> Portlets |
> |14427|New|Nor|2002-11-10|Update website to be more inline with
> Jakarta stan|
> |14428|Ass|Nor|2002-11-10|Rework the default (example) portal
> site  |
> |14430|Ass|Nor|2002-11-10|Complete CapabilityMap and Media Type
> Registry|
> |14431|Ass|Nor|2002-11-10|Test and Commit CMS implementation from
> Christophe|
> |14740|New|Nor|2002-11-21|Display bug with AggregatePortlets or
> references  |
> |14830|New|Nor|2002-11-25|layout doesn't use language-specific
> logged_in nav|
> |14893|New|Nor|2002-11-27|Parameter names collision in Customizer
>   |
> |14940|New|Nor|2002-11-28|Exception Logged when User has nothing
> on screen  |
> |15163|New|Maj|2002-12-08|Session timeout does not redirect to
> login page   |
> |15209|New|Nor|2002-12-10|Convert to Maven build
>   |
> |15210|New|Nor|2002-12-10|Complete LDAP Security Service
>   |
> |15211|New|Nor|2002-12-10|Media Type fallback algorithms in
> Profiler, Templa|
> |15212|New|Nor|2002-12-10|Cleanup All Documentation
>   |
> |15213|New|Nor|2002-12-10|WebPagePortlet2 - Integrated Web Page
> Portlet with|
> |15214|Ass|Nor|2002-12-10|[PATCH] Cleanup Logging
>   |
> |15224|New|Enh|2002-12-10|Updated RSS support for RSSPortlet
>   |
> |15225|New|Nor|2002-12-10|Error rendering Velocity template
>   |
> |15265|New|Nor|2002-12-11|RegistryService: Could not unmarshal
>   |
> |15323|New|Enh|2002-12-12|Move Jetspeed tutorial to Jakarta in
> docbook forma|
> |15413|New|Nor|2002-12-16|Deleting reference from customizer
> fails  |
> |15416|New|Nor|2002-12-16|TODO: Write JSP JSLink tool
>   |
> |15453|New|Nor|2002-12-17|CLASSES and jetspeed-1.4-b3.jar
> inconsistent   

Solved AW: jk 1.2.4 LB bug?

[Hans Schmid]

Sorry Glenn,

by looking deeper into the mod_jk.log. When changing worker names, I
realized, that I was actually
restarting Apache with the same worker.properties every time.

There was a link earlier in the configuration chain, which made my switching
useless :(

We should definately reduce our linking !!!

Thanks very much.

p.s. If anybody else is interested in our LB/failover setup I am glad to
provide some info.

Best regards,
Hans

> -Ursprungliche Nachricht-
> Von: Hans Schmid [mailto:[EMAIL PROTECTED]
> Gesendet: Mittwoch, 16. Juli 2003 15:15
> An: Tomcat Developers List
> Betreff: AW: jk 1.2.4 LB bug?
>
>
> Thanks for your reply,
> comments see inline
>
> > -Ursprungliche Nachricht-
> > Von: Glenn Nielsen [mailto:[EMAIL PROTECTED]
> > Gesendet: Mittwoch, 16. Juli 2003 12:26
> > An: Tomcat Developers List
> > Betreff: Re: jk 1.2.4 LB bug?
> >
> >
> > mod_jk will print out information about the lb config if you set
> > the JkLogLevel to debug.
> >
>
> done
>
> > I would suggest setting up a test system where you can test
> > the below with JkLogLevel debug configured.  Then grep the
> > log for lines which have jk_lb_worker.c in them.
> >
>
> OK
>
> > This will tell you several things.
> >
> > 1. Whether the worker.properties are getting reread when you
> >do an apache restart.  (They should be)
> >
>
> Yes they were reread:
> Initial:
> [Wed Jul 16 14:11:14 2003]  [jk_worker.c (118)]: Into wc_close
> [Wed Jul 16 14:11:14 2003]  [jk_worker.c (199)]: close_workers
> got 6 workers
> to destroy
> [Wed Jul 16 14:11:14 2003]  [jk_worker.c (206)]: close_workers
> will destroy
> worker lb-einsurance
> [Wed Jul 16 14:11:14 2003]  [jk_lb_worker.c (561)]: Into
> jk_worker_t::destroy
> [Wed Jul 16 14:11:14 2003]  [jk_ajp_common.c (1461)]: Into
> jk_worker_t::destroy
> [Wed Jul 16 14:11:14 2003]  [jk_ajp_common.c (1468)]: Into
> jk_worker_t::destroy up to 1 endpoint to close
> [Wed Jul 16 14:11:14 2003]  [jk_ajp_common.c (605)]: In
> jk_endpoint_t::ajp_close_endpoint
> [Wed Jul 16 14:11:14 2003]  [jk_ajp_common.c (612)]: In
> jk_endpoint_t::ajp_close_endpoint, closed sd = 12
> [Wed Jul 16 14:11:14 2003]  [jk_ajp_common.c (1461)]: Into
> jk_worker_t::destroy
> [Wed Jul 16 14:11:14 2003]  [jk_worker.c (118)]: Into wc_close
> [Wed Jul 16 14:11:14 2003]  [jk_worker.c (118)]: Into wc_close
> [Wed Jul 16 14:11:14 2003]  [jk_worker.c (118)]: Into wc_close
> [Wed Jul 16 14:11:14 2003]  [jk_ajp_common.c (1468)]: Into
> jk_worker_t::destroy up to 1 endpoint to close
> [Wed Jul 16 14:11:14 2003]  [jk_worker.c (199)]: close_workers
> got 6 workers
> to destroy
> [Wed Jul 16 14:11:14 2003]  [jk_worker.c (199)]: close_workers
> got 6 workers
> to destroy
> [Wed Jul 16 14:11:14 2003]  [jk_worker.c (199)]: close_workers
> got 6 workers
> to destroy
> [Wed Jul 16 14:11:14 2003]  [jk_ajp_common.c (1461)]: Into
> jk_worker_t::destroy
> [Wed Jul 16 14:11:14 2003]  [jk_worker.c (206)]: close_workers
> will destroy
> worker lb-einsurance
> [Wed Jul 16 14:11:14 2003]  [jk_worker.c (206)]: close_workers
> will destroy
> worker lb-einsurance
> [Wed Jul 16 14:11:14 2003]  [jk_worker.c (206)]: close_workers
> will destroy
> worker lb-einsurance
> [Wed Jul 16 14:11:14 2003]  [jk_ajp_common.c (1468)]: Into
> jk_worker_t::destroy up to 1 endpoint to close
> [Wed Jul 16 14:11:14 2003]  [jk_lb_worker.c (561)]: Into
> jk_worker_t::destroy
> [Wed Jul 16 14:11:14 2003]  [jk_lb_worker.c (561)]: Into
> jk_worker_t::destroy
> [Wed Jul 16 14:11:14 2003]  [jk_lb_worker.c (561)]: Into
> jk_worker_t::destroy
>
> ... closing other not related worker
>
> [Wed Jul 16 14:11:16 2003]  [jk_uri_worker_map.c (172)]: Into
> jk_uri_worker_map_t::uri_worker_map_alloc
> [Wed Jul 16 14:11:16 2003]  [jk_uri_worker_map.c (375)]: Into
> jk_uri_worker_map_t::uri_worker_map_open
> [Wed Jul 16 14:11:16 2003]  [jk_uri_worker_map.c (396)]:
> jk_uri_worker_map_t::uri_worker_map_open, rule map size is 12
> [Wed Jul 16 14:11:16 2003]  [jk_uri_worker_map.c (321)]: Into
> jk_uri_worker_map_t::uri_worker_map_open, match rule
> /einsurance/=lb-einsurance was added
> [Wed Jul 16 14:11:16 2003]  [jk_uri_worker_map.c (345)]: Into
> jk_uri_worker_map_t::uri_worker_map_open, exact rule
> /einsurance=lb-einsurance was added
>
> ... 5 other workers (including other lb-workers and normal workers)
>
> added
> [Wed Jul 16 14:11:16 2003]  [jk_uri_worker_map.c (408)]: Into
> jk_uri_worker_map_t::uri_worker_map_open, there are 12 rules
> [Wed Jul 16 14:11:16 2003]  [jk_uri_worker_map.c (422)]:
> jk_uri_worker_map_t::uri_worker_map_open, done
> [Wed Jul 16 14:11:16 2003]  [jk_w

AW: jk 1.2.4 LB bug?

[Hans Schmid]

lidate for worker ajp13-01 contact is tomcathost-ei:11009
[Wed Jul 16 14:11:16 2003]  [jk_ajp_common.c (1397)]: Into jk_worker_t::init
[Wed Jul 16 14:11:16 2003]  [jk_ajp_common.c (1421)]: In jk_worker_t::init,
setting socket timeout to 0
[Wed Jul 16 14:11:16 2003]  [jk_worker.c (187)]: wc_create_worker, done
[Wed Jul 16 14:11:16 2003]  [jk_worker.c (148)]: Into wc_create_worker
[Wed Jul 16 14:11:16 2003]  [jk_worker.c (162)]: wc_create_worker, about to
create instance ajp13-02 of ajp13
[Wed Jul 16 14:11:16 2003]  [jk_ajp13_worker.c (108)]: Into
ajp13_worker_factory
[Wed Jul 16 14:11:16 2003]  [jk_worker.c (171)]: wc_create_worker, about to
validate and init ajp13-02
[Wed Jul 16 14:11:16 2003]  [jk_ajp_common.c (1343)]: Into
jk_worker_t::validate
[Wed Jul 16 14:11:16 2003]  [jk_ajp_common.c (1364)]: In
jk_worker_t::validate for worker ajp13-02 contact is tomcathost-ei:11019
[Wed Jul 16 14:11:16 2003]  [jk_ajp_common.c (1397)]: Into jk_worker_t::init
[Wed Jul 16 14:11:16 2003]  [jk_ajp_common.c (1421)]: In jk_worker_t::init,
setting socket timeout to 0
[Wed Jul 16 14:11:16 2003]  [jk_worker.c (187)]: wc_create_worker, done
[Wed Jul 16 14:11:16 2003]  [jk_worker.c (148)]: Into wc_create_worker
[Wed Jul 16 14:11:16 2003]  [jk_worker.c (162)]: wc_create_worker, about to
create instance ajp13-sb of ajp13
[Wed Jul 16 14:11:16 2003]  [jk_ajp13_worker.c (108)]: Into
ajp13_worker_factory
[Wed Jul 16 14:11:16 2003]  [jk_worker.c (171)]: wc_create_worker, about to
validate and init ajp13-sb
[Wed Jul 16 14:11:16 2003]  [jk_ajp_common.c (1343)]: Into
jk_worker_t::validate
[Wed Jul 16 14:11:16 2003]  [jk_ajp_common.c (1364)]: In
jk_worker_t::validate for worker ajp13-sb contact is tomcathost-ei-sb:11015
[Wed Jul 16 14:11:16 2003]  [jk_ajp_common.c (1397)]: Into jk_worker_t::init
[Wed Jul 16 14:11:16 2003]  [jk_ajp_common.c (1421)]: In jk_worker_t::init,
setting socket timeout to 0
[Wed Jul 16 14:11:16 2003]  [jk_worker.c (187)]: wc_create_worker, done
[Wed Jul 16 14:11:16 2003]  [jk_lb_worker.c (498)]: Balanced worker 0 has
name ajp13-01
[Wed Jul 16 14:11:16 2003]  [jk_lb_worker.c (498)]: Balanced worker 1 has
name ajp13-sb
[Wed Jul 16 14:11:16 2003]  [jk_lb_worker.c (498)]: Balanced worker 2 has
name ajp13-02
[Wed Jul 16 14:11:16 2003]  [jk_lb_worker.c (502)]: in_local_worker_mode:
true
[Wed Jul 16 14:11:16 2003]  [jk_lb_worker.c (505)]: local_worker_only: false
[Wed Jul 16 14:11:16 2003]  [jk_worker.c (187)]: wc_create_worker, done
[Wed Jul 16 14:11:16 2003]  [jk_worker.c (238)]: build_worker_map, removing
old lb-einsurance worker

this last line looks suspicous to me

> 2. What the lb worker thinks the config is.
>

initial:
[Wed Jul 16 14:04:44 2003]  [jk_lb_worker.c (586)]: Into lb_worker_factory
[Wed Jul 16 14:04:44 2003]  [jk_lb_worker.c (420)]: Into
jk_worker_t::validate
[Wed Jul 16 14:04:44 2003]  [jk_lb_worker.c (498)]: Balanced worker 0 has
name ajp13-01
[Wed Jul 16 14:04:44 2003]  [jk_lb_worker.c (498)]: Balanced worker 1 has
name ajp13-sb
[Wed Jul 16 14:04:44 2003]  [jk_lb_worker.c (498)]: Balanced worker 2 has
name ajp13-02
[Wed Jul 16 14:04:44 2003]  [jk_lb_worker.c (502)]: in_local_worker_mode:
true
[Wed Jul 16 14:04:44 2003]  [jk_lb_worker.c (505)]: local_worker_only: false

but after the switching and graceful restart exactly the same (which is the
error) 

[Wed Jul 16 14:11:16 2003]  [jk_lb_worker.c (420)]: Into
jk_worker_t::validate
[Wed Jul 16 14:11:16 2003]  [jk_lb_worker.c (498)]: Balanced worker 0 has
name ajp13-01
[Wed Jul 16 14:11:16 2003]  [jk_lb_worker.c (498)]: Balanced worker 1 has
name ajp13-sb
[Wed Jul 16 14:11:16 2003]  [jk_lb_worker.c (498)]: Balanced worker 2 has
name ajp13-02
[Wed Jul 16 14:11:16 2003]  [jk_lb_worker.c (502)]: in_local_worker_mode:
true
[Wed Jul 16 14:11:16 2003]  [jk_lb_worker.c (505)]: local_worker_only: false

This explains the observed (wrong) fall-over behavior, (should be ajp13-02,
ajp13-sb, ajp13-01)


original workers.properties:
worker.ajp13-01.lbfactor=1
worker.ajp13-01.local_worker=1

worker.ajp13-02.lbfactor=1
worker.ajp13-02.local_worker=0

worker.ajp13-sb.lbfactor=0
worker.ajp13-sb.local_worker=1

local_worker_only=0 for the lb-worker

changed to before graceful restart: (linking a different worker.properties)

worker.ajp13-01.lbfactor=1
worker.ajp13-01.local_worker=0

worker.ajp13-02.lbfactor=1
worker.ajp13-02.local_worker=1

worker.ajp13-sb.lbfactor=0
worker.ajp13-sb.local_worker=1

local_worker_only=0 the lb-worker



So it *seems* there might be something wrong with the reinitialisation of
the worker order ?


If you need further information, I can mail you the complete logs offline.

Thanks for looking into this,
Hans



> Then post those log lines here.
>
> Thanks,
>
> Glenn
>
> Hans Schmid wrote:
> > Hi,
> >
> > I noticed the following with mod_jk 1.2.4, Apache 1.3.26 and
> > Tomcat 3.3.1a on Solaris 8 JDK 1.4.1_03.
> >
> > Maybe a LB bug (Loadfactors do not recover after st

jk 1.2.4 LB bug?

[Hans Schmid]

Hi,

I noticed the following with mod_jk 1.2.4, Apache 1.3.26 and
Tomcat 3.3.1a on Solaris 8 JDK 1.4.1_03.

Maybe a LB bug (Loadfactors do not recover after startup of new
tomcat/graceful Apache restart).

Let me explain my scenario first:

I want to gracefully upgrade our webapp without loosing sessions + have a
fail over scenario.
Therefor we have sticky sessions enabled.

Setup:
1 tomcat 01 running on Server A,
0 tomcat 02 running on Server A,
1 tomcat SB running on Server B

01 tomcat on Server A runs the application, SB tomcat on server B is
standby(fallback),
02 tomcat is shutdown on Server A at the moment.

All three Tomcats are in the same lb_worker:


worker.list=lb-worker

worker.ajp13-01.port=11009
worker.ajp13-01.host=A
worker.ajp13-01.type=ajp13
worker.ajp13-01.lbfactor=1
worker.ajp13-01.local_worker=1

worker.ajp13-02.port=11019
worker.ajp13-02.host=A
worker.ajp13-02.type=ajp13
worker.ajp13-02.lbfactor=1
worker.ajp13-02.local_worker=0

worker.ajp13-sb.port=11015
worker.ajp13-sb.host=B
worker.ajp13-sb.type=ajp13
worker.ajp13-sb.lbfactor=0
worker.ajp13-sb.local_worker=1

worker.lb-worker.type=lb
worker.lb-worker.balanced_workers=ajp13-01, ajp13-02, ajp13-sb
worker.lb-worker.local_worker_only=0


The worker List order should now be:
 1. worker.ajp13-01 lbfactor=1,local_worker=1  TC 01
 2. worker.ajp13-sb lbfactor=0,local_worker=1  TC SB
 3. worker.ajp13-02 lbfactor=1,local_worker=0) TC 02  (not running)

Now all requests go to worker.ajp13-01 (TC 01), none to worker.ajp13-sb (TC
SB lbfactor=0),
none to worker.ajp13-02.port (TC 02 not running).

If Server A crashes (TC 01) all new requests go to Server B (TC SB
worker.ajp13-sb)
since this is then the only running Tomcat FINE
This is our Fail-Over Solution (lost running sessions, but OK).

Now the webapp update Scenario:

1.) shutdown TC SB on Server B, update the webapp, start tc SB and test via
a seperate HTTPConnector port without Apache.
2.) this does not affect anything on production, since the lbfactor=0 on TC
SB
-> no sessions arrive on tc SB
3.) When the test was successful, our Standby Tomcat SB is updated
4.) Now upgrade the webapp on Server A TC 02, which is currently not
running.
5.) Start up TC 02 on Server A with the new version of the webapp,
immediately exchange the worker.properties with a different version and
gracefully restart apache:

worker.list=lb-worker

worker.ajp13-01.port=11009
worker.ajp13-01.host=A
worker.ajp13-01.type=ajp13
worker.ajp13-01.lbfactor=1
worker.ajp13-01.local_worker=0 < put old webapp on TC 01 to the
foreign worker list

worker.ajp13-02.port=11019
worker.ajp13-02.host=A
worker.ajp13-02.type=ajp13
worker.ajp13-02.lbfactor=1
worker.ajp13-02.local_worker=1 < put new webapp on TC 02 in front of
the local worker list

worker.ajp13-sb.port=11015
worker.ajp13-sb.host=B
worker.ajp13-sb.type=ajp13
worker.ajp13-sb.lbfactor=0
worker.ajp13-sb.local_worker=1

worker.lb-worker.type=lb
worker.lb-worker.balanced_workers=ajp13-01, ajp13-02, ajp13-sb
worker.lb-worker.local_worker_only=0

Just the two lines marked above with < swap
(local_worker values of TC 01 and TC 02)

6.) now all 3 Tomcats are running. All existing sessions still go to TC 01
(sticky sessions; we do not loose running sessions)
7.) What I expect:
TC 02 takes a while to startup.
The worker List order should now be:
 1. worker.ajp13-02 lbfactor=1,local_worker=1  TC 02
 2. worker.ajp13-sb lbfactor=0,local_worker=1  TC SB
 3. worker.ajp13-01 lbfactor=1,local_worker=0) TC 01  (old webapp)

Since TC 02 needs 3 minutes to start up (filling caches etc.) it is not
immediately availlable.
During this time new sessions arrive at TC SB, since it is the next in the
worker list. OK fine this works.
Since these sessions are sticky as well, all users connecting during this
time stay on TC SB
during their whole session life. FINE

8.) As soon as TC 02 is up and running (finished all load-on-startup servlet
initialisition stuff)
I would expect that TC 02 gets all new Sessions (Number 1 in the worker
List).

This is not the case! All new Sessions still arrive at TC SB.

9.) After a while (one hour) we shutdown TC 01. Since no new sessions
arrived there since our
graceful restart of Apache, all old Sessions should have expired.

10.) even now (only 2 Tomcats running TC 02  and TC SB) and even after a
graceful restart new Sessions
arrive at TC SB


Conclusion:
Now, do I misunderstand the supposed behaviour of lbfactor and local_worker
flag ?
I think that the behaviour in 8.) is wrong. 10.) is starange too.

Thanks for any suggestion if I am completely wrong here
or further looking into this.

Hans


> -Ursprungliche Nachricht-
> Von: Glenn Nielsen [mailto:[EMAIL PROTECTED]
> Gesendet: Mittwoch, 9. Juli 2003 15:56
> An: Tomcat Developers List
> Betreff: Re: jk 1.2.25 release ?
>
>
> I was hoping to get it released this week.
>
> But I just noticed that under Apache 2 mod_jk piped logs there
> are two instances of the piped log program running for t

AW: java processes created by tomcat

[Hans Schmid]

See
http://tomcatfaq.sourceforge.net/linx.html

cheers,
Hans

> -Ursprüngliche Nachricht-
> Von: siddharth [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 17. Juni 2003 12:13
> An: [EMAIL PROTECTED]
> Betreff: java processes created by tomcat
>
>
> hello,
>
>
> I am running following servers on my linux machine
>
> 1. tomcat4  using many JSPs and Servlets
> 2. apache
> 3. qmail
> 4. postgresql
> etc.
>
> Tomcat is the only process which is usijg java.
>
> when i do 'top' and 'sort by memory usage' i get
> following output.
>
> -
>
>  2:10pm  up  5:24,  5 users,  load average: 0.22,
> 0.52, 0.83
> 168 processes: 166 sleeping, 2 running, 0 zombie, 0
> stopped
> CPU states:  1.1% user, 17.6% system,  0.0% nice,
> 81.1% idle
> Mem:   384416K av,  381356K used,3060K free,
> 2324K shrd,   11720K buff
> Swap:  522072K av,   60548K used,  461524K free
>71616K cached
>
>
>
>   PID USER PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM
>   TIME COMMAND
>  9458 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:24 java
>  9489 root   8   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9490 root   9   0  118M 115M 23768 S 0.0 30.8
>   1:45 java
>  9491 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9495 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:01 java
>  9502 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9537 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9538 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9539 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:05 java
>  9639 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9717 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9719 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9720 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9721 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9723 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9724 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9725 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9726 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9727 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9728 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9729 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9730 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9731 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9732 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9733 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9734 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9735 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9736 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9737 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9738 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9739 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9740 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9741 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9742 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>  9743 root   9   0  118M 115M 23768 S 0.0 30.8
>   0:00 java
>
> -
>
> ***
> Notice that first page displayed by output of 'top' is
> full of JAVA processes ...
>
>
> is this a problem ? because my machine is getting
> heavily loaded. ( with around 400 MB of RAM )
>
>
>
> please help
>
> thanks.
>
>
> --
>   siddharth
>   [EMAIL PROTECTED]
>
> --
> http://www.fastmail.fm - The way an email service should be
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: [VOTE] minimal JSR 154 only distribution

[Hans Schmid]

Hi,

I would like to have the possibility to not include jasper in our production
system.

We are using TC 3.3.2-dev plus Velocity.

It does not really hurt us, but having fewer code is always better IHMO :)
I really love the modularity og TC 3.3.x

Bill, can you give me hints, how to patch TC 3.3.2-dev to exclude jasper ?


Another thought regarding the Admin Webapp in TC 4.x/TC 5.0:
(please forgive me if I am completly off the track here)

I would rather like to be able to use the Admin Webapp on a seperate remote
Admin Tomcat to control our production system. I really do not want to
install
such sensitive code on our live servers. So the Admin Webapp could connect
to the
production Tomcat and execute for example ant tasks to restart contexts,
deploy a webapp
and so on.

(The localhost shutdown restriction is no option, since our servers are at
out ISP
and have to be controlled from within our office.)

Thanks,
Hans




> -Ursprüngliche Nachricht-
> Von: Bill Barker [mailto:[EMAIL PROTECTED]]
> Gesendet: Samstag, 7. Dezember 2002 09:59
> An: Tomcat Developers List
> Betreff: Re: [VOTE] minimal JSR 154 only distribution
>
>
> It would cause nightmares if you knew how badly I've got my e-mails
> cross-linked :).
>
> This is to +1 the original VOTE.  While I'm personally a heavy JSP user,
> having patched TC 3.3.x to allow it to run in servlet-only mode, I see the
> need for offering a servlet-only container.
>
> According to the Costin-vote-watch, we still need at least one more
> (binding) +1 to authorize a servlet-only release of Tomcat.
>
> - Original Message -
> From: "IAS" <[EMAIL PROTECTED]>
> To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>
> Sent: Friday, December 06, 2002 11:02 PM
> Subject: RE: [VOTE] minimal JSR 154 only distribution
>
>
> > I'm very glad to see this vote proposal because it seems to me like the
> > first step of Servlet/JSP mutual independence.
> >
> > Two months ago I proposed Tomcat architectural refactoring plan (at that
> > time "Tomcat subproject plan") on
> > http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg34720.html.
> > I also showed JSF+Struts+Catalina ensemble on
> > http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg35116.html
> > and a possible Jasper-Catalina relationship on
> > http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg35119.html.
> > I sincerely understand a very few of Tomcat committers share interest in
> > this issue like jean-frederic clere's seconding on
> > http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg34768.html.
> >
> >
> > In my humble opinion, in terms of technology, it is not imperative that
> > Servlet should go with JSP. In fact, the mother of Tomcat, JServ also
> > started as a Servlet engine. In other words, Servlet technology itself
> > is independent one. It also implies that Java Web developers have
> > freedom of choosing dynamic page generation technology over Servlet. We
> > can say we have right to use JSP, but on the other hand, we have right
> > not to use JSP in purely technical perspective.
> >
> > However, I totally agree on the need that we deliver JSP equipped Tomcat
> > for the majority of Tomcat users who are very familiar with JSP (even
> > cannot live without JSP like me :-). I guess the problem is "Who will do
> > (or exactly speaking, be willing to do) the job, i.e. making
> > Servlet-only-Tomcat since we need a considerable number of Tomcat
> > committers (Costin said 3) for that. If we get wide support from Tomcat
> > committers but they can't afford the job, how about gathering
> > Servlet-only-Tomcat team whether they belong to committers or not? I
> > hope there would be many people who will volunteer for that, including
> > myself. The detailed processes respecting the work could be discussed
> > from now on, and this chance might be a new attempt to develop greater
> > Tomcat empowered by volunteers.
> >
> > Thanks in advance.
> > IAS
> >
> > ===
> > Lee, Changshin (Korean name)
> > IAS (International name)
> >Company Web Site: http://www.tmax.co.kr
> >Personal Web Site: http://www.iasandcb.pe.kr
> > ---
> > Senior Researcher & Java Technology Evangelist
> > JCP member - http://jcp.org/en/participation/members/L
> > R&D Institute
> > Tmax Soft, Inc.
> > JCP member - http://jcp.org/en/participation/members/T
> > ==
> >
> > > -Original Message-
> > > From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> > > Sent: Saturday, December 07, 2002 1:09 AM
> > > To: tomcat-dev
> > > Subject: [VOTE] minimal JSR 154 only distribution
> > >
> > > Create a separate minimal JSR 154 only distribution of Tomcat 4.x:
> > >
> > > +1  []
> > > 0   []
> > > -1  []
> > >
> > > -jon
> > >
> > > --
> > > StudioZ.tv /\ Bar/Nightclub/Entertain

AW: Nightly TC 3.3.x builds not working anymore?

[Hans Schmid]

Last time they were created was 08-Nov-2002 but today is the 20.11.2002 ;)

http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3.x/

Parent Directory -
 JmxSupport.war  08-Nov-2002 06:28  459K
 PasswordPrompter.war08-Nov-2002 06:28   23K
 StreamHandler.war   08-Nov-2002 06:28  9.4K
 jakarta-tomcat-3.3.2-dev-src.tar.gz 08-Nov-2002 06:07  2.9M  GZIP
compressed file
 jakarta-tomcat-3.3.2-dev-src.zip08-Nov-2002 05:22  3.1M
 jakarta-tomcat-3.3.2-dev.tar.gz 08-Nov-2002 06:08  5.4M  GZIP
compressed file
 jakarta-tomcat-3.3.2-dev.zip08-Nov-2002 05:27  5.5M
 jsp-tests.war   08-Nov-2002 06:28  318K
 servlet-tests.war   08-Nov-2002 06:28  1.8M
 test.war08-Nov-2002 06:28  165K



> -Ursprungliche Nachricht-
> Von: Henri Gomez [mailto:[EMAIL PROTECTED]]
> Gesendet: Mittwoch, 20. November 2002 10:41
> An: Tomcat Developers List
> Betreff: Re: Nightly TC 3.3.x builds not working anymore?
>
>
> Hans Schmid wrote:
> > Hi,
> >
> > the nightly build of Tomcat 3.3.x seems to have stopped at 08-Nov-2002.
> >
> > Any Idea, why?
> >
> > Cheers,
> > Hans
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
> >
> What's the error ?
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Nightly TC 3.3.x builds not working anymore?

[Hans Schmid]

Hi,

the nightly build of Tomcat 3.3.x seems to have stopped at 08-Nov-2002.

Any Idea, why? 

Cheers,
Hans 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Bug 13736

[Hans Schmid]

I will try by best next week. I have seen this only once 
in the logs, I have not been able to reproduce it yet. 
I'll do my best to reproduce the error conditions, and see 
if it occurs again.

Cheers,
Hans

On Sun, 20 Oct 2002 00:08:33 -0700
 "Bill Barker" <[EMAIL PROTECTED]> wrote:
Remy's fix is now in the 3.3 nightly.  Since you can 
reproduce this, it
would be a big help if you could find a machine to test 
this on.

- Original Message -
From: "Hans Schmid" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
<[EMAIL PROTECTED]>
Sent: Saturday, October 19, 2002 5:59 AM
Subject: AW: Bug 13736


Bill, Remy,

I have seen this one once on our production system
running Tomcat 3.3.1 with AJP1.3, Apache 1.3.27, mod_jk 
1.1.0
This is on Sparc Solaris 8 running JDK 1.3.1_04.
11019 is our ajp13 port (which we uswe also as shutdown 
port. No AJP 1.2
port open)
Our webservers use the lb_worker to connect to the 
Tomcat servers
(different

machine)

It occured, when we had a bug in our application causing 
an endless
stacktrace, which filled
up our logs.( 5000 !!! MB per minute). At some stage, 
the JVM crashed out
after a stack overflow.

Before the crash, tomcat got slower and slower due to 
the massive logging.
11019 is our ajp13 port (which we uswe also as shutdown 
port. No AJP 1.2
port open)

I can reproduce the endless stacktrace, but am not sure 
to get the
ServerSocket error
(can not reproduce this on our production server for 
obvious reasons)


PoolTcpEndpoint: Endpoint
ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=11019] 
ignored
exception:

java.net.SocketException: Interrupted system call
java.net.SocketException: Interrupted system call
at java.net.PlainSocketImpl.socketAccept(Native Method)
at 
java.net.PlainSocketImpl.accept(PlainSocketImpl.java:463)
at 
java.net.ServerSocket.implAccept(ServerSocket.java:238)
at java.net.ServerSocket.accept(ServerSocket.java:217)
at

org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultSe

rverSocketFactory.java:107)
at


org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java

:326)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:472)
at


org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav

a:516)
at java.lang.Thread.run(Thread.java:479)
2002-10-05 16:01:24 - Ctx(/einsurance) : 
IllegalStateException in R(
/einsurance + /view + /screens/car/carDescription.htm) -
java.lang.IllegalStateException: Cannot forward because 
the response has
already been committed
at

org.apache.tomcat.facade.RequestDispatcherImpl.doForward(RequestDispatcherIm

pl.java:207)
at


org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl

.java:174)
at


de.einsurance.gui.framework.ExceptionHandler.handle(ExceptionHandler.java:25

5)
at


de.einsurance.gui.framework.ExceptionHandler.handle(ExceptionHandler.java:15

1)
at


de.einsurance.gui.framework.ExtendedActionServlet.process(ExtendedActionServ

let.java:69)
at 
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:491)
at 
javax.servlet.http.HttpServlet.service(HttpServlet.java)
at 
javax.servlet.http.HttpServlet.service(HttpServlet.java)
at
org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
at 
org.apache.tomcat.core.Handler.invoke(Handler.java:322)
at 
org.apache.tomcat.core.Handler.service(Handler.java:235)
at
org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)

at


org.apache.tomcat.facade.RequestDispatcherImpl.doForward(RequestDispatcherIm

pl.java:272)
at


org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl

.java:174)
at


org.apache.struts.action.ActionServlet.processActionForward(ActionServlet.ja

va:1758)
at 
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595)
at

de.einsurance.gui.framework.ExtendedActionServlet.process(ExtendedActionServ

let.java:65)
at 
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:491)
at 
javax.servlet.http.HttpServlet.service(HttpServlet.java)
at 
javax.servlet.http.HttpServlet.service(HttpServlet.java)
at
org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
at 
org.apache.tomcat.core.Handler.invoke(Handler.java:322)
at 
org.apache.tomcat.core.Handler.service(Handler.java:235)
at
org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)

at


org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:91

7)
at 
org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
at

org.apache.tomcat.modules.server.Ajp13Interceptor.processConnection(Ajp13Int

erceptor.java:341)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494)
at


org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav

a:516)
at java.lang.Thread.run(Thread.java:479)


Cheers,
Hans


> -Ursprungliche Nachricht-
> Von: 

AW: Bug 13736

[Hans Schmid]

Bill, Remy,

I have seen this one once on our production system
running Tomcat 3.3.1 with AJP1.3, Apache 1.3.27, mod_jk 1.1.0
This is on Sparc Solaris 8 running JDK 1.3.1_04.
11019 is our ajp13 port (which we uswe also as shutdown port. No AJP 1.2
port open)
Our webservers use the lb_worker to connect to the Tomcat servers (different
machine)

It occured, when we had a bug in our application causing an endless
stacktrace, which filled
up our logs.( 5000 !!! MB per minute). At some stage, the JVM crashed out
after a stack overflow.

Before the crash, tomcat got slower and slower due to the massive logging.
11019 is our ajp13 port (which we uswe also as shutdown port. No AJP 1.2
port open)

I can reproduce the endless stacktrace, but am not sure to get the
ServerSocket error
(can not reproduce this on our production server for obvious reasons)


PoolTcpEndpoint: Endpoint
ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=11019] ignored exception:
java.net.SocketException: Interrupted system call
java.net.SocketException: Interrupted system call
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:463)
at java.net.ServerSocket.implAccept(ServerSocket.java:238)
at java.net.ServerSocket.accept(ServerSocket.java:217)
at
org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultSe
rverSocketFactory.java:107)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java
:326)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:472)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:516)
at java.lang.Thread.run(Thread.java:479)
2002-10-05 16:01:24 - Ctx(/einsurance) : IllegalStateException in R(
/einsurance + /view + /screens/car/carDescription.htm) -
java.lang.IllegalStateException: Cannot forward because the response has
already been committed
at
org.apache.tomcat.facade.RequestDispatcherImpl.doForward(RequestDispatcherIm
pl.java:207)
at
org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl
.java:174)
at
de.einsurance.gui.framework.ExceptionHandler.handle(ExceptionHandler.java:25
5)
at
de.einsurance.gui.framework.ExceptionHandler.handle(ExceptionHandler.java:15
1)
at
de.einsurance.gui.framework.ExtendedActionServlet.process(ExtendedActionServ
let.java:69)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:491)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at
org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
at org.apache.tomcat.core.Handler.service(Handler.java:235)
at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)
at
org.apache.tomcat.facade.RequestDispatcherImpl.doForward(RequestDispatcherIm
pl.java:272)
at
org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcherImpl
.java:174)
at
org.apache.struts.action.ActionServlet.processActionForward(ActionServlet.ja
va:1758)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595)
at
de.einsurance.gui.framework.ExtendedActionServlet.process(ExtendedActionServ
let.java:65)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:491)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at
org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
at org.apache.tomcat.core.Handler.service(Handler.java:235)
at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:91
7)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
at
org.apache.tomcat.modules.server.Ajp13Interceptor.processConnection(Ajp13Int
erceptor.java:341)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:516)
at java.lang.Thread.run(Thread.java:479)


Cheers,
Hans


> -Ursprungliche Nachricht-
> Von: Remy Maucherat [mailto:remm@;apache.org]
> Gesendet: Freitag, 18. Oktober 2002 20:15
> An: Tomcat Developers List
> Betreff: Re: Bug 13736
>
>
> Bill Barker wrote:
>
> > +1.  As I said above, it probably hasn't shown up in 3.3 mostly because
> > AJP13 has many fewer accepts.
>
> I'll fix it then.
>
> You have to be careful that no IOException should end up in that code,
> otherwise, for each one the server socket will be restarted (not

AW: [POLL] Tomcat 3.3.2 updates

[Hans Schmid]

Hi,

since our application uses TopLink, we can not upgrade to xerces 2.
There are hardcoded xerces 1 classes used directly from TopLink.

So 2) is a showstopper for all people with 3rd party jars requiring xerces 1

MBeans are useful for us, but not required. We are already using mx4j and
mx4j-tools in our webapp together with xerces 1.4.0 and xalan 2.1.0

My preference would be. Leave it as it is, but give a short
readme hat to copy where to be abe to use MxInterceptor


Thanks,
Hans

> -Ursprungliche Nachricht-
> Von: Henri Gomez [mailto:[EMAIL PROTECTED]]
> Gesendet: Montag, 23. September 2002 16:02
> An: [EMAIL PROTECTED]
> Betreff: [POLL] Tomcat 3.3.2 updates
>
>
> Hi to all,
>
> If you tracked the discussion about MxInterceptor and it's
> use in Tomcat 3.3.2-dev you should know that we have some
> modification to Tomcat 3.3.2 jars layout to be able to
> use MxInterceptor :
>
> 1) mx4j and mx4j-tools should goes in lib/common
>
> 2) mx4j-tools HTTP adaptor require TRAX (xalan),
> so we should put in common/lib JAXP+XML PARSER+TRANSFORMER,
> and as such could use :
>
> xerces-j2 2.1.0
> xalan-j2 2.4.0
> xml-commons-apis 1.0
>
> Since these jars will be in lib/common, users won't be able
> to use another one for it's own apps.
>
> 3) We'll have to remove JAXP/XML-PARSER for lib/container.
>
>
> Thanks to give your opinion here.
>
> [ ] 1. Don't care about MBeans, or do want to be able to have
> different XML apis for apps and container, so keep the
> current situation.
>
> [ ] 2. MxInterceptor is really needed, ok to change the layout,
> we'll warn users in Changelog / Readme
>
> [ ] 3. I'd like to MxInterceptor and old layout, I'd rather like to
> have a copy of DynamicMBeanProxy from jtc/util located in
> a location compatible with container/lib (to be in
> container_util.jar we could copy it in org.apache.tomcat.util.mx)
>
> [ ] 4. I'd like to use MxInterceptor, keep the old layout, but don't
> want to make the copy and could provide some code to avoid that.
>
>
> Personally, I'd like solution 4 (but don't know how to), so I'll be
> pragmatic and retains 3.
>
>
>
>
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[TC 5] XMLSchema validation and Xerces 2.1.0

[Hans Schmid]

Hi,

as far as I understand, there are problems in Tomcat 5 
with the XML Schema validation. A hack in Tomcat plus Xerces 2.0.1 
are currentzly in the build system.

Has anyone tried the new Xerces release 2.1.0 yet ?

If 2.1.0 fixes the XML Schema problems it might be 
worth including it in Tomcat 4.1 as well

Just a thought,
Hans Schmid


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

AW: Proposal draft for Tomcat 5.0 : #3 Straw Man

[Hans Schmid]

Hi,

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Gesendet: Samstag, 22. Juni 2002 06:32
> An: [EMAIL PROTECTED]
> Betreff: Re: Proposal draft for Tomcat 5.0 : #3 Straw Man
>
>
> Glenn Nielsen wrote:
> >
> > Proposal in General:
> >
> > The proposal is pretty vague on details.  I have seen a number of
> > replies stating "That's an implementation detail".  I for one would
> > like to see the proposal broken out into much more detail before
> > work starts.  Perhaps we should take a step back and start asking
> > questions first so that there is more information and consensus for
> > a formal proposal.  Questions like:
> >
> >1. What code in Tomcat really smells bad?
> >2. Based on the previews of the Servlet 2.4 and JSP 1.3 specs,
> >   what major changes are expected.
> >3. Are there any major new features needed?

Perhaps we can look into bugzilla to have a starting point here:

Entries marked as
1.) Enhancement:  May be candidates of 'new features wanted by users' or
'features needed in some user usecases'
2.) LATER: Things not implemented because it is too complicated with the
current architecture -> these might point us to design problems to be
addressed

and possibly

3.) WONTFIX: There might be some entries which have the same reason as
LATER (too complicated to implement on the existing codebase)

just my €0.02  ;)

Regards,
HAns

> >
> > My fear is that work on Tomcat 5 will turn into a CVS version of
> > the wild wild west if the proposal isn't detailed enough.
> >
>
>  +1.
>
>  I will be out of town this weekend. I'll be checking
> my mail, but I won't be able to participate as fully as I like
> for the next day or so. I can't expect everything to grind to
> a screeching halt because I'm not here. On the other hand, a
> discussion as important as this needs to take place over the
> course of a couple of normal business days so the entire
> community has a chance to give input.
>
>
> --
> Christopher St. John [EMAIL PROTECTED]
> DistribuTopia http://www.distributopia.com
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

AW: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt

[Hans Schmid]

Hi I miss the following fix in there:


Configuration:

Bug No.  Description

7520 Tomcat starts with title 3.3 instead of 3.3.1. Insert version string
during build.



Cheers,
Hans

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Gesendet: Freitag, 17. Mai 2002 07:15
> An: [EMAIL PROTECTED]
> Betreff: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt
>
>
> billbarker02/05/16 22:15:29
>
>   Modified:.RELEASE-NOTES-3.3.2.txt
>   Log:
>   Document fix for #9165
>
>   Revision  ChangesPath
>   1.7   +3 -1  jakarta-tomcat/RELEASE-NOTES-3.3.2.txt
>
>   Index: RELEASE-NOTES-3.3.2.txt
>   ===
>   RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.2.txt,v
>   retrieving revision 1.6
>   retrieving revision 1.7
>   diff -u -r1.6 -r1.7
>   --- RELEASE-NOTES-3.3.2.txt 30 Apr 2002 05:25:22 -  1.6
>   +++ RELEASE-NOTES-3.3.2.txt 17 May 2002 05:15:29 -  1.7
>   @@ -3,7 +3,7 @@
> Release Notes
> =
>
>   -$Id: RELEASE-NOTES-3.3.2.txt,v 1.6 2002/04/30 05:25:22 billbarker Exp $
>   +$Id: RELEASE-NOTES-3.3.2.txt,v 1.7 2002/05/17 05:15:29 billbarker Exp $
>
>
>This document describes the changes that have been made since the
>   @@ -36,6 +36,8 @@
>7770Fixed thread race problem in accessing the Hooks.
>
>8092Fixed JSP source exposure proplem.
>   +
>   +9165Fix auto-detection of tomcat.install for certain
> 1.1.x JDKs.
>
>Jasper:
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

AW: startup.bat window

[Hans Schmid]

First, this is clearly a tomcat-user question.

To find out, what is wrong, execute
tomcat.bat run
This will start tomcat in the same window. (TC 3.3.1 at least)

I can't help you with the mySQL question though.

Regards,
Hans

> -Ursprüngliche Nachricht-
> Von: Bill Blackmon [mailto:[EMAIL PROTECTED]]
> Gesendet: Mittwoch, 15. Mai 2002 14:16
> An: Tomcat Developers List
> Betreff: startup.bat window
>
>
> I'm trying to set the following JDBC Realm up:
> 
> to use with mySQL. Obviously there is an error because the startup.bat
> window flits off of the screen.
> What can I do in startup.bat to make it stay opened so I can see what the
> problem is? Also, can anyone point me
> to a good example or a book that covers using mySQL and Tomcat together?
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

AW: PROPOSAL: mod_jk2: Group/Instance

[Hans Schmid]

> -Ursprungliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Gesendet: Donnerstag, 2. Mai 2002 19:35
> An: Tomcat Developers List
> Betreff: Re: PROPOSAL: mod_jk2: Group/Instance
>
>
> On Thu, 2 May 2002, Bernd Koecke wrote:
>
> > misunderstood it. After you said that my patch is included a
> had a closer look
> > at mod_jk. I can't see anything of my code but I found the
> special meaning of
> > the zero lb_factor/lb_value. It seems that I didn't understand
> it right at the
> > first time. This could solve my problem but after a closer look
> and some testing
> > I found another problem. When you set the lb_value in
> workers.properties to 1
> > for the local tomcat and 0 for the others, you get the desired
> behavior. But if
> > you switch off the local tomcat for a short time you come into
> trouble. The
> > problem is the 0 for the other workers. The calculation of
> lb_worker transforms
> > the 0 to _inf_. Because 1/0 for a double is _inf_. This is
> greater than any


Thats why we use values like 0.01 in this situation in mod_jk1 and live
with the few lost sessions.

Somewhere in the tomcat-Dev archives I once saw a patch introducing a
'active' flag
for the lbfactor, but I never had the time to apply this patch and try it
out.

it was something like

worker.ajp13-01.lbfactor=1
worker.ajp13-01.active=0

in the workers.properties

(we already discussed this one in 2001 :)
http://marc.theaimsgroup.com/?l=tomcat-dev&m=100719342027584&w=4

>
> I think there is a piece that checks for 0 and sets it to DEFAULT_VALUE
> (==1 ) before doing 1/lb.
>
> While looking at the code - I'm not very sure this whole float is needed,
> I'll try to find a way to simplify it and use ints ( maybe 0..100 with
> some 'special' values for NEVER and ALLWAYS, or some additional flags ).
>
> But the way it works ( or at least how I understand it ) is that if the
> main worker fails, then we look at all workers in error state and try the
> one with the oldest error. And the 'main' worker will be tried again when
> the timeout expires.
>
>
> I haven't tested this too much, I just applied the patches ( that I
> understand :-), I'll add some more debugging for this process and maybe
> we can find a better solution.
>
> But this functionality is essential for the JNI worker and very important
> in general - so I really want to find the best solution. If you have any
> patch idea, let me know.
>
> To avoid further confusion and complexity in the lb-factor/value, I
> think we should add one more flag ( 'local_worker' ? ) and use it
> explicitely. Again, patches are wellcome - it's allways good to have
>  different ( and more ) eyes looking at the code.
>
> ( that can go in both jk1, but I can't see a release of jk2 without this
> functionality )
>
> Costin
>
>
> > other lb_value and greater than the lb_value of the local
> tomcat. But after a
> > failure of the local tomcat he is in error_state. After some
> time its set to
> > recovering and if the local tomcat is back again the function
> jk(2)_get_max_lb
> > gets the highest lb_value. This is _inf_ from one of the other
> workers. The
> > addition of a value to _inf_ is meaningless. You end up with an
> lb_value of
> > _inf_ for the local worker. If this worker isn't the first in
> the worker list,
> > it will never be choosen again. Because his lb_value will never
> be less than
> > another lb_value, because all the other workers have _inf_ as
> theire lb_values.
> > So every request without a session will be routed to the first
> of the other
> > tomcats.
> >
> > The only way out is a restart of the local apache after tomcat
> is up and
> > running. But I don't know when tomcat is finished with all his
> contexts and
> > started the connectors.
> >
> > I didn't looked very deep into jk2, but I found the same
> > get_most_suitable_worker and get_max_lb functions. The
> jk2_get_max_lb function
> > will always return _inf_. In your answer to some other mails
> you said, that
> > workers could be removed. Do I understand it right, that if my
> local tomcat goes
> > down his worker is removed from the list and after he is
> comming up again added
> > to the worker list with reseted lb_value (only for mod_jk2)?
> >
> > The next days I will look in the docu and code of jk2 and give
> it a try. May be
> > all my problems gone away with the new module :).
> >
> > Sorry if I ask stupid questions, but I want to make it working
> for our new cluster.
> >
> > Thanks
> >
> > Bernd
> >
> > > This is essential for jk2's JNI worker, which fits perfectly this case
> > > ( you don't want to send via TCP when you have a tomcat
> instance in the
> > > same process ).
> > >
> > >
> > >
> > >>(2) Tomcat instances in standby or "soft shutdown" mode where
> they serve
> > >>requests bound by established sessions, and requests without
> a session only
> > >>if all non-standby instances have failed.
> > >
> > >
> > > That's what the SHM scoreboard is going to do ( among o

AW: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common Shm.java

[Hans Schmid]

Please see questions on shm and lb worker intermixed,

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Gesendet: Donnerstag, 2. Mai 2002 05:18
> An: [EMAIL PROTECTED]
> Betreff: cvs commit:
> jakarta-tomcat-connectors/jk/java/org/apache/jk/common Shm.java
>
>
> costin  02/05/01 20:18:01
>
>   Modified:jk/java/org/apache/jk/common Shm.java
>   Log:
>   Few more features. I think the sending part works fine now (
> but we should
>   still do more tunning ).
>
>   For each tomcat instance we create a shm slot in the scoreboard. The
>   slot is named TOMCAT:host:port ( host:port is used as instance ID ), and
>   contains a ( ajp13-encoded ) structure with informations about
> the channels
>   ( currently the socket and unix channel - jni is special ). It'll also
>   include the groups where the instance belongs, and possibly other
>   informations.
>
>   If the number of channels is 0, the lb worker is supposed to stop
>   sending new requests to the instance ( but keep forwarding the
>   existing sessions ). That'll implement 'gracefull shutdown'.
>

I hope the current 'lbfactor' functionality mod_jk from TC3.3.1 will still
be working
(or an equivilent strategy):

Scenario:
We have two Tomcats in a lb group. Only one is running at a time with
lbfactor=1,
the other has lbfactor=0 assinged but is not running -> all requests go to
TC1

When we upgrade our system we update the classes/jars and start the second
Tomcat TC2 in the group,
switch the lbfactor of TC1 to 0 and the lbfactor fo TC2 to 1 and do a
graceful
restart of apache. This way old sessions still go to TC1 whereas new
sessions go to TC2.

After all sessions on TC1 have ended, we shutdown TC1 and TC2 serves
everything.

Next update goes in the oposit direction (start TC1, switch lbfactors, wait
for the end of all
sessions on TC2 and finally shutdown TC2.


Thanks,
Hans



>   Still to add:
>   - display ( nicely ) the information in the shm
>   - read info from shm ( like slots owned by apache processes with
>   statistics - in a future release )
>
>   Revision  ChangesPath
>   1.9   +27 -0
> jakarta-tomcat-connectors/jk/java/org/apache/jk/common/Shm.java
>
>   Index: Shm.java
>   ===
>   RCS file:
> /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/S
> hm.java,v
>   retrieving revision 1.8
>   retrieving revision 1.9
>   diff -u -r1.8 -r1.9
>   --- Shm.java1 May 2002 22:40:17 -   1.8
>   +++ Shm.java2 May 2002 03:18:01 -   1.9
>   @@ -95,6 +95,7 @@
>
>boolean unregister=false;
>boolean reset=false;
>   +String dumpFile=null;
>
>// Will be dynamic ( getMethodId() ) after things are stable
>static final int SHM_SET_ATTRIBUTE=0;
>   @@ -102,6 +103,8 @@
>static final int SHM_ATTACH=3;
>static final int SHM_DETACH=4;
>static final int SHM_RESET=5;
>   +static final int SHM_DUMP=6;
>   +static final int SHM_DESTROY=7;
>
>public Shm() {
>}
>   @@ -112,6 +115,13 @@
>file=f;
>}
>
>   +/** Copy the scoreboard in a file for debugging
>   + *  Will also log a lot of information about what's in the
> scoreboard.
>   + */
>   +public void setDump( String dumpFile ) {
>   +this.dumpFile=dumpFile;
>   +}
>   +
>/** Size. Used only if the scoreboard is to be created.
> */
>public void setSize( int size ) {
>   @@ -199,6 +209,20 @@
>this.invoke( msg, mCtx );
>}
>
>   +public void dumpScoreboard(String fname) throws IOException {
>   +if( apr==null ) return;
>   +MsgContext mCtx=createMsgContext();
>   +Msg msg=(Msg)mCtx.getMsg(0);
>   +C2BConverter c2b=(C2BConverter)mCtx.getNote(C2B_NOTE);
>   +msg.reset();
>   +
>   +msg.appendByte( SHM_DUMP );
>   +
>   +appendString( msg, fname, c2b);
>   +
>   +this.invoke( msg, mCtx );
>   +}
>   +
>public void setNativeAttribute(String name, String val)
> throws IOException {
>if( apr==null ) return;
>MsgContext mCtx=createMsgContext();
>   @@ -315,8 +339,11 @@
>return;
>}
>init();
>   +
>if( reset ) {
>resetScoreboard();
>   +} else if( dumpFile!=null ) {
>   +dumpScoreboard(dumpFile);
>} else if( unregister ) {
>unRegisterTomcat( host, port );
>} else {
>
>
>
>
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

AW: AW: PROPOSAL: mod_jk2 autoconfig

[Hans Schmid]

> -Ursprungliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Gesendet: Dienstag, 30. April 2002 16:39
> An: Tomcat Developers List
> Betreff: Re: AW: PROPOSAL: mod_jk2 autoconfig
>
>
> On Tue, 30 Apr 2002, Hans Schmid wrote:
>
> > I can not see how this works if you have Apache and Tomcat on different
> > machines.
> > This way we do not have a webapp/ directory on that Apache server.
>
> It works fine.
>
> There are 2 cases:
> 1. You want Apache to serve static pages. That's the 'normal' case, and
> it automatically require that you _have_ the webapp (at lest the static
> pages, you can remove the clasesses, lib, etc ) on the apache server.
>
> 2. You don't want apache to serve static pages for the app. In this case
> you'll just put a small file in the webapp/ ( myApp.jk2 or something
> similar - see how 3.3 apps-myApp.xml or 4.1 webapps/myApp.xml works ),
> with the single mapping that is required to forward all requests.
>

We have lots of not webapp related static stuff so we have set the
DocumenRoot of apache
at our static 'source' tree (not tomcat related source tree).

For the few bits of static content in our webapps (few logos) we do not
really care (yet).
They are served by Tomcat.

This has all historic reasons. This is an old system migrating slowly :)

So we do not even have a Tomcat installed on our webservers - so no webapps
directories.

> Even in the second case, I think it is easier to 'deploy' one conf file
> per webapp in a clear format than editing workers.properties.
>
> > Did I misunderstand the intent of this configuration? Is it a
> 'best guess'
> > for simple setups?
> > Probably in our scenario we have to configure it manually anyways.
>
> Manual configuration will work, of course. In tomcat you can still edit
> server.xml. It's just that I would strongly discourage that for 'normal'
> use.
>

We make heavy use of the apps-myall.xml files in TC 3.3.1 - but as I said,
no Tomcat on our webservers.
We have 2 hardware loadbalanced small pizzaboxes running Apache and three
bigger Solaris machines
running our Tomcats and the database.

> > > Some 'special' files ( like in 4.1 and the 3.3 apps- files ) will
> > > also be read and used to load webapps that sit in different
> directories.
> >
> > same here we are on different machines.
>
> Again, all you need is to install 1 file on the server machine for each
> webapp ( without static files ).
>
> I personally believe that is a very bad choice to not let apache serve
> the static files, but it'll work.

Have not yet figured out how to combine our static DocumentRoot plus serving
static
contents from our webapps.

>
> > Just make sure, everything in the config can be overwritten and
> configures
> > manually
> > if possible in a single file (as workers.properties right now)
>
> Either workers2.properties, or one file in the webapps ( named
> after the application, with .jk2 extension ).
>
> The file can be used if you have the docRoot in a different place in
> the apache server.
>
>

exactly this is our setup. So we will use a workers2.properties.

Thanks for clarifying.

Cheers,
Hans


> Costin
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

AW: PROPOSAL: mod_jk2 autoconfig

[Hans Schmid]

See intermixed

> -Ursprungliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Gesendet: Montag, 29. April 2002 19:17
> An: List Tomcat-Dev
> Betreff: PROPOSAL: mod_jk2 autoconfig
>
>
> Hi,
>
> I spent a lot of time on this - and I think this is a very good solution.
> Please send feedback - the sooner the better...
>
> I think the current solution of generating configs on tomcat startup,
> or having tomcat send it's config to apache is wrong.
>
> Basically what I would like to propose is similar with what Glen
> implemented in jk1 for apache1.3 ( the webapp/ directory
> auto-conf )- with
> few enhancements.
>
> The major requirement is that mod_jk2 is configured with the location
> of the webapp/ directory. Inside webapp, it'll look for directories
> and configure them automatically, like tomcat is doing.

I can not see how this works if you have Apache and Tomcat on different
machines.
This way we do not have a webapp/ directory on that Apache server.

Or does this work across several machines?

We have two Apache 1.3 servers which are busy serving static contents plus
PHP legacy stuff.
We run at least 4 Tomcats on two different servers to distribute our
webapps.

Did I misunderstand the intent of this configuration? Is it a 'best guess'
for simple setups?
Probably in our scenario we have to configure it manually anyways.

>
> Some 'special' files ( like in 4.1 and the 3.3 apps- files ) will
> also be read and used to load webapps that sit in different directories.

same here we are on different machines.

>
> In addition, a separate directory ( named ??? ) can be used with a
> host-based hierarchy. Given that most users are using a single
> host and the current webapps/ habbits, the vhost hierarchy will
> be different from the 'default server'.
>
> For each discovered webapp ( either directory or CONTEXT.jk2 file ) , jk
> will look for WEB-INF/jk2/map.properties and load the file.
>

I would need a complete webapp structure for configurating mod_jk2 on a
server
which does not have any tomcat - and webapp installed.

Just make sure, everything in the config can be overwritten and configures
manually
if possible in a single file (as workers.properties right now)

But I agree the concept is nice for simple setups.

> The map.properties file will be generated from web.xml - using a
> small tool ( I'll commit the first code shortly ) that is independent
> of tomcat ( it doesn't require starting tomcat ). It can be used
> as CLI, as ant task or as a bean inside an admin or deploy application.
>
> The tool curently uses DOM - and very simple and strictly specialized
> code, no "LoadModule" or anything that is beyond web.xml content.
> In addition, the tool may generate Apache-specific configuration
> fragments for the 'native' mapper ( as you may remember, jk2 can
> map URIs using it's internal mapper - but also using 
> and Set-Handler directives ). It'll also generate JkMounts for
> backward compat.
>
> All other code from the jk1 autoconf will be separated ( or replaced
> with some templates ) - the location of jk, other global settings
> are better to be done manually ( and have decent defaults ).
>
> Finally, the shmem system that is ( will be ) used for autoconfiguration
> of workers ( i.e. when a tomcat starts up it can add itself automatically,
> without admin intervention ) can be used by the deploy/admin tool to
> reconfigure uri mappings ( with the common mapper, the native mapper
> still requires a soft restart - but that can be automated as well ).
>
> Implementation-wise - this is not difficult, and can be done pretty
> fast if Glenn and few other people step in.
>
> I believe that's going to be very close to 'minimal' pain for the
> regular user while preserving the ability to fine tune everything.
>
> NOTE: jk2 will use a different model for the lb, see next mail.
>
> Costin
>
>
>
>
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 

Thanks,
Hans



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

AW: Apache1.3/mod_jk (unix) & Tomcat 4 & No processor available, rejecting this connection

[Hans Schmid]

Hi,

what about Tomcat 3.3 ?

Does this correspond to Ajp13Connector maxThreads >= the maxiumum number
of Apache httpd processes in this case?

Thanks,
Hans

> -Ursprungliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im
> Auftrag von Glenn Nielsen
> Gesendet: Freitag, 22. Marz 2002 16:39
> An: [EMAIL PROTECTED]
> Betreff: Apache1.3/mod_jk (unix) & Tomcat 4 & No processor available,
> rejecting this connection
>
>
> I have finally figured out why sometimes the Tomcat4 Ajp13Connector
> would refuse connections.
>
>
> Each Apache1.3 httpd process using mod_jk establishes a single connection
> to Tomcat the first time it has to forward a request to Tomcat.
> That connection is only used by that httpd process.
>
> mod_jk can fail to make a new connection to Tomcat when an httpd process
> forwards its first request to Tomcat if the number of httpd
> processes which
> have already established a connection to Tomcat exceeds the
> Ajp13Connector
> maxProcessors setting.
>
> So it is critical that the Ajp13Connector maxProcessors be set >=
> the maxiumum number of Apache httpd processes.
>
> This may be a known config issue, but I haven't any documentation
> for this issue.
>
> Regards,
>
> Glenn
>
> --
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> MOREnet System Programming   |  * if iz ina coment.  |
> Missouri Research and Education Network  |  */   |
> --
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

AW: AW: mod_jk suggestion, add "request" logging option

[Hans Schmid]

> -Ursprungliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im
> Auftrag von Glenn Nielsen
> Gesendet: Donnerstag, 21. Februar 2002 19:28
> An: Tomcat Developers List
> Betreff: Re: AW: mod_jk suggestion, add "request" logging option
>
>
> Hans Schmid wrote:
> >
> > Hi,
> >
> > what about adding 'port' to the list.
> >
>
> Is this the port the http request came in on, or the port for the worker?

I thought of the host and port of the worker. In our setup we send different
workers to different hosts (even loadbalanced workers) So its easy to see
where
the request was sent to.

But if we can configure, which of the fields we want to see in the log there
can't
be too much availlable :)

Cheers, Hans


>
> > For lb workers the worker would be the real one used not 'loadbalancer',
> > right?
> >
>
> Yes, you would want the worker which points at the actual instance of
> Tomcat the request was forwarded to.
>
> > I think it would be really helpful to have this log level.
> >
> > Cheers,
> > Hans
> >
> > > -Ursprungliche Nachricht-
> > > Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]Im
> > > Auftrag von Glenn Nielsen
> > > Gesendet: Donnerstag, 21. Februar 2002 16:57
> > > An: Tomcat Developers List
> > > Betreff: Re: mod_jk suggestion, add "request" logging option
> > >
> > >
> > > Updated list of fields for request logging.
> > >
> > > Timestamp
> > > worker
> > > host
> > > URI
> > > Status (OK, FAIL, etc)
> > > Latency (Time in ms or us to handle request)
> > >
> > > Glenn
> > >
> > > Glenn Nielsen wrote:
> > > >
> > > > Currently mod_jk has four logging levels - (debug,info,error,emerg).
> > > >
> > > > I suggest a fifth log level be added called "request".
> > > > (debug, info, request, error, emerg)
> > > >
> > > > This log level would log each request with the following
> possible info,
> > > > what info is logged could be controlled by an new config option
> > > > JkLogRequestFormat.
> > > >
> > > > Timestamp
> > > > URI
> > > > Status (OK, FAIL, etc)
> > > > Latency (Time in ms or us to handle request)
> > > >
> > > > And there may be other fields of interest to add to the above list.
> > > >
> > > > I am most interested in using mod_jk to log the request latency for
> > > > Tomcat to handle different requests so that statistics can
> be generated.
> > > >
> > > > Having mod_jk do this instead of Tomcat avoids violating
> the heisenberg
> > > > principal.
> > > >
> > > > Regards,
> > > >
> > > > Glenn
> > > >
> > > >
> --
> > > > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut
> madder|
> > > > MOREnet System Programming   |  * if iz ina
> coment.  |
> > > > Missouri Research and Education Network  |  */
>  |
> > > >
> --
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> > --
> > --
> > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> > MOREnet System Programming   |  * if iz ina coment.  |
> > Missouri Research and Education Network  |  */   |
> > --
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> --
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> MOREnet System Programming   |  * if iz ina coment.  |
> Missouri Research and Education Network  |  */   |
> --
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

AW: mod_jk suggestion, add "request" logging option

[Hans Schmid]

Hi,

what about adding 'port' to the list.

For lb workers the worker would be the real one used not 'loadbalancer',
right?

I think it would be really helpful to have this log level.

Cheers,
Hans

> -Ursprungliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im
> Auftrag von Glenn Nielsen
> Gesendet: Donnerstag, 21. Februar 2002 16:57
> An: Tomcat Developers List
> Betreff: Re: mod_jk suggestion, add "request" logging option
>
>
> Updated list of fields for request logging.
>
> Timestamp
> worker
> host
> URI
> Status (OK, FAIL, etc)
> Latency (Time in ms or us to handle request)
>
> Glenn
>
> Glenn Nielsen wrote:
> >
> > Currently mod_jk has four logging levels - (debug,info,error,emerg).
> >
> > I suggest a fifth log level be added called "request".
> > (debug, info, request, error, emerg)
> >
> > This log level would log each request with the following possible info,
> > what info is logged could be controlled by an new config option
> > JkLogRequestFormat.
> >
> > Timestamp
> > URI
> > Status (OK, FAIL, etc)
> > Latency (Time in ms or us to handle request)
> >
> > And there may be other fields of interest to add to the above list.
> >
> > I am most interested in using mod_jk to log the request latency for
> > Tomcat to handle different requests so that statistics can be generated.
> >
> > Having mod_jk do this instead of Tomcat avoids violating the heisenberg
> > principal.
> >
> > Regards,
> >
> > Glenn
> >
> > --
> > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> > MOREnet System Programming   |  * if iz ina coment.  |
> > Missouri Research and Education Network  |  */   |
> > --
> >
> > --
> > To unsubscribe, e-mail:

> For additional commands, e-mail:


--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Loadbalancer problems in mod_jk 4.0.3 [was Native Connector problems]

[Hans Schmid]

 (300)]: Into
jk_endpoint_t::service
[Tue Feb 12 15:28:32 2002]  [jk_ajp13_worker.c (865)]: Into
jk_worker_t::get_endpoint
[Tue Feb 12 15:28:32 2002]  [jk_ajp13_worker.c (775)]: Into
jk_endpoint_t::service
[Tue Feb 12 15:28:32 2002]  [jk_ajp13.c (403)]: Into ajp13_marshal_into_msgb
[Tue Feb 12 15:28:32 2002]  [jk_ajp13.c (537)]: ajp13_marshal_into_msgb -
Done
[Tue Feb 12 15:28:32 2002]  [jk_connect.c (108)]: Into jk_open_socket
[Tue Feb 12 15:28:32 2002]  [jk_connect.c (115)]: jk_open_socket, try to
connect socket = 38
[Tue Feb 12 15:28:32 2002]  [jk_connect.c (124)]: jk_open_socket, after
connect ret = 0
[Tue Feb 12 15:28:32 2002]  [jk_connect.c (132)]: jk_open_socket, set
TCP_NODELAY to on
[Tue Feb 12 15:28:32 2002]  [jk_connect.c (140)]: jk_open_socket, return, sd
= 38
[Tue Feb 12 15:28:32 2002]  [jk_ajp13_worker.c (189)]: In
jk_endpoint_t::connect_to_tomcat, connected sd = 38
[Tue Feb 12 15:28:32 2002]  [jk_ajp13_worker.c (206)]: sending to ajp13 #436
[Tue Feb 12 15:28:32 2002]  [jk_ajp13_worker.c (645)]: send_request 2:
request body to send 0 - request body to resend 0
[Tue Feb 12 15:28:34 2002]  [jk_ajp13_worker.c (258)]: received from ajp13
#82



4.0.2 version of mod_jk:

[Tue Feb 12 15:27:02 2002]  [jk_uri_worker_map.c (464)]: Attempting to map
URI '/einsurance/doEntry.do'
[Tue Feb 12 15:27:02 2002]  [jk_uri_worker_map.c (489)]:
jk_uri_worker_map_t::map_uri_to_worker, Found a context match
loadbalancer -> /einsurance/
[Tue Feb 12 15:27:02 2002]  [jk_worker.c (132)]: Into wc_get_worker_for_name
loadbalancer
[Tue Feb 12 15:27:02 2002]  [jk_worker.c (136)]: wc_get_worker_for_name,
done  found a worker
[Tue Feb 12 15:27:02 2002]  [jk_lb_worker.c (487)]: Into
jk_worker_t::get_endpoint
[Tue Feb 12 15:27:02 2002]  [jk_lb_worker.c (306)]: Into
jk_endpoint_t::service
[Tue Feb 12 15:27:02 2002]  [jk_ajp_common.c (1345)]: Into
jk_worker_t::get_endpoint
[Tue Feb 12 15:27:02 2002]  [jk_ajp_common.c (1075)]: Into
jk_endpoint_t::service
[Tue Feb 12 15:27:02 2002]  [jk_ajp_common.c (280)]: Into
ajp_marshal_into_msgb
[Tue Feb 12 15:27:02 2002]  [jk_uri_worker_map.c (447)]: Into
jk_uri_worker_map_t::map_uri_to_worker
[Tue Feb 12 15:27:02 2002]  [jk_uri_worker_map.c (464)]: Attempting to map
URI '/einsurance/doEntry.do'
[Tue Feb 12 15:27:02 2002]  [jk_uri_worker_map.c (489)]:
jk_uri_worker_map_t::map_uri_to_worker, Found a context match
loadbalancer -> /einsurance/
[Tue Feb 12 15:27:02 2002]  [jk_worker.c (132)]: Into wc_get_worker_for_name
loadbalancer
[Tue Feb 12 15:27:02 2002]  [jk_worker.c (136)]: wc_get_worker_for_name,
done  found a worker
[Tue Feb 12 15:27:02 2002]  [jk_lb_worker.c (487)]: Into
jk_worker_t::get_endpoint
[Tue Feb 12 15:27:02 2002]  [jk_lb_worker.c (306)]: Into
jk_endpoint_t::service
[Tue Feb 12 15:27:02 2002]  [jk_ajp_common.c (1345)]: Into
jk_worker_t::get_endpoint
[Tue Feb 12 15:27:02 2002]  [jk_ajp_common.c (1075)]: Into
jk_endpoint_t::service
[Tue Feb 12 15:27:02 2002]  [jk_ajp_common.c (280)]: Into
ajp_marshal_into_msgb
[Tue Feb 12 15:27:02 2002]  [jk_uri_worker_map.c (447)]: Into
jk_uri_worker_map_t::map_uri_to_worker
[Tue Feb 12 15:27:02 2002]  [jk_uri_worker_map.c (464)]: Attempting to map
URI '/einsurance/doEntry.do'
[Tue Feb 12 15:27:02 2002]  [jk_uri_worker_map.c (489)]:
jk_uri_worker_map_t::map_uri_to_worker, Found a context match
loadbalancer -> /einsurance/
[Tue Feb 12 15:27:02 2002]  [jk_worker.c (132)]: Into wc_get_worker_for_name
loadbalancer
[Tue Feb 12 15:27:02 2002]  [jk_worker.c (136)]: wc_get_worker_for_name,
done  found a worker
[Tue Feb 12 15:27:02 2002]  [jk_lb_worker.c (487)]: Into
jk_worker_t::get_endpoint
[Tue Feb 12 15:27:02 2002]  [jk_lb_worker.c (306)]: Into
jk_endpoint_t::service
[Tue Feb 12 15:27:02 2002]  [jk_ajp_common.c (1345)]: Into
jk_worker_t::get_endpoint
[Tue Feb 12 15:27:02 2002]  [jk_ajp_common.c (1075)]: Into
jk_endpoint_t::service
[Tue Feb 12 15:27:02 2002]  [jk_ajp_common.c (280)]: Into
ajp_marshal_into_msgb
[Tue Feb 12 15:27:02 2002]  [jk_uri_worker_map.c (447)]: Into
jk_uri_worker_map_t::map_uri_to_worker


Thanks a lot for looking into this,

Best Regards,
Hans





-Ursprungliche Nachricht-
Von: Hans Schmid [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 13. Februar 2002 08:23
An: Tomcat Developers List
Betreff: AW: Native Connector problems


Hi,

I just ran into a problem with the loadbalancing stuff.

I built mod_jk.so from the 4.0.2 connector package and replaced my
mod_jk.so (TC3.3 Version) with this one in apache/libexec (1.3.19).

By just changing a link back and forth between the two versions, I tested
our TC3.3 based application against the two versions of mod_jk.
If this is not enough and I am missing something, please let me know.
Otherwise exactly the same setup

All works perfectly with the new mod_jk when I use normal ajp13 workers
(one webapp), but fails when I use a loadbalancing worker pointing to
another webapp on a different Tomcat instance.

I do not have the mod_jk.log here at home. Will 

AW: Native Connector problems

[Hans Schmid]

Hi, 

I just ran into a problem with the loadbalancing stuff.

I built mod_jk.so from the 4.0.2 connector package and replaced my 
mod_jk.so (TC3.3 Version) with this one in apache/libexec (1.3.19).

By just changing a link back and forth between the two versions, I tested
our TC3.3 based application against the two versions of mod_jk.
If this is not enough and I am missing something, please let me know.
Otherwise exactly the same setup 

All works perfectly with the new mod_jk when I use normal ajp13 workers 
(one webapp), but fails when I use a loadbalancing worker pointing to 
another webapp on a different Tomcat instance.

I do not have the mod_jk.log here at home. Will send it in a couple of 
hours when I am in the office.

What else would be required for debugging? 


Note, We use the loadbalancer just for switching tomcats. Only one 
instance of the two loadbalanced Tomcats is active most of the time.
(by changing the lbvalue)

Thanks,
Hans

 

> -Ursprungliche Nachricht-
> Von: Mike Anderson [mailto:[EMAIL PROTECTED]]
> Gesendet: Mittwoch, 13. Februar 2002 02:17
> An: [EMAIL PROTECTED]
> Betreff: RE: Native Connector problems
> 
> 
> The problem is that the default cache size is one and in the ajp_init
> function
> in jk_ajp_common.c we return from inside of an if when we initialize
> the cache
> so the secrect member of the structure never gets initialized.  This
> caused
> some GPFs in certain cases on some of my builds.
> 
> I've checked in the fix.  All I did was move the line that initializes
> secret up above
> the if statement.
> 
> Remy, would it be possible to relabel jk_ajp_common.c
> rev. 1.24 as the rev for tomcat_402?  I've built and tested this fix on
> NetWare
> and the resolved my GPFs and bad behavior talking to older
> installations
> of Tomcat (i.e. 3.3).  I was able to use the same module to talk to 
> Tomcat 4.0.2 and Tomcat 3.3 from the same instance of the web server.
> I love it when a plan comes together :-)
> 
> Mike Anderson
> 
> 
> >>> [EMAIL PROTECTED] 02/12/02 05:19PM >>>
> >One of the last changes on the connector ( the secret ) 
> >introduced a bug,
> >when worker_cache is enabled. The secret will not be initialized, and
> 
> >that may creates all kind of serious problems.
> 
> Could you detail the problem ?
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

WG: TC3.3 updating a webapp without killing sessions

[Hans Schmid]

Hi,

since Costin is currently refactoring mod_jk in jakarta-tomcat-connectors
I want to throw in our usage scenario.

We are abusing the loadbalancing feature of mod_jk to switch
tomcats on the fly in order to be able to make application updates
without killing our curreent user sessions. See discussion below from
tomcat-user

This feature (graceful restart) was present in jserv and is still missing
in mod_jk/Tomcat3.3 as far as I know.

Below are references to the archive where Michael Kuz has sent a patch to
decouple this feature from the lbfactor (introducing an active flag).

So please keep in mind the requirement to be able to update Webapps in
a farm of Tomcats without killing active sessions.

Thanks,
Hans



-Ursprüngliche Nachricht-
Von: Hans Schmid [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 28. November 2001 18:21
An: Tomcat Users List
Betreff: AW: TC3.3 updating a webapp without killing sessions


Thanks Larry,

perhaps a lbfactor of 0.1 or so would do the job for us.
We could probably live with 1 out of 10 sessions beeing
sent to the wrong Tomcat and beeing killed if this instance
shuts down.

Should this be discussed in tomcat-dev ?

I remember a patch from early this year which tried to fix this
(check the archives) but did never make it into the release
It tried to add a flag called 'active' in the worker.properties
file for each worker instead of misusing the lbfactor for this.


ajp13-01...
lbfactor=1
active=0

and
ajb13-02...
lbfactor=1
active=1

see
http://w6.metronet.com/~wjm/tomcat/2001/Jan/msg00102.html
and
http://w6.metronet.com/~wjm/tomcat/2001/Jan/msg00114.html
for the patch which might be a little bit outdated



> -Ursprüngliche Nachricht-
> Von: Larry Isaacs [mailto:[EMAIL PROTECTED]]
> Gesendet: Mittwoch, 28. November 2001 15:00
> An: 'Tomcat Users List'
> Betreff: RE: TC3.3 updating a webapp without killing sessions
>
>
> I assume the value or lbfactor is requested to be >0
> because 1/lbfactor is calculated during initialization.
> Since this is done with doubles, it may generate an
> internal representation for infinity rather than a division
> by zero error.
>
> I don't have a complete understanding of what mod_jk
> does internally for loadbalancing, but your approach
> seems like it should work.  A brief scan of the codes
> shows that some updates to mod_jk would be needed
> to insure that lbfactor=0 means only use this worker
> when mandated by session routing.
>
> There isn't much logging around the choice of worker.
> Perhaps adding some logging would help determine
> why requests are being routed to the lbfactor=0
> Tomcat when session routing shouldn't be a factor.
>
> Hope this helps.
>
> Cheers,
> Larry
>
>
> > -Original Message-
> > From: Hans Schmid [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, November 28, 2001 4:25 AM
> > To: Tomcat-User
> > Subject: TC3.3 updating a webapp without killing sessions
> >
> >
> > Hi,
> >
> > We try to make a workaround for the following problems:
> > 1.) memory management
> > 2.) application update
> > 3.) do not kill active sessions
> >
> > Perhaps someone can comment on the startegy and answer some questions.
> >
> >
> > Our environment:
> > Tomcat 3.3 final with mod_jk Apache 1.3.19 on Solaris 2.7 Sparc
> >
> > Our problem:
> > ever growing cache until memory runs out (clearly an
> > application problem)
> > plus soft updates to our application without killing actiove sessions
> >
> > The idea:
> > when a certain ammount of memory is reached by the tomcat
> > java process,
> > start up a second
> > Tomcat and route all new requests to the second instance
> > while existing
> > sessions should phase out
> > on the first instance.
> > If no more sessions are active on the original Tomcat, shut it down
> > (currently we just shut it down 30 minutes after the second
> > Tomcat started
> > up)
> >
> > How to do it with mod_jk:
> > We have two versions of a worker.properties. Before we start
> > up our second
> > tomcat,
> > we switch a link to point to the other version.
> >
> > Both versions of the worker.property file have a loadbalancer worker
> > defined:
> >
> > First version:
> > worker.list=loadbalancer
> >
> > worker.ajp13-01.port=11009
> > worker.ajp13-01.host=tomcathost
> > worker.ajp13-01.type=ajp13
> > worker.ajp13-01.lbfactor=1  <- important
> >
> > worker.ajp13-02.port=11019
> > worker.ajp13-02.host=tomcathost
> > worker.ajp13-02.type=ajp13
> > worker.ajp13-02.lbfactor=0  <

AW: tomcat in the production environment

[Hans Schmid]

Hi Kandasamy.

we are using Tomcat 3.3 on our production site. Solaris 2.7 Sparc, 2
processors,
JDK 1.3.1_01 mod_jk ajp1.3 behind two Apache 1.3.19 with a HW loadbalancer
in front.
And still our single Tomcat 3.3 instance is not the bottleneck. Currently it
is our
Oracle machine :)
BTW. we make heavy use of Velocity as well.

We have currently up to 200 concurrent users and I must say, Tomcat is the
most
stable and reliable piece in our architecture.

We have some JVM crashes when the heap fills up and sometimes at startup
(when there are already
many customers trying to log in) But this is clearly the JVM - not Tomcat.

But it is true, you have to make test for your environment.

All the best,

Regards,
Hans


> -Ursprüngliche Nachricht-
> Von: T. Kandasamy [mailto:[EMAIL PROTECTED]]
> Gesendet: Freitag, 23. November 2001 11:02
> An: 'Tomcat Developers List'
> Betreff: RE: tomcat in the production environment
>
>
> Hi Bojan:
>
> Thanks for your kind reply. How about the stability of the tomcat
> i.e.if the
> number of concurrent increases. whether the tomcat will be stable? or
> getting
> crashed. Please let me know, do you use tomcat in the production server?
>
> regards
> Kandasamy
> Singapore
>
> -Original Message-
> From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 23, 2001 5:39 PM
> To: Tomcat Developers List
> Subject: Re: tomcat in the production environment
>
>
> "T. Kandasamy" wrote:
> >
> > Hi
> >
> > In our organization, we are trying to put the tomcat 3.3 in the
> production
> > environment. I wish to see
> > some performance test results of the tomcat. Is it highly
> stable?. If any
> is
> > using the tomcat in the
> > production/ live server, please share your experinces with me.
> >
> > we have successfully integrated apache web server with tomcat.
> I unable to
> > see performance results
> > in the jakarata.apache.org. How concurrent requests it will handle?. we
> are
> > having redhad linux with
> > processor and 4gb ram machine. please give your reply
>
> I wouldn't rely on any benchmarks or experiences of others since they
> could be a result of a totally different scenario then yours. There is a
> simple tool called 'ab' that comes with Apache. It is extremely easy to
> simulate server load with it. I suggest you try it in your environment
> and make decisions for yourself.
>
> Bojan
>
> PS. My own benchmarks show that a P2 266 with 288 MB of RAM, 2 UW SCSI
> disks, running RedHat Linux 7.0 with selective Rawhide updates, kernel
> 2.4.14, Apache 1.3.22 and TC 3.3 can serve around 60 requests per second
> (or 17 ms per request) at concurrency of 10 requests, using one of my
> typical Velocity pages... which is probably totally irrelevant for your
> scenario.
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

WG: worker.properties swallows my first worker (mod_jk)

[Hans Schmid]

Hi,

just filed a bug on Larrys request

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3467

Thanks for looking into this one.

Cheers,
Hans


-Ursprüngliche Nachricht-
Von: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 6. September 2001 19:39
An: '[EMAIL PROTECTED]'
Betreff: RE: worker.properties swallows my first worker (mod_jk)


Hi Hans,

The answers to your questions are:

1.) Why gets this hardcoded worker on port 8007 created?

Don't know, I will investigate.

2.) Is this a Bug I shall report?

   Yes, and please attache the workers.properties in question.

Thanks.

Larry


> -Original Message-
> From: Hans Schmid [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 06, 2001 12:57 PM
> To: Tomcat-User
> Subject: worker.properties swallows my first worker (mod_jk)
>
>
> Hello,
>
> This is about mod_jk in Tomcat 3.3b1 on Solaris with Apache 1.3.19
>
> It seems to me that the first worker found in the worker.list
> always gets
> created as ajp12 on port 8007
> regardless what i configure.
>
> The following worker.list entry
> worker.list=worker.list=ajp12-01, ajp12-02, ajp13-01, ajp13-02
>
> produces 4 workers:
> ajp12-01 on port 8007  ajp12
> ajp12-02 on port 9017  ajp12
> ajp13-01 on port 9009  ajp13
> ajp13-02 on port 9019  ajp13
>
> instead of the expected:
> ajp12-01 on port 9007  ajp12
> ajp12-02 on port 9017  ajp12
> ajp13-01 on port 9009  ajp13
> ajp13-02 on port 9019  ajp13
>
> Please note the ajp12-01 worker points to port 8007 instead of 9007.
>
> When I put a space in front of the first worker I get my
> expected 4 workers
> pointing to the correct ports
> plus a 5th worker ('' on port 8007)
>
>
> The following entry in workers.properties
> worker.list=worker.list= ajp12-01, ajp12-02, ajp13-01, ajp13-02
>
> produces 5 workers instead of 4
> Please note the port 8007 for the first worker named
> worker.list= of ajp12
> I do not have a worker assigned to this port (greped through
> all config
> files).
>
>
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (207)]: Into
> build_worker_map,
> creating 5 workers
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (213)]:
> build_worker_map, creating
> worker worker.list=
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (138)]: Into wc_create_worker
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (152)]:
> wc_create_worker, about to
> create instance worker.list= of ajp12
> [Thu Sep 06 18:26:17 2001]  [jk_ajp12_worker.c (264)]: Into
> ajp12_worker_factory
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (161)]:
> wc_create_worker, about to
> validate and init worker.list=
> [Thu Sep 06 18:26:17 2001]  [jk_ajp12_worker.c (182)]: Into
> jk_worker_t::validate
> [Thu Sep 06 18:26:17 2001]  [jk_ajp12_worker.c (194)]: In
> jk_worker_t::validate for worker worker.list= contact is
> localhost:8007
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (177)]:
> wc_create_worker, done
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (223)]:
> build_worker_map, removing
> old worker.list= worker
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (213)]:
> build_worker_map, creating
> worker ajp12-01
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (138)]: Into wc_create_worker
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (152)]:
> wc_create_worker, about to
> create instance ajp12-01 of ajp12
> [Thu Sep 06 18:26:17 2001]  [jk_ajp12_worker.c (264)]: Into
> ajp12_worker_factory
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (161)]:
> wc_create_worker, about to
> validate and init ajp12-01
> [Thu Sep 06 18:26:17 2001]  [jk_ajp12_worker.c (182)]: Into
> jk_worker_t::validate
> [Thu Sep 06 18:26:17 2001]  [jk_ajp12_worker.c (194)]: In
> jk_worker_t::validate for worker ajp12-01 contact is localhost:9007
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (177)]:
> wc_create_worker, done
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (223)]:
> build_worker_map, removing
> old ajp12-01 worker
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (213)]:
> build_worker_map, creating
> worker ajp12-02
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (138)]: Into wc_create_worker
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (152)]:
> wc_create_worker, about to
> create instance ajp12-02 of ajp12
> [Thu Sep 06 18:26:17 2001]  [jk_ajp12_worker.c (264)]: Into
> ajp12_worker_factory
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (161)]:
> wc_create_worker, about to
> validate and init ajp12-02
> [Thu Sep 06 18:26:17 2001]  [jk_ajp12_worker.c (182)]: Into
> jk_worker_t::validate
> [Thu Sep 06 18:26:17 2001]  [jk_ajp12_worker.c (194)]: In
> jk_worker_t::validate for worker ajp12-02 contact is localhost:9017
> [Thu Sep 06 18:26:17 2001]  [jk_worker.c (177)]:
> wc_creat

[PATCH] Tomcat 3.3 m3 mod_jk-howto.html (new Bug #1809)

[Hans Schmid]

Hello,

I just installed Tomcat3.3-m3 with ajpv13 behind Apache 1.3.19 on Win2000.

While setting up mod_jk with ajp1.3, I noticed a bug in the
mod_jk-howto.html
It states:


Add the following block to your TOMCAT_HOME/conf/server.xml file.


  
  



but this is the way Tomcat 3.2.2 has to be setup.

In TC 3.3 the entry should be:




and its enabled by default.

Anyway, I have attatched diffs against /src/doc/mod_jk-howto.html. This is
the new paragraph:


---
(Optional) Configuring Tomcat to use the Ajpv13 protocol
mod_jk can use either the original Ajpv12 protocol or the newer Ajpv13
protocol. If you choose the latter, you need to activate the "Ajp13"
Connection Handler in Tomcat. This will give you the benefit of a faster
protocol and the ability to identify requests made via HTTPS.

Add the following block to your TOMCAT_HOME/conf/server.xml file.

  
  


The server.xml file already has a block similar to this for Ajp12
connections on port 8007 (as delivered by mod_jserv). Even if you think
you're only using Ajp13, you probably don't want to delete this connector --
it's required to shut down Tomcat.

---

There is a mod_jk-howto.html in proposals as well. I don't know, if this
patch should be applied to this one as well.

I hope this helps a little bit since there seems to be so much confusion in
the user-list about setting up mod_jk.

Best regards,

Hans


--- mod_jk-howto.html.orig  Fri May 18 14:22:58 2001
+++ mod_jk-howto.html   Fri May 18 14:32:21 2001
@@ -643,14 +643,13 @@
 (Optional) Configuring Tomcat to use the Ajpv13 protocol
 
 mod_jk can use either the original Ajpv12 protocol or the newer Ajpv13 protocol.
-If you choose the latter, you need to activate the "Ajp13" Connection 
Handler in Tomcat. This
-will give you the benefit of a faster protocol and the ability to identify requests 
made via HTTPS.
-Add the following block to your TOMCAT_HOME/conf/server.xml file.
+Both protocols are enabled by default. The "Ajp13" Connection Handler in 
+Tomcat will
+give you the benefit of a faster protocol and the ability to identify requests made 
+via HTTPS.
+The following block enables Ajpv13 in your TOMCAT_HOME/conf/server.xml file.
 
-
-  
-  
-
+
 
 
 The server.xml file already has a block similar to this for

[PATCH] JSP examples TC 3.3 latest

[Hans Schmid]

Hi folks,

there is still a little bug in the TC 3.3 JSP examples after my patch has
been applied.

The JSP-Servlet-JSP example does not show the Source code (with IE 5.5)
Instead an Error 500 pops up.

Reason: Wrong directory name referenced in jts.html
(jsp/jsptoservlet instead of jsp/jsptoserv)

Attatched is a patch.

Best regards,

Hans

 jts.html.diff

--- src/examples/jsp/jsptoserv/jts.html.origSun Mar 11 19:38:57 2001
+++ src/examples/jsp/jsptoserv/jts.html Sun Mar 11 19:28:57 2001
@@ -12,10 +12,10 @@
 
 
 
-Source Code 
for JSP calling servlet 
+Source Code 
+for JSP calling servlet 

 
-Source Code for 
Servlet calling JSP
+Source Code for 
+Servlet calling JSP
   
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

AW: AW: [PATCH REPOST] Tomcat 4.0 JSP Examples view Source

[Hans Schmid]

Hi Pierre,

see below:

> -Ursprüngliche Nachricht-
> Von: Pierre Delisle [mailto:[EMAIL PROTECTED]]
> Gesendet am: Samstag, 2. Dezember 2000 01:39
> An: [EMAIL PROTECTED]
> Betreff: Re: AW: [PATCH REPOST] Tomcat 4.0 JSP Examples view Source
>
>
>
> Hans Schmid wrote:
> >
> > Pierre,
> >
> > at least we both see that the numberguess example is different from the
> > others.
> > This actually was my starting point.
>
> Agree. I'll commit a patch for it soon.
>

Thanks, we are at least consistent now.

> >
> > I may be completely wrong, but I would expect to see the source
> listing of
> > the JSP examples
> > when I hit the View Source link. The only example it works that
> way is the
> > numberguess example.
> >
> > All other examples execute the JSP if I hit Source. I can also let the
> > example execute
> > when I hit 'Execute'.
>
> The 'Execute' link points to the jsp file itself (so the page is executed
> when the link is selected), while the 'source' link points to an
> html file,
> which itself displays a link that points to a .txt file
> containing the source code.
> (so the source code is displayed when the link is selected).
>
> For example, 'Date' has the following links:
>
> Execute -> http://localhost:8080/examples/jsp/dates/date.jsp
> Source  -> http://localhost:8080/examples/jsp/dates/date.html
>
> In date.html, we have the following:
>
> Source Code for Date Example ->
> http://localhost:8080/examples/jsp/dates/date.txt
>
> Is that what you have?


No, I see it exactly the other way around.
But see the Reply form Hans Bergsten. It really seems to be an IE issue.

Perhaps we should just document this behaviour.

Regards,
Hans

>
> -- Pierre
>
> >
> > So did I misunderstand the intent of this View Source thingy ?
> >
> > Please enlighten me.
> >
> > Best Regards,
> > Hans
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Pierre Delisle [mailto:[EMAIL PROTECTED]]
> > > Gesendet am: Donnerstag, 30. November 2000 19:34
> > > An: [EMAIL PROTECTED]
> > > Betreff: Re: [PATCH REPOST] Tomcat 4.0 JSP Examples view Source
> > >
> > > Hans,
> > >
> > > I just tried the examples on tomcat 4.0, and the only
> > > problem I could see is with the source code of
> > > the "number guess" example.
> > >
> > > The link in num/numguess.html should be changed from
> > >"/examples/jsp/source.jsp?/jsp/num/numguess.jsp"
> > >  to
> > >"numguess.txt"
> > >
> > > Otherwise, everything seems ok when I try the examples
> > > (both execute and source).
> > >
> > > -- Pierre
> > >
> > >
> > > Hans Schmid wrote:
> > > >
> > > > Hi there,
> > > >
> > > > I sent a patch to display the source code in the JSP examples
> > > and did not
> > > > get any feedback either. Probably because US folk was in turkey
> > > mode :) and
> > > > busy working on Tomcat 3.2 thereafter. Good work!!
> > > >
> > > > What it does:
> > > > JSP Examples in Tomcat 4.0 have a 'View Source' button. All but the
> > > > numberguess example do execute the JSP instead of displaying
> > > the source. My
> > > > patches do use source.jsp to display the sources instead of
> > > referencing the
> > > > *.txt files.
> > > >
> > > > The attatched zip file contains my current
> webapp\examples\jsp directory
> > > > tree without the noe unnecessary *.txt files.
> > > >
> > > > Most of the example code should be reusable in Tomcat 3.X
> > > >
> > > > Please let me know, if this is usefull or not
> > > >
> > > > I resend the patch as attatchment.
> > > >
> > > > Best regards,
> > > > Hans
> > > >
> > > > I had no luck putting this Bug into Bugrat:
> > > > Error: 500
> > > > Location: /BugRatReport/PostReport
> > > > Internal Servlet Error:
> > > >
> > > > java.lang.NoClassDefFoundError: javax/activation/DataSource
> > > > at
> > > org.gjt.bugrat.servlet.BugRatReport.processReportPOST(Compiled Code)
> > > > at org.gjt.bugrat.servlet.BugRatReport.doPost(Compiled Code)
> > > > at javax.servlet.http.Htt

AW: AW: [PATCH REPOST] Tomcat 4.0 JSP Examples view Source

[Hans Schmid]

Hi again,

please see comments below:

> -Ursprüngliche Nachricht-
> Von: Hans Bergsten [mailto:[EMAIL PROTECTED]]
> Gesendet am: Samstag, 2. Dezember 2000 02:27
> An: [EMAIL PROTECTED]
> Betreff: Re: AW: [PATCH REPOST] Tomcat 4.0 JSP Examples view Source
>
> Pierre Delisle wrote:
> > [...]
> > > All other examples execute the JSP if I hit Source. I can also let the
> > > example execute
> > > when I hit 'Execute'.
> >
> > The 'Execute' link points to the jsp file itself (so the page
> is executed
> > when the link is selected), while the 'source' link points to
> an html file,
> > which itself displays a link that points to a .txt file
> containing the source code.
> > (so the source code is displayed when the link is selected).
>
> I bet this problem only occurs with IE. It tries to be smarter
> than the server,


Ah! Yes, im using IE 5.5. I currently have no Netscape here to try.


> and totally ignores the Content-Type header. Instead it looks for HTML
> elements in the response body, and if it finds one it tries to render
> the response as HTML. Since the .txt file contains both HTML and JSP
> elements, the result is that IE shows a rendering of the HTML and hides
> all JSP elements :-(


That would make sense and explain the misunderstandings Piere and I seemed
to have.

Funny enough the behavior under IE seems to be exactly the oposit of what
Piere explained:
"/examples/jsp/source.jsp?/jsp/num/numguess.jsp"
displayes the source code as HTML listing and
"numguess.txt"
executes the JSP example.

At least we have now consistent behavior after Pieres patch to numberguess.

Should we mention this behaviour in the README.txt?
I bet many people use IE and wonder about this behaviour (like myself :)

>
> I have attached a hack I use to show the source for all example pages
> in my upcoming JSP book. Use it if you like. It takes the JSP source file
> and converts all HTML special characters into HTLM character
> entities. IE can
> then happily render it as HTML.
>
> To use it, just map it to a name (e.g. jspSource) and use a URI like
> /jspSource/.


I will give it a try.


> Note! Even though it does test the path for ".." and "WEB-INF", I can't
> guarantee that it handles all possible security threats. In other words,
> this servlet should *not* be installed on a production site.
>
> Hans
> --
> Hans Bergsten [EMAIL PROTECTED]
> Gefion Software   http://www.gefionsoftware.com

Thanks for clarification,

Best Regards,
Hans

Hans Schmid

AW: [PATCH REPOST] Tomcat 4.0 JSP Examples view Source

[Hans Schmid]

Pierre,

at least we both see that the numberguess example is different from the
others.
This actually was my starting point.

I may be completely wrong, but I would expect to see the source listing of
the JSP examples
when I hit the View Source link. The only example it works that way is the
numberguess example.

All other examples execute the JSP if I hit Source. I can also let the
example execute
when I hit 'Execute'.

So did I misunderstand the intent of this View Source thingy ?

Please enlighten me.

Best Regards,
Hans

> -Ursprüngliche Nachricht-
> Von: Pierre Delisle [mailto:[EMAIL PROTECTED]]
> Gesendet am: Donnerstag, 30. November 2000 19:34
> An: [EMAIL PROTECTED]
> Betreff: Re: [PATCH REPOST] Tomcat 4.0 JSP Examples view Source
>
> Hans,
>
> I just tried the examples on tomcat 4.0, and the only
> problem I could see is with the source code of
> the "number guess" example.
>
> The link in num/numguess.html should be changed from
>"/examples/jsp/source.jsp?/jsp/num/numguess.jsp"
>  to
>"numguess.txt"
>
> Otherwise, everything seems ok when I try the examples
> (both execute and source).
>
> -- Pierre
>
>
> Hans Schmid wrote:
> >
> > Hi there,
> >
> > I sent a patch to display the source code in the JSP examples
> and did not
> > get any feedback either. Probably because US folk was in turkey
> mode :) and
> > busy working on Tomcat 3.2 thereafter. Good work!!
> >
> > What it does:
> > JSP Examples in Tomcat 4.0 have a 'View Source' button. All but the
> > numberguess example do execute the JSP instead of displaying
> the source. My
> > patches do use source.jsp to display the sources instead of
> referencing the
> > *.txt files.
> >
> > The attatched zip file contains my current webapp\examples\jsp directory
> > tree without the noe unnecessary *.txt files.
> >
> > Most of the example code should be reusable in Tomcat 3.X
> >
> > Please let me know, if this is usefull or not
> >
> > I resend the patch as attatchment.
> >
> > Best regards,
> > Hans
> >
> > I had no luck putting this Bug into Bugrat:
> > Error: 500
> > Location: /BugRatReport/PostReport
> > Internal Servlet Error:
> >
> > java.lang.NoClassDefFoundError: javax/activation/DataSource
> > at
> org.gjt.bugrat.servlet.BugRatReport.processReportPOST(Compiled Code)
> > at org.gjt.bugrat.servlet.BugRatReport.doPost(Compiled Code)
> > at javax.servlet.http.HttpServlet.service(Compiled Code)
> > at javax.servlet.http.HttpServlet.service(Compiled Code)
> > at
> org.apache.tomcat.core.ServletWrapper.doService(Compiled Code)
> > at org.apache.tomcat.core.Handler.service(Compiled Code)
> > at org.apache.tomcat.core.ServletWrapper.service(Compiled Code)
> > at
> org.apache.tomcat.core.ContextManager.internalService(Compiled Code)
> > at org.apache.tomcat.core.ContextManager.service(Compiled Code)
> > at
> >
> org.apache.tomcat.service.connector.Ajp12ConnectionHandler.process
> Connection
> > (Compiled Code)
> > at
> org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code)
> > at
> org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code)
> > at java.lang.Thread.run(Compiled Code)
> >
> > Here the entry:
> >
> > JSP Examples in Tomcat 4.0 have a 'Source' button. All but the
> numberguess
> > example do execute the JSP instead of displaying the source. My
> patch uses
> > source.jsp to display the sources instead of referencing the
> *.txt files.
> >
> > I will repost a patch in the tomcat-dev list, which corrects
> this behavior
> > for Tomcat 4.0
> >
> > But the Tomcat 3.2 examples look pretty much the same.
> >
> > I am using Tomcat 4.0 and 3.2 in standalone mode
> >
> > http://localhost:8080 then press JSP Examples.
> > Click 'Sorce' on the Numberguess line, then 'Source Code for...'
> >
> > you get the source code displayed.
> >
> > For all other examples, the JSP page gets executed.
> >
> >
> --
> --
> > Name: patchfile.txt
> >patchfile.txtType: Plain Text (text/plain)
> > Encoding: quoted-printable
> >
> >   Name: jsp.zip
> >jsp.zipType: Zip Compressed Data (application/x-zip-compressed)
> >   Encoding: base64
>

[PATCH REPOST] Tomcat 4.0 JSP Examples view Source

[Hans Schmid]

Hi there,

I sent a patch to display the source code in the JSP examples and did not
get any feedback either. Probably because US folk was in turkey mode :) and
busy working on Tomcat 3.2 thereafter. Good work!!

What it does:
JSP Examples in Tomcat 4.0 have a 'View Source' button. All but the
numberguess example do execute the JSP instead of displaying the source. My
patches do use source.jsp to display the sources instead of referencing the
*.txt files.

The attatched zip file contains my current webapp\examples\jsp directory
tree without the noe unnecessary *.txt files.

Most of the example code should be reusable in Tomcat 3.X


Please let me know, if this is usefull or not

I resend the patch as attatchment.

Best regards,
Hans



I had no luck putting this Bug into Bugrat:
Error: 500
Location: /BugRatReport/PostReport
Internal Servlet Error:

java.lang.NoClassDefFoundError: javax/activation/DataSource
at org.gjt.bugrat.servlet.BugRatReport.processReportPOST(Compiled Code)
at org.gjt.bugrat.servlet.BugRatReport.doPost(Compiled Code)
at javax.servlet.http.HttpServlet.service(Compiled Code)
at javax.servlet.http.HttpServlet.service(Compiled Code)
at org.apache.tomcat.core.ServletWrapper.doService(Compiled Code)
at org.apache.tomcat.core.Handler.service(Compiled Code)
at org.apache.tomcat.core.ServletWrapper.service(Compiled Code)
at org.apache.tomcat.core.ContextManager.internalService(Compiled Code)
at org.apache.tomcat.core.ContextManager.service(Compiled Code)
at
org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection
(Compiled Code)
at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code)
at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code)
at java.lang.Thread.run(Compiled Code)


Here the entry:

JSP Examples in Tomcat 4.0 have a 'Source' button. All but the numberguess
example do execute the JSP instead of displaying the source. My patch uses
source.jsp to display the sources instead of referencing the *.txt files.

I will repost a patch in the tomcat-dev list, which corrects this behavior
for Tomcat 4.0

But the Tomcat 3.2 examples look pretty much the same.

I am using Tomcat 4.0 and 3.2 in standalone mode

http://localhost:8080 then press JSP Examples.
Click 'Sorce' on the Numberguess line, then 'Source Code for...'

you get the source code displayed.

For all other examples, the JSP page gets executed.



cvs diff -u (in directory 
D:\Develop\jakarta-cvs\jakarta-tomcat-4.0\webapps\examples\jsp)
cvs server: Diffing .
Index: index.html
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/index.html,v
retrieving revision 1.1
diff -u -r1.1 index.html
--- index.html  2000/08/17 00:58:03 1.1
+++ index.html  2000/11/23 14:55:51
@@ -6,7 +6,7 @@

JSP Examples
 
 
@@ -90,7 +90,7 @@
 
 Execute
 
-Source
+Source
 
 
 
cvs server: Diffing cal
cvs server: cannot find cal/cal1.txt
cvs server: cannot find cal/cal2.txt
Index: cal/calendar.html
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/cal/calendar.html,v
retrieving revision 1.1
diff -u -r1.1 calendar.html
--- cal/calendar.html   2000/08/17 00:58:04 1.1
+++ cal/calendar.html   2000/11/23 14:55:53
@@ -1,6 +1,6 @@
 
 
 
@@ -13,9 +13,9 @@
 
 
  Source Code for Calendar Example. 
-cal1.jsp
+cal1.jsp

-cal2.jsp
+cal2.jsp

 
 
cvs server: Diffing checkbox
cvs server: cannot find checkbox/checkresult.txt
Index: checkbox/cresult.html
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/checkbox/cresult.html,v
retrieving revision 1.1
diff -u -r1.1 cresult.html
--- checkbox/cresult.html   2000/08/17 00:58:07 1.1
+++ checkbox/cresult.html   2000/11/23 14:55:55
@@ -1,6 +1,6 @@
 
 
 
@@ -12,7 +12,7 @@
 
 
 
-Source Code for Checkbox Example
+Source Code for 
+Checkbox Example

 
 Property Sheet for CheckTest
cvs server: Diffing colors
Index: colors/clr.html
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/colors/clr.html,v
retrieving revision 1.1
diff -u -r1.1 clr.html
--- colors/clr.html 2000/08/17 00:58:09 1.1
+++ colors/clr.html 2000/11/23 14:55:58
@@ -1,6 +1,6 @@
 
 
 
@@ -12,7 +12,7 @@
 
 
 
-Source Code for Color Example
+Source Code for Color 
+Example

 
 Property Sheet for ColorGameBean
cvs server: cannot find colors/colors.txt
cvs server: Diffing dates
Index: dates/date.html
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/dates/date.html,v
retrieving revision 1.1
diff -u -r1.1 date.html
--- dates/date.html 2000/08/17 00:58:09 1.1
++

[PATCH] View Source in JSP Examples TC4

[Hans Schmid]

Hi everybody,

this is my first post to this group, even if I lurked for a while.
Now I think I can contribute a litte bit ;)

I noticed, that the JSP examples in TC4 (current CVS) do work, but the
source code is not shown propperly. At least, most of it (via Source /
Source Code for ...)

I reworked the examples a little bit to consistently use source.jsp and
therefor the examples-taglib. I did not change the logic, or added
additional links. Just changed the lines in the show Source HTML files from

Source Code for Date Example
   

to something like

Source Code for
Date Example
   

and changed a link in index.html form "colors/cresult.html" to
"checkbox/cresult.html" in the checkbox example.

As a side effect most of the *.txt files are not required anymore (e.g.
date.txt)


I attatch a zip file containing all files in the webapp\examples\jsp
directory and a patchfile, which I created in WinCVS using diff -u in the
jsp directory.

I hope this is in the right format, since I have never done this diff/path
thingy before.
[EMAIL PROTECTED]@jakarta.apache.orgtomcat-dev@jakarta
[EMAIL PROTECTED]

Feel free to incorporate this into TC4 and let me know, if it was useful.
Perhaps we can use something for TC3? (havent looked at those examples)


Best Regards, and keep up the excelent work,
Hans

---
Hans Schmid

 jsp.zip


cvs diff -u (in directory 
D:\Develop\jakarta-cvs\jakarta-tomcat-4.0\webapps\examples\jsp)
cvs server: Diffing .
Index: index.html
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/index.html,v
retrieving revision 1.1
diff -u -r1.1 index.html
--- index.html  2000/08/17 00:58:03 1.1
+++ index.html  2000/11/23 14:55:51
@@ -6,7 +6,7 @@

JSP Examples
 
 
@@ -90,7 +90,7 @@
 
 Execute
 
-Source
+Source
 
 
 
cvs server: Diffing cal
cvs server: cannot find cal/cal1.txt
cvs server: cannot find cal/cal2.txt
Index: cal/calendar.html
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/cal/calendar.html,v
retrieving revision 1.1
diff -u -r1.1 calendar.html
--- cal/calendar.html   2000/08/17 00:58:04 1.1
+++ cal/calendar.html   2000/11/23 14:55:53
@@ -1,6 +1,6 @@
 
 
 
@@ -13,9 +13,9 @@
 
 
  Source Code for Calendar Example. 
-cal1.jsp
+cal1.jsp

-cal2.jsp
+cal2.jsp

 
 
cvs server: Diffing checkbox
cvs server: cannot find checkbox/checkresult.txt
Index: checkbox/cresult.html
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/checkbox/cresult.html,v
retrieving revision 1.1
diff -u -r1.1 cresult.html
--- checkbox/cresult.html   2000/08/17 00:58:07 1.1
+++ checkbox/cresult.html   2000/11/23 14:55:55
@@ -1,6 +1,6 @@
 
 
 
@@ -12,7 +12,7 @@
 
 
 
-Source Code for Checkbox Example
+Source Code for 
+Checkbox Example

 
 Property Sheet for CheckTest
cvs server: Diffing colors
Index: colors/clr.html
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/colors/clr.html,v
retrieving revision 1.1
diff -u -r1.1 clr.html
--- colors/clr.html 2000/08/17 00:58:09 1.1
+++ colors/clr.html 2000/11/23 14:55:58
@@ -1,6 +1,6 @@
 
 
 
@@ -12,7 +12,7 @@
 
 
 
-Source Code for Color Example
+Source Code for Color 
+Example

 
 Property Sheet for ColorGameBean
cvs server: cannot find colors/colors.txt
cvs server: Diffing dates
Index: dates/date.html
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/dates/date.html,v
retrieving revision 1.1
diff -u -r1.1 date.html
--- dates/date.html 2000/08/17 00:58:09 1.1
+++ dates/date.html 2000/11/23 14:55:59
@@ -1,6 +1,6 @@
 
 
 
@@ -12,7 +12,7 @@
 
 
 
-Source Code for Date Example
+Source Code for Date 
+Example

 
 
cvs server: cannot find dates/date.txt
cvs server: Diffing error
Index: error/er.html
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/error/er.html,v
retrieving revision 1.1
diff -u -r1.1 er.html
--- error/er.html   2000/08/17 00:58:10 1.1
+++ error/er.html   2000/11/23 14:56:02
@@ -1,6 +1,6 @@
 
 
 
@@ -12,7 +12,7 @@
 
 
 
-Source Code for Error Example
+Source Code for Error 
+Example

 
 
cvs server: cannot find error/err.txt
cvs server: Diffing forward
cvs server: cannot find forward/forward.txt
Index: forward/fwd.html
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/forward/fwd.html,v
retrieving revision 1.1
diff -u -r1.1 fwd.html
--- forward/fwd.html2000/10/16 21:33:11 1.1
+++ forward/fwd.html2000/11/23 14:56:04
@@ -1,6 +1,6 @@
 
 
 
@@ -11,7 +11,7 @@
 
 
 
-Sou