Re: Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.

[Rainer Jung]

Please witch over to tomcat-user for discussion. This is not really a 
developer issue.


=== My previous comments (bugzilla) ===
First hints from my side: reduce to equal number of apache and tomcat 
instances, configure F5 with rule that sends URLs with session cookie or 
jsessionid in URL to the "correct" apache. Furthermore configure mod_jk, 
such that each apache sends requests without sessions to it's preferred 
tomcat partner.


That way almost all apache processes will connect to only one tomcat.

If you still need 16K apache processes per instance you are in trouble 
(maybe upgrade to apache 2), if you manage to handle the workload with 
1K apache processes, 1K Threads in Tomcat should be OK.


=== Additional comments ===
If you don't want to reuse the connections between apache and tomcat 
(last ressort solution) switch over to connectors of type ajp12 (they 
will close the connection after each request-response cycle) or set 
cachesize to 0 which will use ajp13 protocol, but I think it will close 
connections after each request too.


I hope you don't use HTTP keep alive?

Also: I vaguely remember there was an experimental connector/thread pool 
implementation with asynchroneous features. It might be, that this 
implementation does not need one fixed thread for each apache connection 
and I think it is beeing shipped with 5.5.x, but not enabled on default.


Concerning this topic tomcat-dev might be the right place to ask.

Rainer

Remy Gendron wrote:


Hi all,

Here's the situation as it stands today and what can be done to solve
it. I'll try to keep this short.

Running configuration:

*   Running on Linux Red-Hat Ent 3
*   1 X F5 load balancer and hardware SSL box.
*   5 X Apache 1.3.33/mod_jk 1.2.14
*	6 X JBoss 4.0.0/Tomcat 5.0.28 using the AJP13 connector. 
*	Oracle 9i



Our production environment hosts a number of applications, each with
different load and usage patterns. Our problem comes from the fact that
it is difficult to find a web farm configuration that will satisfy every
application. For reasons I will not explain here, we cannot have a
dedicated web farm for each application.

This is what we think is happening in our production environment based
on tests ran in UAT (User Acceptance Tests) and literature from the
Apache and Tomcat products. This is all pretty new to us so if someone
can provide hard facts, you are more than welcome.

1.  The 1.3 generation of Apache web servers will spawn a child
process to handle an HTTP request. Only one HTTP request at a time can
be processed by that child. 
2.	As the load increases on the web server, additional child

processes will be spawned to concurrently serve the requests. There is a
default limit to how many child processes can be forked. That limit
defaults to 256 but has been changed in production to 16384. This is the
MaxClients directive. It seems that production really needs the 16384
value instead of the 256 default. With 256, our web servers were
rejecting connections and could not support the load generated by all of
our clients.
3.  To prevent latency, Apache will maintain a maximum of 100 spare
child processes alive. Spare means that they are not serving requests.
Once reached, that number of spare servers does not seem to decrease.
This is the number we see in our tests in UAT where 201 threads remain
active in Tomcat. This is the 100 spare children connections * 2 web
server plus accept() thread. 
4.	If a request needs to be forwarded to Tomcat/JBoss (dynamic

pages), the child process mod_jk module will instantiate a socket
connection to the ajp13 connector in Tomcat. 
5.	Tomcat will accept the connection and create a thread to serve

it. Connections will be accepted up to a concurrent maximum of 1200.
This upper value has been set by us. 
6.	Tomcat will reject connections when the maximum is reached.

JBoss 4.0.0 has a known issue where the server will die when the maximum
is reached. This has been fixed in 4.0.2. 
7.	A connection could potentially be recycled in mod_jk

(recycle_timeout) if no activity occurs thru the connection. However,
any requests to Tomcat from any user session-bound to that Tomcat
instance could go thru the connection, thus keeping it active. Recycling
does not seem to occur. We use a recycle_timeout value of 300.
8.  The fact that the production web servers can potentially serve
up to 16384 concurrent requests make it possible for a web server to
instantiate an almost infinite number of connections to Tomcat and nuke
it. 
9.	Tomcat can then become overloaded with connections. If a valid

HTTP request comes thru Apache and is routed to a child process that has
not yet made a connection to Tomcat, the connection could be impossible
if Tomcat has already accepted its 1200 limit. 
10.	In that case, mod_jk could potentially fail over to another

Tomcat. The user would however loose his session.
11. The recycle_timeout and  cache_size options are of no use to us
because too 

Re: JK 1.2.15 Release plan?

[Rainer Jung]

I encourage you for voting 1.2.15 as stable.

Mladen Turk wrote:

> Anyhow, I would like that we vote this (1.2.15) version as stable,
> because it's a bug-fix release over the 1.2.14 stable.


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

Re: Releasing JK 1.2.15

[Rainer Jung]

Hi Peter, Mladen and all others,

I would like to follow Mladens suggestion from earlier this month to
create a list of precise use cases for the load balancing, failover and
administrative downtime scenarios. I think from that we might end up by a
better understandable overal lb design. I expect, that we will find the
need for bigger changes to lb. Maybe after we know what we need to do, we
can decide if we start 1.3, or if the changes with respect to
functionality are still small enough to call them 1.2.16.

I unfortunately didn't go deeply into Peter's bug report, because I wanted
to go into it when writing up use cases. So I'm not sure, if the proposed
changes are a "bug fix" (then it's OK for last minute 1.2.15) or maybe
should better be decided together with a complete view of lb use cases
(then 1.3 or 1.2.16).

Rainer

> Hey Mladen,
>
> can we also integrate the better domain loadbalancer support at
> jk_lb_worker.c?
> I think that we don't change the lb_value inside sticky mode at every
> request.
> Can we comment out or remove lines L413-431?
>
> Thanks,
> Peter
>
> Mladen Turk schrieb:
>
>>> There has been couple of major bug fixes
>>> against 1.2.14, see:
>>> http://jakarta.apache.org/tomcat/connectors-doc/changelog.html
>>>
>>> They have been fixed in the CVS, and since
>>> couple of them actually makes 1.2.14 unusable on
>>> some platforms like Solaris 2.8 and Irix we need a release.
>>>
>>> I plan to tag the 1.2.15 by the end of this week, and pursue
>>> for a vote next week for this bug-fixing release.
>>>
>>> Any objections?
>>>
>>
>> Since there were no objections I plan to tag the 1.2.15 later this
>> evening at 19:00 GMT.
>>
>> This will eventually be the last release from CVS, cause IIUC the
>> transition will be made this weekend.
>>
>>
>> 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]
>



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

Re: Releasing JK 1.2.15

[Rainer Jung]

Both users tried with CVS head and the patch works for IRIX and Solaris.
No objections to releasing.

> Hi,
>
> There has been couple of major bug fixes
> against 1.2.14, see:
> http://jakarta.apache.org/tomcat/connectors-doc/changelog.html
>
> They have been fixed in the CVS, and since
> couple of them actually makes 1.2.14 unusable on
> some platforms like Solaris 2.8 and Irix we need a release.
>
> I plan to tag the 1.2.15 by the end of this week, and pursue
> for a vote next week for this bug-fixing release.
>
> Any objections?
>
> 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]

Re: Releasing JK 1.2.15

[Rainer Jung]

Hi,

I think the changes are important enough for a release.

I explicitely CC the two users who experienced the core dump (bugzilla 
36525) and I hope they can also check validity of the fix. We have built 
CVS HEAD without problems, but since we usually don't built with 
optimization turned on I would very much like some feedback from at 
least one of the two users.


1.2.15 might be the first stable release after all the big changes in 
lb, status worker, shared memory etc.


Regards,

Rainer

Mladen Turk wrote:


Hi,

There has been couple of major bug fixes
against 1.2.14, see:
http://jakarta.apache.org/tomcat/connectors-doc/changelog.html

They have been fixed in the CVS, and since
couple of them actually makes 1.2.14 unusable on
some platforms like Solaris 2.8 and Irix we need a release.

I plan to tag the 1.2.15 by the end of this week, and pursue
for a vote next week for this bug-fixing release.

Any objections?

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]

Questions about MemoryUserDatabase

[Rainer Jung]

Hi,

for the patch 36020 I had a look at MemoryUserDatabase and although the 
patch is already committed (Thanks!) I wanted to discuss a few things:


1) The close() for the MemoryUserDatabase is never called,
especially not during shutdown of tomcat. Anyone with a good hint, where 
to look for adding a hook to close MemoryUserDatabase during tomcat 
shutdown? Where should I look for supplying a nice integration into the 
LifeCycle?


The creation comes from

org.apache.catalina.users.MemoryUserDatabaseFactory.getObjectInstance(MemoryUserDatabaseFactory.java:113)
org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:129)
javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
org.apache.naming.NamingContext.lookup(NamingContext.java:792)
org.apache.naming.NamingContext.lookup(NamingContext.java:152)
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:138)
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:108)
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:80)
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
org.apache.catalina.core.StandardServer.start(StandardServer.java:673)

2) The new warn message is only contained in the english 
LocalString.properties. Anyone who could do es/fr/ja ?


Original message:

"User database is not persistable - no write permissions on directory"

3) I think, at the moment there is no documentation for UserDatabase at 
all. I only find docs about MemoryRealm. Where would there be a good 
place/page to contribute something? I would like to add information 
about the new property "readonly"?


Thanks for any advice.

Regards,

Rainer

[EMAIL PROTECTED] wrote:


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36020


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-08-04 15:14 ---
I applied the patch, but I changed "persistable" -> "writeable". Thanks.



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

Re: Writing MemoryUserDatabase on Startup

[Rainer Jung]

Hi Remy,

so would it be OK, if I produce a patch, that cares about the Exception 
and logs a message instead? I could make that configurable if you think 
there is too much danger for a user to loose changes because he was able 
to start tomcat and didn't notice the database was not writable.


I will propose a patch later that week and you can have a look at it.

By the way: I think Mladen also wanted such a behaviour and just now 
there is a user on the users list who ran into trouble because of the 
needed write permissions (not easy to understand/believe, that the file 
is needed to be written during startup).


Rainer

Remy Maucherat wrote:


Rainer Jung wrote:


Hi,

I wonder, why

/org/apache/catalina/users/MemoryUserDatabaseFactory.java

saves the MemoryUserDatabase directly after opening it:

public Object getObjectInstance(Object obj, Name name, Context
nameCtx, Hashtable environment) throws Exception {

...

// Return the configured database instance
database.open();
database.save();
return (database);

}

That means, the runtime user of tomcat needs write permissions on the
directory, the file is in (see the implementation of
MemoryUserDatabase.save()).

Ogf course in case one likes to administer the user database the save
function is necessary. But there are two cases where one would prefer to
have tomcat not trying to save the database during startup:

1) Running tomcat from CD
2) Having a very secure setup of tomcat, where all the configs are write
disabled.

The call to database.save() is in the code since the very first version
in TC 4, but I can't really see, why it is necessary.

Another possibility would be to catch the Exception thrown when there is
no write permission and to simply log a warning.

Also: there is a save() done in close(). I don't know, where the close
is called from, but it looks like nowhere in catalina code (eventually
in admin).

Any comments? Thanks!



The problem is (mostly) the save in close: the database can't know for 
sure if its stuff was updated so it always saves.


I understand the need for 1), which can be achieved with the other 
equivalent-but-not-management-friendly memory realm. 2) seems unlikely IMO.


Rémy

-
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]

Writing MemoryUserDatabase on Startup

[Rainer Jung]

Hi,

I wonder, why

/org/apache/catalina/users/MemoryUserDatabaseFactory.java

saves the MemoryUserDatabase directly after opening it:

public Object getObjectInstance(Object obj, Name name, Context
nameCtx, Hashtable environment) throws Exception {

...

// Return the configured database instance
database.open();
database.save();
return (database);

}

That means, the runtime user of tomcat needs write permissions on the
directory, the file is in (see the implementation of
MemoryUserDatabase.save()).

Ogf course in case one likes to administer the user database the save
function is necessary. But there are two cases where one would prefer to
have tomcat not trying to save the database during startup:

1) Running tomcat from CD
2) Having a very secure setup of tomcat, where all the configs are write
disabled.

The call to database.save() is in the code since the very first version
in TC 4, but I can't really see, why it is necessary.

Another possibility would be to catch the Exception thrown when there is
no write permission and to simply log a warning.

Also: there is a save() done in close(). I don't know, where the close
is called from, but it looks like nowhere in catalina code (eventually
in admin).

Any comments? Thanks!

Rainer




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

Wrong index.html on Tomcat Documentation Website

[Rainer Jung]

The page

http://jakarta.apache.org/tomcat/tomcat-5.5-doc/index.html

is missing position "23) APR" in the listed User Guide menu. Any subpage
includes number 23 on it's own submenu. It is also included in the 5.5.10
download, only missing on the internet top level doc page.

Please add

23) APR

after

22) Logging



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

Unclear 5.0 release status

[Rainer Jung]

Hi,

the release status of TC 5.0 is a little unclear:

http://jakarta.apache.org/tomcat/tomcat-5.0-doc/status.html

states:

Tomcat 5.0.29 was released on October 6th, 2004. Work on the 5.0 branch is
primarily for maintenance and bug fixes. It is still considered the best
branch for production use, but Tomcat 5.5 is rapidly nearing a stable
release.

I remember, that 5.0.29 was not finally released, instead 5.0.30-beta was
put on the server 6 months ago and never changed from beta to final, so

http://jakarta.apache.org/site/downloads/downloads_tomcat-5.cgi

still only shows 5.0.30-beta and the last non-beta version is 5.0.28.

Any reasons to not formally change 5.0.30 from beta to final (apart from
everyone is using his/her time for 5.5.x)?

Rainer



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

Re: Tagging JK 1.2.9 on 3/17/2005

[Rainer Jung]

Hi,

socket_timeout on Solaris: does very well during connect.
Also no more erors/warning during build.

I tested by adding microsecond timestamps to jk_log, adding some trace log
messages to nb_connect and changing socket_timeout in nb_connect to
millisecond resolution.

Then I stressed to tomcat system and could see that:

- the connect call comes back immediately (non blocking) with EINPROGRESS
- the select call comes back immediately after connect or very close to
the timeout given.
- if I put the timeout very small (e.g. 5 milliseconds) connect fails and
indeed a packet sniff shows, that the handshake was not fast enough.
- with 15 milliseconds one of the three attempts succeed (motly the second
one)
- with a higher timeout the first attempt succeeds and the timestamp of
the return of the select call nicely fits with the end of the three way
tcp handshake (syn/sysn_ack/ack) from the packet sniff.
- without any stress on the target system the connect alredy comes back
with rc/errno=0 (success) and no select is done.

Regards,

Rainer

> Rainer Jung wrote:
>> I could help with Solaris info. If you tell me, what you are interested
>> in, I can do some tests.
>>
> Build, socket_timeout and JkShmFile.
>
> Regards,
> Mladen.



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

Re: Tagging JK 1.2.9 on 3/17/2005

[Rainer Jung]

>> 2) The test in configure about functionality of the timeouts is broken.
>> The test program does not compile under Solaris, because it needs
>> "-lsocket".
>
> Can you provide a patch for that?

How about:

*** configure.in.orig   Thu Mar 17 17:00:36 2005
--- configure.inThu Mar 17 21:28:29 2005
***
*** 56,63 
  dnl check for flock function.
  AC_CHECK_FUNC(flock, AC_DEFINE(HAVE_FLOCK,1,[Have flock()]))

! AC_DEFUN(JK_CHECK_SETSOCKOPT, [
  AC_MSG_CHECKING(whether to use $1 with setsockopt())
  AC_TRY_RUN([
  #include 
  #include 
--- 56,65 
  dnl check for flock function.
  AC_CHECK_FUNC(flock, AC_DEFINE(HAVE_FLOCK,1,[Have flock()]))

! AC_DEFUN([JK_CHECK_SETSOCKOPT], [
  AC_MSG_CHECKING(whether to use $1 with setsockopt())
+ saved_LIBS="$LIBS"
+ LIBS="$saved_LIBS -lsocket"
  AC_TRY_RUN([
  #include 
  #include 
***
*** 88,93 
--- 90,96 
  , [ AC_MSG_RESULT([yes]) AC_DEFINE(USE_$1, 1, [Define to use $1 with
setsockopt()]) ]
  , [ AC_MSG_RESULT([no]) ]
  )
+ LIBS="$saved_LIBS"
  ])dnl

  dnl check for SO_RCVTIMEO and SO_SNDTIMEO

Since it's only changed line and three added I did not use local CVS to
make diff -u and I hope this context diff suffices.

That way the test runs smoothly, of course with the same negative but
clean result:

configure:19433: checking whether to use SO_RCVTIMEO with setsockopt()
configure:19480: gcc -specs=/usr/local/apautobuild/specs -o conftest -O2  
conftest.c  -lsocket >&5
configure:19483: $? = 0
configure:19485: ./conftest
configure:19488: $? = 1
configure: program exited with status 1

Regards,
Rainer




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

Re: Tagging JK 1.2.9 on 3/17/2005

[Rainer Jung]

Concerning socket_timeout:

1) In common/jk_connect.c there is a typo:

   374  setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
   375 (const void *) &tv, sizeof(tv));
   376  setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
   377 (const void *) &tv, sizeof(tv));

so both setsockopts use the same option. It should be SO_SNDTIMEO in line
376. Maybe that's easy enough to change for 1.2.9.

2) The test in configure about functionality of the timeouts is broken.
The test program does not compile under Solaris, because it needs
"-lsocket".

Undefined   first referenced
 symbol in file
socket  /var/tmp//ccKuhLE0.o
setsockopt  /var/tmp//ccKuhLE0.o
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status
configure:19481: $? = 1
configure: program exited with status 1

When I compile the test program with "-lsocket" it compiles but it exits
as expected with "1". So under Solaris the two timeouts are defined in the
include files, but they do not work with setsockopt. Since this doesn't
change the result in the end, it might also be corrected after 1.2.9.

3) in common/jk_connect.c in method jk_is_socket_connected the second
argument "timeout" is never used.

4) Still need to test functionality of socket_timeout under Solaris.

Regards,
Rainer

> Rainer Jung wrote:
>> Hi,
>>
>> I could help with Solaris info. If you tell me, what you are interested
>> in, I can do some tests.
>>
>
> Build, socket_timeout and JkShmFile.
>
> 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]

Re: Tagging JK 1.2.9 on 3/17/2005

[Rainer Jung]

Hi Mladen,
- Build for apache 1.3 OK (but see detailed comments).
- Running with apache 1.3 and JkShmFile: Looks OK
- jkstatus: Looks OK
- socket_timeout: Still needs to be tested (will try later)
- Logging shows mod_jk initialization two times! Once for a process A,
which does no longer exist after apache startup has finished, and a
second time the same lines for the usual parent process B. System call
trace shows, that A forks B and exits during startup. In my case, apache 
is not run from the root account.

Anything else (apart from socket_timeout) I should test (test cases?)
Details:
Code from CVS HEAD today 17:00 CET.
Environment Solaris 8 UltraSparc, autoconf 2.59, automake 1.9, libtool
1.5, GNU m4 1.4.2, GNU make 3.80, gcc 3.2, Solaris ld 1.279.
CFLAGS set to "-O2", CC set to "gcc -specs=MY_SPECS_PATH/specs" and the
specs file differs from the standard one by:
51c51
< %{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc
-lgcc_eh}%{shared-libgcc:-lgcc_s%M -lgcc}}%{shared:-lgcc_s%M}}}
---
 > %{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc
-lgcc_eh}%{shared-libgcc:-lgcc_s%M -lgcc}}}
This is to link statically against libgcc. Otherwise the runtime system
must have libgcc_s.so, which usually is not the case for Solaris systems.
buildconf.sh warns:
configure.in:59: warning: underquoted definition of JK_CHECK_SETSOCKOPT
   run info '(automake)Extending aclocal'
   or see
http://sources.redhat.com/automake/automake.html#Extending%20aclocal
configure.in: installing `scripts/build/unix/install-sh'
configure.in: installing `scripts/build/unix/missing'
The underquoted warning means, that future versions of automake might
require line 59 to include additional brackets:
AC_DEFUN([JK_CHECK_SETSOCKOPT], [
./configure --with-apxs=MY_APXS_PATH/apxs
Nothing special.
make: Warning:
libtool: install: warning: remember to run `libtool --finish SOME_PATH'
libtool: install: warning: remember to run `libtool --finish SOME_PATH'
but inspection of libtools show, that --finish would not do anything in
our case.
Copied apache-1.3/mod_jk.so.0.0.0 to libexec/mod_jk.so.
Configured apache:
LoadModule jk_module  libexec/mod_jk.so
AddModule mod_jk.c
JkWorkersFile /SOME_PATH/conf/workers.properties
JkShmFile /SOME_PATH/logs/mod_jk.shm
JkLogFile /SOME_PATH/logs/mod_jk.log
JkLogLevel trace
...
# Inside virtual host
# Where to put jk logs
JkLogFile /SOME_PATH/logs/mod_jk_21000.log
JkLogLevel trace
JkMount /status status
JkMount /*.jsp balancer
Test:
lynx -cfg=/home/jung/lib/lynx.cfg http://localhost:21000/status
shows version 1.2.9 and detail info for load balancing worker and single
worker.
Regards,
Rainer
Mladen Turk wrote:
Rainer Jung wrote:
Hi,
I could help with Solaris info. If you tell me, what you are 
interested in, I can do some tests.

Build, socket_timeout and JkShmFile.
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]

Re: Tagging JK 1.2.9 on 3/17/2005

[Rainer Jung]

Hi,
I could help with Solaris info. If you tell me, what you are interested 
in, I can do some tests.

Regards,
Rainer
Mladen Turk wrote:
Mark Thomas wrote:
I suspect that most of them are invalid/already fixed bug would be 
grateful if you could take a look.

Hi,
Yes, most are fixed. Other I simply do not understand.
I'll clean up fixed and invalid, and instruct the reporters
to check beta version. Some problem like Solaris one are
really hard to track down without a box :)
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]

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

[Rainer Jung]

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.
OK, understood from below. I agree concerning JNI deprecation. But read 
comments about local_worker.

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.
You are totally right about the bad documentation (at least concerning 
the status before you gave it a refresh). But I have the feeling that 
more people where using it like me, by studying the code (at least it's 
open source) and learning the functionality from there. So local_worker 
is a feature, that I assume is being useful and used.

So locality is not deprecated. Quite opposite, now it works, just
the local_worker_only is changed to sticky_session_force.
IMHO this is more clearer and descriptive directive then previous one.
My understanding of the use case: the term local_worker historically 
most likely comes from the idea, that if you use multiple systems each 
with apache and tomcat on them, then a call from an apache to the tomcat 
on the same system would be faster then going to a remote tomcat. 
local_worker should have indicated to prefer this (until 1.2.6 only one 
worker would work as a local_worker) worker unless a request carries a 
session id and stickyness is on or the local_worker is in error state. A 
more general better term would have been preferred_worker or just 
preferred and that's the way it is used today. At the moment there seems 
to be no more possibility to map a preference (I don't mean load 
balancing weights).

Still I know cases, where it makes sense to have a distinction for 
requests without session id/stickyness between:

- preferred (one or more)
- failover for the preferred (your redirect)
- maybe allowed (although the first two cases should be enough not to 
need more)
- the rest

"The" rest is there, because some worker may only be used, in case 
stickyness comes in.

With stickyness and session id one would have:
- sticky worker (the correct one)
- failover for the preferred (your redirect)
- any other in the same replication cluster (domain)
- the rest (loose session but can start the app again from the beginning)
Your redirect concept and my older domain patch share some use cases.
On the other hand local_worker_only only makes a difference if you 
configure local and non-local workers in a load balancer and all local 
workers go into error state. With local_worker_only, all further 
requests will fail. Without local_worker_only the non-local workers will 
be used. I always had the impression that only very few - if any - 
people will need this kind of feature.

You indicated i a separate answer, that one could use the disabled 
attribute instead. But I assume there is no failover to a disabled 
worker, whereas there should be to a non-preferred worker.

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

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

[Rainer Jung]

Hi,
first: thanks a lot to Mladen for adding all the beautiful features [and 
removing CRLF :) ]. Big leap forward!

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.

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:

Do we need to reflect the incompatible changes by shifting to 1.3? By 
this I mean: will we still need to maintain bugs in the parallel 1.2 tree?

Stated differently:
Which features can be dropped without further maintenance for older 
releases?

Usually one would deprecate by first announcing deprecation but still 
supporting for some time to allow migration. Then after e.g. 6 months 
one could drop the functionality totally.

People have just been told few months ago, that mod_jk2 is no longer 
supported and that they should move to mod_jk. Mladen helps them by 
reimplementing valuable mod_jk2 features inside mod_jk, but we should 
not kick out long-time mod_jk users by dropping features without having 
a visible discussion on that item.

Regards,
Rainer
Mladen Turk wrote:
Henri Gomez wrote:
Good works Mladen.
I found jk a bit faster and it's good to see that we could speed it up 
a little.

The next step could be to use larger AJP packets (4k too small)
Sure ;).
For 100K file the speed is the same, as expected.
On large files we are measuring the network throughput
not the speed of the jk itself.
Anyhow what is more important then speed is the fact
that endpoint cache is working as expected on threaded
servers.
BTW, what do you think of deprecating the JNI connector.
Since it can be (theoretically) used only on windows and netware,
I wonder if it make sense to continue the support.
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]

Re: [VOTE] Proposed API change to the Manager interface

[Rainer Jung]

I have the impression you fixed the jvmRoute in the new Session(-Id) in
ManagerBase, but not in DeltaManager? Even when the context is
distributable one might prefer to stick the session to the node where it
now originates.

Furthermore: I did not really understand the use case of emptySessionPath,
but want to indicate 2 problematic areas:

1) If the cookie contains an expired session(-id) then you would allow a
new session to be started with the old id. That is not a naive security
problem, because the session is empty, so authentication has to be done
again etc.

But there is a more complex threat: Security of webapps relies on the
fact, that session ids are not easily guessable. Once you move into a
situation where a user might use the same session id for a very long time
(in fact different sessions) the id will loose it's security. Normally
it's hard to find out the id of a user session while the session is still
active. And the user can at every time end his session. If he is going to
use the same Id for many sessions you have a much better chance to get
knowledge about the id between sessions and then to just wait for a new
session to begin.

2) There might be problems by putting an arbitrary string coming from an
uncontrolled Cookie and using it as a session id inside tomcat. I don't
know, if there is a way related to cross site scrpting or injection of
malicious code for cookies (of course I know, that there is no scripting
inside Cookies, but atackers are very ingenious nowadays). At least one
should check the string for formal correctness (e.g. containing only
letters and numbers or something similar).



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

Re: [VOTE] Proposed API change to the Manager interface

[Rainer Jung]

Upgrading mod_jk would be possible (not too complicated), but I'm afraid
we are going to break other products we don't control the way we do with
mod_jk.
mod_jk is a good example to see, why it's not unlikely that changes
would be needed for other balancers.
Rainer
Remy Maucherat wrote:
Filip Hanik - Dev wrote:
its not at all that complicated.
This is how a big5 load balancer does it.
A) it sets a cookie, and based on the cookie it load balances.
B) if a cookie is not supported, it does a calculation based on the IP 
address, and stays sticky that way.

No need to exchange any info in this scenario and very straight 
forward, and never goes wrong. The only time it goes wrong is for
AOL users who can change gateway between HTTP and HTTPS

I don't think it's that complicated either, but it would still require 
an upgrade of mod_jk to work, so it's probably not an option :(

Rémy
-
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]

Re: [VOTE] Proposed API change to the Manager interface

[Rainer Jung]

I don't fully agree: we use F5 too, but:
1) I know many commercial sites (in germany), which do not use Cookies 
(privacy reasons).

2) IP based stickyness does not work very well. In many scenarios you 
will only be able to correctly route "most" of your clients. If you rely 
on exact routing, IP-based will not suffice.

3) These are the reasons why I assume, that all balancers will support 
routing decisions based on the jsessionid in the URI. So they already 
have to support extracting routing information from the session id string.

So using the same jessionid string in the standard cookie will work in 
most (all ?) situations / for most products.

Example: mod_jk does it like that:
/* Retrieve session id from the cookie or the parameter 
 */
static char *get_sessionid(jk_ws_service_t *s)
{
char *val;
val = get_path_param(s, JK_PATH_SESSION_IDENTIFIER);
if (!val) {
val = get_cookie(s, JK_SESSION_IDENTIFIER);
}
return val;
}

and after that it does no longer matter, where the info comes from.
On the other hand: what's wrong about embedding the jmvRoute as a suffix 
in the session id?

Rainer
Filip Hanik - Dev wrote:
its not at all that complicated.
This is how a big5 load balancer does it.
A) it sets a cookie, and based on the cookie it load balances.
B) if a cookie is not supported, it does a calculation based on the IP address, 
and stays sticky that way.
No need to exchange any info in this scenario and very straight forward, and 
never goes wrong. The only time it goes wrong is for
AOL users who can change gateway between HTTP and HTTPS
Filip
- Original Message -
From: "Rainer Jung" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Tuesday, February 08, 2005 10:39 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
I'm afraid that change will have negative implications: The jvmRoute is
used to enable routing decisions by balancing components. All these
components usually support routing either COOKIE-based or URI-based.
In the URI-based case it is more or less the only clean way to include
the jvmRoute in the jsessionid, since the jsessionid is standardized, so
all common balancing products know how to handle it.
But then it is pretty common to assume the jsessionid and the cookie to
have the same value. They are sort of two different ways to transport
the same session information. So most balancer providers implement the
routing decision features the same way, independant of the source of the
session string.
Splitting the jvmRoute from the session id in the cookie case will most
likely make the situation for all implementers of balancers more complex
and instable (e.g.: mod_jk).
Of course we would all profit, if some JSR would standardize the way,
distributed applications exchange routing information with the
clients/balancers. As long as that's not the case it is very likely,
that jvmRoute as a suffix of the session id has much better support from
balancer providers.
Rainer
Filip Hanik - Dev wrote:

Remy Wrote:

BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?

That would have been the obvious solution, the jvmRoute must have come from a 
dark basement somewhere :)
Whatever the change you decide on, I'll be happy to implement it and test it 
for the cluster stuff
Filip
- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Monday, February 07, 2005 11:34 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface


@@ -744,15 +747,17 @@
   session.setValid(true);
   session.setCreationTime(System.currentTimeMillis());
   session.setMaxInactiveInterval(this.maxInactiveInterval);
-String sessionId = generateSessionId();
+if (sessionId == null) {
+sessionId = generateSessionId();
+}

I just noticed my patch needs something for jvmRoute handling
(basically, the session id which is recieved must be edited for the
right route). I'll fix that.
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
Rémy
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-

Re: [VOTE] Proposed API change to the Manager interface

[Rainer Jung]

I'm afraid that change will have negative implications: The jvmRoute is 
used to enable routing decisions by balancing components. All these 
components usually support routing either COOKIE-based or URI-based.

In the URI-based case it is more or less the only clean way to include 
the jvmRoute in the jsessionid, since the jsessionid is standardized, so 
all common balancing products know how to handle it.

But then it is pretty common to assume the jsessionid and the cookie to 
have the same value. They are sort of two different ways to transport 
the same session information. So most balancer providers implement the 
routing decision features the same way, independant of the source of the 
session string.

Splitting the jvmRoute from the session id in the cookie case will most 
likely make the situation for all implementers of balancers more complex 
and instable (e.g.: mod_jk).

Of course we would all profit, if some JSR would standardize the way, 
distributed applications exchange routing information with the 
clients/balancers. As long as that's not the case it is very likely, 
that jvmRoute as a suffix of the session id has much better support from 
balancer providers.

Rainer
Filip Hanik - Dev wrote:
Remy Wrote:
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?

That would have been the obvious solution, the jvmRoute must have come from a 
dark basement somewhere :)
Whatever the change you decide on, I'll be happy to implement it and test it 
for the cluster stuff
Filip
- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Monday, February 07, 2005 11:34 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface

@@ -744,15 +747,17 @@
session.setValid(true);
session.setCreationTime(System.currentTimeMillis());
session.setMaxInactiveInterval(this.maxInactiveInterval);
-String sessionId = generateSessionId();
+if (sessionId == null) {
+sessionId = generateSessionId();
+}

I just noticed my patch needs something for jvmRoute handling
(basically, the session id which is recieved must be edited for the
right route). I'll fix that.
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
Rémy
-
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]

Re: [VOTE] Proposed API change to the Manager interface

[Rainer Jung]

Both Cluster Managers (Delta and SimpleTcpReplication) extend ManagerBase
but override createSession().

Maybe Filip or Peter can check how to make them long-time compatible with
your proposal?

> Managers extending ManagerBase should work and compile as before with no
changes unless they override the createSession method.





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

Improving jk_uri_worker_map in mod_jk

[Rainer Jung]

Hi,

while trying to improve parts of the mod_jk documentation I made some
observations concerning mod_jk's jk/native/common/jk_uri_worker_map.c I
wanted to discuss. I'm willing to provide patches but wanted to get some
opinions first.

I find the JkMount worker map decision code very difficult to understand
and I think there is some clean up needed:

1) JkUnMount

There seems to be no general rule, which JkUnMount wins the decision
process vs. conflicting JkMounts. One policy could be, to let JkUnMount
win in any conflicting case, except an exact match from JkMount.

Using longest context match might not be the best idea, since then there
is no way to just say

JkUnMount /*.gif

At the moment most of the time JkUnMount wins, but e.g. not if there is a
longer JkMount match with multiple '*' in it.

2) Map sort

For implementation it could be very helpful to sort the map not only
depending on context length (as it is done now), but to sort it e.g. like:

- First: positive exact Matches (Match returns immediately positive)
- Second: negative Matches (maybe these sorted in ascending context length
order) (Match returns immediately negative)
- Third: all other positive matches sorted in descending context length
order (Match returns immediatly)

3) Further there is a decision needed, which matches should be done case
sensitive on Win32. At the moment matches are only done case insensitive
in the case, when a suffix match is needed and the suffix starts with a
'.'. Anything special about that case?

4) Repairing JkMount /Context/*/Dir: from looking at the code I have the
impression that that case is buggy, but I did not yet test to prove it.

5) It's strange, that the general suffix case is handled very different
from the case, where the sufix starts with a dot. Also, implementation of
both suffix cases seems to be a little clumsy. It steps throught the uri
to find the character, which with the suffix starts and after that
compares the rest of the uri with the suffix for equality. Why not just
jumping to the correct position, since we already know the length of the
suffix.

6) There is some code for prevention of a security fraud coming from URLs
.../secret.jsp/ or .../secret.jsp. or with a ' ' after the suffix. The
code is called after no match is found. Then the uri is made more secret
and a shortened decision loop is called to make another mapping decision.

This fraud prevention e.g. is never called when JkUnMount matches. It also
seems to be used only in case a suffix pattern is used. What's the idea
behind it? Wouldn't it be more stable to beautify the URI before looping
through the mapping?

What about non-matches /Context//secret.jsp or /Context/./secret.jsp? Are
these URIs already simplified by Apache itself?

7) Concerning the new wildcard matches using multiple "*" or "?": They are
very useful, but they break the idea of "longest context wins", because
they take the whole pattern as the context, whereas the former possible
patterns only used anything up to the first "*" as the context. It makes
understanding the decisions (and correctly documenting the feature)
difficult. Also we should mention, that using more than just one "*" has a
performance penalty (since then the pattern is not split into context and
suffix with relatively easy matching algorithm, but instead the URI is
passed to a more general recursive wildcard matching method).

Any comments?

Rainer



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

Re: Releasing JK1.2.7

[Rainer Jung]

+1
Although not being a commiter I want to support your work with an 
informal +1. I appreciate calling it 1.2.7-beta due to the amount of 
code being changed.

Rainer
Mladen Turk wrote:
Hi,
There has been lots of changes in the JK,
and I'd like to tag and release 1.2.7-beta tomorrow.
Any objections?
Also,
This release will be marked as beta, and thus not
production ready. If it passes user's testing, in
a week or two I plan to release 1.2.8 stable.
The reason for that are couple of new things added like
extensive logging, socket timeouts, new load balancer
algorithm, etc... that needs 'real-world' testing.
Any comments?
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]

Re: Question about new mod_jk jk_lb_worker.c

[Rainer Jung]

Unfortunately I don't understand. Trying to combine rotatelogs with 
mod_jk.log in the following way (apache 1.3):

JkLogFile "|/home/jung/mkb/apache/bin/rotatelogs 
/home/jung/mkb/apache/logs/mod_jk.log 600"

doesn't work. It does neither log, nor spawn a rotatelogs process.
Inside apaches CustomLog rotatelogs works, but there is no obvious way 
to combine CustomLog with JkLogFile.

Mladen Turk wrote:
David Rees wrote:
Rainer Jung wrote, On 11/14/2004 7:31 AM:
0) Any ideas on rotating the mod_jk log file?

Use cronolog http://cronolog.org/ or the rotatelogs program included 
with Apache.

For that (or any kind of rotatelogs) we would need to spawn the
separate process that'll do the logging.
The only reasonable solution is to use the 'native' logging and
then use rotatelogs program.
MT.
-
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]

Re: Question about new mod_jk jk_lb_worker.c

[Rainer Jung]

I would be pleased to use rotatelogs, but it doesn't work with 
mod_jk.log (at least not last time I checked).

David Rees wrote:
Rainer Jung wrote, On 11/14/2004 7:31 AM:
0) Any ideas on rotating the mod_jk log file?

Use cronolog http://cronolog.org/ or the rotatelogs program included 
with Apache.

-Dave
-
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]

Re: Question about new mod_jk jk_lb_worker.c

[Rainer Jung]

Forgot to attach the patch for the overload feature. It is attached now.*** mod_jk.c.1.52   Sun Nov 14 15:00:20 2004
--- mod_jk.c.1.52.overload  Sun Nov 14 15:18:59 2004
***
*** 38,43 
--- 38,46 
  #include "util_script.h"
  #include "util_date.h"
  #include "http_conf_globals.h"
+ #ifdef OVERLOAD
+ #include "scoreboard.h"
+ #endif /* OVERLOAD */
  
  /*
   * Jakarta (jk_) include files
***
*** 63,68 
--- 66,75 
  #define JK_DURATION ("jakarta.worker.duration")
  #define JK_MAGIC_TYPE   ("application/x-jakarta-servlet")
  #define NULL_FOR_EMPTY(x)   ((x && !strlen(x)) ? NULL : x)
+ #ifdef OVERLOAD
+ #define EMPTY_FOR_NULL(x)   ((x) ? x : "") 
+ #define NEITHER_NULL_NOR_EMPTY(x)   (x && x[0] != '\0')
+ #endif /* OVERLOAD */
  
  /*
   * If you are not using SSL, comment out the following line. It will make
***
*** 134,139 
--- 141,170 
  int envvars_in_use;
  table *envvars;
  
+ #ifdef OVERLOAD
+ /*
+  * Configuration object for the mod_overload module. Parameters are
+  *
+  *   overload_uri URI that triggers load check, e.g. starting
+  * URI for a new application session
+  *   overload_uri_regexp  URI RegExp that triggers load check, e.g. 
starting
+  * URI pattern for a new application 
session
+  *   overload_uri_match   String representation of overload_uri_match
+  *   overload_max_busy_slots  maximum number of busy children allowed
+  * when doing load check
+  *   overload_error_page  URI of the error page shown (or redirected 
to),
+  * if there are too many children busy 
during load check
+  *   overload_is_external Flag to indicate, that overload redirect 
should
+  * be done externally insted of an 
internal redirect
+  */
+ char *overload_uri;
+ char *overload_uri_match;
+ regex_t *overload_uri_regexp;
+ int  overload_max_busy_slots;
+ char *overload_error_page;
+ int  overload_is_external;
+ #endif /* OVERLOAD */
+ 
  server_rec *s;
  } jk_server_conf_t;
  
***
*** 1404,1409 
--- 1435,1556 
  return NULL;
  }
  
+ #ifdef OVERLOAD
+ /* 
+  * JkOverloadURI directive Handling
+  *
+  * Take this config parameter only, if the string is not null and not empty 
+  */
+ static const char *set_overload_uri(cmd_parms *cmd, 
+  void *dummy, 
+  char *uri)
+ {
+ jk_server_conf_t *conf =
+ (jk_server_conf_t *)ap_get_module_config(cmd->server->module_config, 
+  &jk_module);
+ 
+ if ( NEITHER_NULL_NOR_EMPTY(uri) ) {
+ conf->overload_uri = uri;
+ }
+ 
+ return NULL;
+ }
+ 
+ /* 
+  * JkOverloadURIMatch directive Handling
+  *
+  * Take this config parameter only, if the string is not null and not empty 
+  */
+ static const char *set_overload_uri_match(cmd_parms *cmd, 
+   void *dummy, 
+   char *uri_match)
+ {
+ jk_server_conf_t *conf =
+ (jk_server_conf_t *)ap_get_module_config(cmd->server->module_config, 
+  &jk_module);
+ 
+ if ( NEITHER_NULL_NOR_EMPTY(uri_match) ) {
+ conf->overload_uri_regexp = ap_pregcomp(cmd->pool, uri_match, 
REG_EXTENDED);
+ if (conf->overload_uri_regexp == NULL) {
+ ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_DEBUG, cmd->server,
+  "Overload configure: "
+  "could not compile regexp %s",
+  uri_match);
+ conf->overload_uri_match = NULL;
+ conf->overload_uri_regexp = NULL;
+ } else {
+ conf->overload_uri_match = uri_match;
+ }
+ }
+ 
+ return NULL;
+ }
+ 
+ /*
+  * JkOverloadMaxBusySlots Directive Handling
+  *
+  * Take this config parameter only, if the string is not null and not empty. 
+  * We just take atoi of the string, so the integer value is the initial 
integer 
+  * in the string 
+  */
+ static const char *set_overload_max_busy_slots(cmd_parms *cmd,  
+   void *dummy, 
+   char *max_busy_slots)
+ {
+ jk_server_conf_t *conf =
+ (jk_server_conf_t *)ap_get_module_config(cmd->server->module_config, 
+  &jk_module);
+ 
+ if ( NEITHER_NULL_NOR_EMPTY(max_busy_slots) ) {
+ conf->overload_max_busy_slots = atoi(max_busy_slots);
+ }
+ 
+ return NULL;
+ }
+ 
+ /* 
+  * JkOverloadErrorPage Directive Handling
+  *
+  * Take this config parameter only, if the string is n

Re: Question about new mod_jk jk_lb_worker.c

[Rainer Jung]

Hi Mladen,

0) Any ideas on rotating the mod_jk log file?

>> 4) Open Problem

> This should work now with the latest patches.

Excellent! Actually I tried to understand the new principles. Using an old
style paper computer I can see that the values for lb_value are periodic.
But I must confirm, that I did not mathematically understand the
algorithm, maybe due to being a little ill. Are the mathematically
foundations behind that simple algorithm described anywhere?

>> 1) Limiting new application sessions if load is to high.
>>
>
> There is a problem with that. I made a implementation counting the
> number of busy childs/threads from scoreboard (took me entire day),
> but again we should count the number of connections to tomcat, cause
> the apache might be serving static content.
> Anyhow the idea is great and I'll implement it in the new mod_proxy
> for Apache 2.2 where we have extra slots in the scoreboard.
> Sad but we can not do that inside mod_jk unless we implement our
> own shared memory, that was prover to be bogus in jk2.

Apache serving static content is not a problem according to our
experience. Static content usually serves in very well under a second
(depending mostly on internet speed). The idea here is to detect a problem
with the application getting slow, e.g. because of backend systems not
responding fast enough. In this situation we want to limit creation of new
sessions. Counting the static requests doesn't really matter for us.

Example: During normal operation there are 5 static requests in work and
10 dynamic ones (that take much longer to complete). When there is a
problem with backend systems we will have 15 static ones, but more than
100 dynamic ones. So either counting or ommiting the static ones seems to
make no big difference.

You might want to take a look at the attached patch "patch_overload.txt"
for jk/native/apache1.3/mod_jk.c version 1.52. I don't have a patch for
Apache 2. The Patch places every change inside "#ifdef OVERLOAD". Also
there are some DEBUG-Log-Statements put inside "#ifdef DEBUG" which I
assume can now be done more consistently with your TRACE features.

Of course the "best" observable value would be the number of requests
belonging to the same webapp. So some possible enhancement would be to
count only requests with a fix URL prefix (that's not contained in the
patch).

>> 2) Multi-Cluster-Routing
>>
>
> Can you write some use case for that and perhaps some simple algo
> too. What about sticky-sessions and forcing failower if we do not have
> session replication?

Use case:

Enterprise application with redundant internet connections A and B.
A consists of two Apache instances A.a1 und A.a2, B of B.a1 and B.a2.
Behind are 4 Tomcat A.t1, A.t2, B.t1, B.t2.

A.t1 and A.t2 are clustered, B.t1 and B.t2 are clustered. mod_jk uses load
balancing with sticky sessions.

All Apaches can connect to any Tomcat, but A.t1 is local for A.a1, A.t2
for A.a2, B.t1 for B.a1 and B.t2 for B.a2:

A.a1   A.a2   B.a1   B.a2
 ||  X  ||  X  ||  X  ||
A.t1---A.t2   B.t1---B.t2

A.t1 and A.t2 are put into the same "domain" "A" in workers.properties,
B.t1 and B.t2 are put into the same "domain" "B" in workers.properties.

Now if you shutdown e.g. tomcat B.t1 for service/update (or if it breaks)
All apaches will know from the domain configuration, that sticky requests
for B.t1 have to go to B.t2. This is important, since only on that tomcat
the replicated sessions from B.t1 will exist.

Without domains you have to put all the Tomcats in one cluster. But then
all sessions are replicated to all tomcats. We have a production side
using 3x3=9 tomcats and a cluster with 9 nodes would mean too much
overhead.

The implementation uses and additional worker attribute domain, and if a
session has a jvmRoute, is sticky and the correct worker is in error state
another worker with the same domain attribute is chosen.

I have an implementation, but I have to adapt to your code changes. The
patch will only concern common/jk_util.c for configuration and
common/jk_lb_worker.c. I could provide the code, if you are interested.

For applications using sessions but without session replication I don't
see a way how to successfully fail over. Maybe I don't understand that
part of your question?

>> 3) Idle connection disconnect
> Use worker mpm. We just can not make maintainer thread for
> non-treaded mpm's like apache1.2 or prefork.

I don't use a seperate thread. I implemented this feature for Apache 1.3.
The principles are the following (and I can sent complete code if you are
interested):

a) In common/service.h in jk_worker define an additional JK_METHOD check
to be implemented by the workers:

/*
 * Check all workers on a regular basis,
 * even if they do not process requests.
 */
int (JK_METHOD *check)(jk_worker_t *w,
   int force,
   jk_logger_t *l);

b) In common/jk_worker.c provide an entry point wc_check, that will call
the check m

Re: Question about new mod_jk jk_lb_worker.c

[Rainer Jung]

Hi Mladen,
I include my original posting.
Hi Mladen,
great! I don't know how hard the following is to achieve, but it is the 
most prominent problem around mod_jk-Logging I know of:

mod_jk does neither support Apaches rotatelogs nor does it have a log 
rotation capability on its own. If you or any other committer has an 
idea how to introduce rotating logfiles, that would be a major achievement.

I have 3 more features I would be willing to provide. Maybe you or the 
other committers can comment, if they think that would be useful. All of 
them are already implemented for mod_jk/apache 1.3 and in production 
under high load.

1) Limiting new application sessions if load is to high.
You can configure a start URL for your application (regexp based). If a 
request X matches this URL, then mod_jk checks the scoreboard how many 
apache requests are being processed simultaneously at that moment. There 
is a configurable limti, and if that limit is reached, the request X 
will not be sent to tomcat, but instead be answered by some configurable 
 "local" static response (containing the info, that the load is to high 
and the user should try again later). Alternatively one can configure X 
to be answered by some external redirect.

2) Multi-Cluster-Routing
Tomcat-Cluster does only allow session replication to all nodes in the 
cluster. Once you work with more than 3-4 nodes there is too much 
overhead and risk in replicating sessions to all nodes. We split all 
nodes into clustered groups. I introduced a new worker attribute 
"domain" to let get_most_suitable_worker know, to which other nodes the 
session gets replicated (the workers in the same domain).

This enhancement has another benefit: Once mod_jk connects an apache 
process to a tomcat instance, the tomcat jk connector will need one 
thread for this connection as long as the apache process is alive.

Now assume you have multiple Apaches and Tomcats. The Tomcats are 
clustered and mod_jk uses sticky sessions. Now you are going to shut 
down (maintenance) one tomcat. All Apache will start connections to all 
tomcats. You end up with all tomcats getting connections from all apache 
processes, so the number of threads needed inside the tomcats will explode.

If you group the tomcats the connections normally will stay inside the 
groups (combine 2) with a routing load balancer to the apaches).

3) Idle connection disconnect
This one also comes from the fact, that a mod_jk connection consumes one 
tomcat connector thread, even if its idle for a long time. The idle 
connection check in mod_jk only works, if the connection is going to be 
used. Then it is checked if it was idle for too long and probably is 
beeing closed and reconnected.

I implemented a feature, where in configurable intervals all workers of 
an lb worker are checked for idle connections, even the ones which are 
not returned by get_most_suitable_worker. The rationale behind it is the 
same as in the second part of 2).

4) Open Problem
I didn't check your new code, but at least before there was the problem, 
that a recovered worker that was offline a long time (in means of load) 
got all the work after recovery. Of course there was a fixed conatsnt of 
load added to it after recovery to compensate, but working with a 
constant was not really solving the problem.

It looks like one should virtually add load to a worker, even during 
it's error time, so that it will get normal load after recovering.

Thanks for any comments!
Rainer
Mladen Turk wrote:
> Rainer Jung wrote:
>
>> Hi Mladen, hi everyone,
>>
>> i have a proposal for a slight enhancement concerning the log format of
>> mod_jk. Maybe you could consider including it in your recently 
revised code. It contains only changes to jk_util.c and I attach a patch 
relativ to version 1.32 of the file.
>>
>
> Hi Rainer.
>
> You are definitely on my track :) .
>
> I'm planning to add one additional log level, and clear all the log
> messages.
>
> 1. ERROR - fatal operations
> 2. WARN  - problems but not fatal
> 3. INFO  - production logging
> 4. DEBUG - protocol tracing
> 5. TRACE - function call logging
>
>> 1) Include the log level of a message in the log line.
>> 2) Include the PID of the logging process in the log file.
>
>
>
> I'd like to make a customizable log line, in the JkRequestLogFormat
> fashion to be able to add PID/ThreadId, level, etc...
>
> MT.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


Mladen Turk wrote:
Peter Rossbach wrote:
Hello Mladen,
I have see your checkin's and Rainer Jung very fine mod_jk extension 
concept mail.

I have two questions about lb changes:
a)   Why you not change the lb_value value after successful recovery 
a

mod_jk enhancement discussion

[Rainer Jung]

Hi Mladen,
great! I don't know how hard the following is to achieve, but it is the 
most prominent problem around mod_jk-Logging I know of:

mod_jk does neither support Apaches rotatelogs nor does it have a log 
rotation capability on its own. If you or any other committer has an 
idea how to introduce rotating logfiles, that would be a major achievement.

I have 3 more features I would be willing to provide. Maybe you or the 
other committers can comment, if they think that would be useful. All of 
them are already implemented for mod_jk/apache 1.3 and in production 
under high load.

1) Limiting new application sessions if load is to high.
You can configure a start URL for your application (regexp based). If a 
request X matches this URL, then mod_jk checks the scoreboard how many 
apache requests are being processed simultaneously at that moment. There 
is a configurable limti, and if that limit is reached, the request X 
will not be sent to tomcat, but instead be answered by some configurable 
 "local" static response (containing the info, that the load is to high 
and the user should try again later). Alternatively one can configure X 
to be answered by some external redirect.

2) Multi-Cluster-Routing
Tomcat-Cluster does only allow session replication to all nodes in the 
cluster. Once you work with more than 3-4 nodes there is too much 
overhead and risk in replicating sessions to all nodes. We split all 
nodes into clustered groups. I introduced a new worker attribute 
"domain" to let get_most_suitable_worker know, to which other nodes the 
session gets replicated (the workers in the same domain).

This enhancement has another benefit: Once mod_jk connects an apache 
process to a tomcat instance, the tomcat jk connector will need one 
thread for this connection as long as the apache process is alive.

Now assume you have multiple Apaches and Tomcats. The Tomcats are 
clustered and mod_jk uses sticky sessions. Now you are going to shut 
down (maintenance) one tomcat. All Apache will start connections to all 
tomcats. You end up with all tomcats getting connections from all apache 
processes, so the number of threads needed inside the tomcats will explode.

If you group the tomcats the connections normally will stay inside the 
groups (combine 2) with a routing load balancer to the apaches).

3) Idle connection disconnect
This one also comes from the fact, that a mod_jk connection consumes one 
tomcat connector thread, even if its idle for a long time. The idle 
connection check in mod_jk only works, if the connection is going to be 
used. Then it is checked if it was idle for too long and probably is 
beeing closed and reconnected.

I implemented a feature, where in configurable intervals all workers of 
an lb worker are checked for idle connections, even the ones which are 
not returned by get_most_suitable_worker. The rationale behind it is the 
same as in the second part of 2).

4) Open Problem
I didn't check your new code, but at least before there was the problem, 
that a recovered worker that was offline a long time (in means of load) 
got all the work after recovery. Of course there was a fixed conatsnt of 
load added to it after recovery to compensate, but working with a 
constant was not really solving the problem.

It looks like one should virtually add load to a worker, even during 
it's error time, so that it will get normal load after recovering.

Thanks for any comments!
Rainer
Mladen Turk wrote:
Rainer Jung wrote:
Hi Mladen, hi everyone,
i have a proposal for a slight enhancement concerning the log format of
mod_jk. Maybe you could consider including it in your recently revised 
code. It contains only changes to jk_util.c and I attach a patch 
relativ to version 1.32 of the file.

Hi Rainer.
You are definitely on my track :).
I'm planning to add one additional log level, and clear all the log
messages.
1. ERROR - fatal operations
2. WARN  - problems but not fatal
3. INFO  - production logging
4. DEBUG - protocol tracing
5. TRACE - function call logging
1) Include the log level of a message in the log line.
2) Include the PID of the logging process in the log file.

I'd like to make a customizable log line, in the JkRequestLogFormat
fashion to be able to add PID/ThreadId, level, etc...
MT.
-
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]

Enhancement: mod_jk-Logging

[Rainer Jung]

Hi Mladen, hi everyone,
i have a proposal for a slight enhancement concerning the log format of
mod_jk. Maybe you could consider including it in your recently revised 
code. It contains only changes to jk_util.c and I attach a patch relativ 
to version 1.32 of the file.

1) Include the log level of a message in the log line. That should be
easy and is very helpful to find relevant messages. It is pretty 
standard and much more safe than relying on the fact, that most error 
messages actually contain the word error in the message text.

2) Include the PID of the logging process in the log file. That helps a
lot at least for Apache 1.3, because one can also log the PID in Apaches 
access log. So it is easier to relate request info from access log lines 
and errors from mod_jk log lines to each other. Also it helps to 
unmangle, if log lines from several parallel requests are mixed inside 
mod_jk-log.

The patch is small, but since I'm not a very experienced C developer 
please check. I borrowed a define for Netware for getpid() from Apache's 
code. Not sure if it will work for Netware, or if configure needs to be
enhanced, if we use getpid(). It builds well on Solaris.

Thank's for considering.

*** jk_util.c  Tue Jul 13 15:58:10 2004
--- jk_util.c.new  Thu Aug 12 18:11:50 2004
***
*** 85,90 
--- 85,98 
  
  const char * jk_log_fmt = JK_TIME_FORMAT;
  
+ int log_level_max = 3;
+ static const char *log_levels[] = {
+ JK_LOG_DEBUG_VERB,
+ JK_LOG_INFO_VERB,
+ JK_LOG_ERROR_VERB,
+ JK_LOG_EMERG_VERB
+ };
+ 
  static void set_time_str(char * str, int len)
  {
  time_t  t = time(NULL);
***
*** 250,255 
--- 258,274 
  f++;
  }
  
+ const char *log_level;
+ if ( level >=0 && level <= log_level_max ) {
+ log_level=log_levels[level];
+ } else {
+ log_level="unknown";
+ }
+ 
+ #ifdef NETWARE
+ #define getpid() ((pid_t)GetThreadGroupID())
+ #endif
+ 
  #ifdef USE_SPRINTF /* until we get a snprintf function */
  #ifdef NETWARE
  buf = (char *) malloc(HUGE_BUFFER_SIZE);
***
*** 256,268 
  if (NULL == buf)
 return -1;
  #endif
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
  if(line)
  used += sprintf(&buf[used], " [%s (%d)]: ", f, line);
  #else 
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
  if(line)
  used += snprintf(&buf[used], HUGE_BUFFER_SIZE, " [%s (%d)]: ", f, 
line);
  #endif
--- 275,289 
  if (NULL == buf)
 return -1;
  #endif
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
! used += sprintf(&buf[used], "[%s] [%ld]", log_level, (long)getpid());
  if(line)
  used += sprintf(&buf[used], " [%s (%d)]: ", f, line);
  #else 
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
! used += snprintf(&buf[used], HUGE_BUFFER_SIZE, "[%s] [%ld]", 
log_level, (long)getpid());
  if(line)
  used += snprintf(&buf[used], HUGE_BUFFER_SIZE, " [%s (%d)]: ", f, 
line);
  #endif

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

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common JkMX.java

[Rainer Jung]

Hi,

thanks for accepting the authentication patch for the mx4j JMX adapter.

Are you going to apply it to the 5.0 branch too? That would be nice.

Have a nice weekend

Rainer Jung



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

Enhancement: mod_jk-Logging

[Rainer Jung]

I have a proposal for a slight enhancement concerning the log format of
mod_jk. As suggested by Henri Gomez, I sent the proposal to the
tomcat-dev list.
1) Include the log level of a message in the log line. That should be
easy and is very helpful to find relevant messages. It is a pretty
standard feature.
2) Include the PID of the logging process in the log file. That helps a
lot, because one can also log the PID in Apaches access log. So it is
easier to relate access log lines and mod_jk log lines to each other.
Also it helps to unmangle, if log lines from several parallel requests
are mixed. Of course this argumentation mainly is for apache 1.3, but
most people use mod_jk for it.
Both enhancements can be done in jk/native/common/jk_util.c.
I attach a small patch, which I also include at the end of the message.
Since I'm not an experienced C developer please
check. I borrowed a define for Netware for getpid() from Apache's code.
Not sure If it will work for Netware, or if configure needs to be
enhanced, if we use getpid(). It build well on Solaris and it is
done in the same way inside core apache.
The patch is in "diff -Nru"-format and is based on
jk/native/common/jk_util.c revision 1.28. I hope this is still up to date.
Thank's for considering.
Rainer Jung
--- jk_util.c   Tue Jul 13 15:58:10 2004
+++ jk_util.c.new   Thu Aug 12 18:11:50 2004
@@ -85,6 +85,14 @@
  const char * jk_log_fmt = JK_TIME_FORMAT;
+int log_level_max = 3;
+static const char *log_levels[] = {
+JK_LOG_DEBUG_VERB,
+JK_LOG_INFO_VERB,
+JK_LOG_ERROR_VERB,
+JK_LOG_EMERG_VERB
+};
+
  static void set_time_str(char * str, int len)
  {
  time_t  t = time(NULL);
@@ -250,19 +258,32 @@
  f++;
  }
+const char *log_level;
+if ( level >=0 && level <= log_level_max ) {
+log_level=log_levels[level];
+} else {
+log_level="unknown";
+}
+
+#ifdef NETWARE
+#define getpid() ((pid_t)GetThreadGroupID())
+#endif
+
  #ifdef USE_SPRINTF /* until we get a snprintf function */
  #ifdef NETWARE
  buf = (char *) malloc(HUGE_BUFFER_SIZE);
  if (NULL == buf)
 return -1;
  #endif
-set_time_str(buf, HUGE_BUFFER_SIZE);
-used = strlen(buf);
+set_time_str(buf, HUGE_BUFFER_SIZE);
+used = strlen(buf);
+used += sprintf(&buf[used], "[%s] [%ld]", log_level,
(long)getpid());
  if(line)
  used += sprintf(&buf[used], " [%s (%d)]: ", f, line);
  #else
-set_time_str(buf, HUGE_BUFFER_SIZE);
-used = strlen(buf);
+set_time_str(buf, HUGE_BUFFER_SIZE);
+used = strlen(buf);
+used += snprintf(&buf[used], HUGE_BUFFER_SIZE, "[%s] [%ld]",
log_level, (long)getpid());
  if(line)
  used += snprintf(&buf[used], HUGE_BUFFER_SIZE, " [%s
(%d)]: ", f, line);
  #endif


--- jk_util.c   Tue Jul 13 15:58:10 2004
+++ jk_util.c.new   Thu Aug 12 18:11:50 2004
@@ -85,6 +85,14 @@
 
 const char * jk_log_fmt = JK_TIME_FORMAT;
 
+int log_level_max = 3;
+static const char *log_levels[] = {
+JK_LOG_DEBUG_VERB,
+JK_LOG_INFO_VERB,
+JK_LOG_ERROR_VERB,
+JK_LOG_EMERG_VERB
+};
+
 static void set_time_str(char * str, int len)
 {
 time_t  t = time(NULL);
@@ -250,19 +258,32 @@
 f++;
 }
 
+const char *log_level;
+if ( level >=0 && level <= log_level_max ) {
+log_level=log_levels[level];
+} else {
+log_level="unknown";
+}
+
+#ifdef NETWARE
+#define getpid() ((pid_t)GetThreadGroupID())
+#endif
+
 #ifdef USE_SPRINTF /* until we get a snprintf function */
 #ifdef NETWARE
 buf = (char *) malloc(HUGE_BUFFER_SIZE);
 if (NULL == buf)
return -1;
 #endif
-set_time_str(buf, HUGE_BUFFER_SIZE);
-used = strlen(buf);
+set_time_str(buf, HUGE_BUFFER_SIZE);
+used = strlen(buf);
+used += sprintf(&buf[used], "[%s] [%ld]", log_level, (long)getpid());
 if(line)
 used += sprintf(&buf[used], " [%s (%d)]: ", f, line);
 #else 
-set_time_str(buf, HUGE_BUFFER_SIZE);
-used = strlen(buf);
+set_time_str(buf, HUGE_BUFFER_SIZE);
+used = strlen(buf);
+used += snprintf(&buf[used], HUGE_BUFFER_SIZE, "[%s] [%ld]", log_level, 
(long)getpid());
 if(line)
 used += snprintf(&buf[used], HUGE_BUFFER_SIZE, " [%s (%d)]: ", f, line);  
  
 #endif


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

RFE: Basic auth jmx http adapter

[Rainer Jung]

Hi,

I append a small patch, including the necessary features to support basic
and digest authentication for the mx4j JMX http connector.

The way the http adaptor is initialized in JkMX.java today gives no
possibility to restrict access to it. Since the JMX console is very
powerful
I included code n JkMx.java to parse 3 additional configuration options
from jk2.properties to the connector:

mx.authMode
mx.authUser
mx.authPassword

The patch is very local and simple. It is based on the newest version of
JkMX.java. Thank for considering.

Rainer Jung

% diff -w -c JkMX.java.orig JkMX.java
*** JkMX.java.orig  Thu Jun 17 21:03:20 2004
--- JkMX.java   Sun Aug 29 14:16:35 2004
***
*** 39,44 
--- 39,47 
  private boolean enabled=false;
  private int httpport=-1;
  private String httphost="localhost";
+ private String authmode="none";
+ private String authuser=null;
+ private String authpassword=null;
  private int jrmpport=-1;
  private String jrmphost="localhost";
  private boolean useXSLTProcessor = true;
***
*** 86,91 
--- 89,118 
  return httphost;
  }
  
+ public void setAuthMode(String mode) {
+ authmode=mode;
+ }
+ 
+ public String getAuthMode() {
+ return authmode;
+ }
+ 
+ public void setAuthUser(String user) {
+ authuser=user;
+ }
+ 
+ public String getAuthUser() {
+ return authuser;
+ }
+ 
+ public void setAuthPassword(String password) {
+ authpassword=password;
+ }
+ 
+ public String getAuthPassword() {
+ return authpassword;
+ }
+ 
  /** Enable the MX4J JRMP internal adapter
   */
  public void setJrmpPort( int i ) {
***
*** 162,167 
--- 189,205 
  mserver.setAttribute(httpServerName, new Attribute("Host", 
httphost));
  mserver.setAttribute(httpServerName, new Attribute("Port", new 
Integer(httpport)));
  
+ if( authmode!=null  && ( "none".equals(authmode) || 
"basic".equals(authmode) || "digest".equals(authmode) ) )
+ mserver.setAttribute(httpServerName, new 
Attribute("AuthenticationMethod", authmode));
+ 
+ if( authuser!=null && authpassword!=null )
+ mserver.invoke(httpServerName, "addAuthorization",
+ new Object[] {
+ authuser,
+ authpassword},
+ new String[] { "java.lang.String", "java.lang.String" });
+ 
+ 
  if(useXSLTProcessor) {
  ObjectName processorName = 
registerObject("mx4j.tools.adaptor.http.XSLTProcessor",
"Http:name=XSLTProcessor");
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Documentation hint: getting rid of JMX HTTP adaptor errors

[Rainer Jung]

Hi,

using TC 5.0.27 together with the jmx http adaptor coming with mx4j 2.0.1
there are still error messages and missing data in the resulting html
pages. The errors disappear when using xalan 2.6.0. The release Notes for
J2SDK 1.4.2_05 say, that Sun still bundles 2.4.1+. Maybe that's worth a
hint either in the release notes, or in the doc, where the parameter
mx.enabled in jk2.properties is explained.

The error messages are:

SystemId Unknown; Line #12; Column #81; Cannot add attribute name after
child nodes or before an element is produced.  Attribute will be ignored.

produced when accessing the default page /serverbydomain (and the domain
name is missing in the result page) and

SystemId Unknown; Line #14; Column #80; Cannot add attribute objectname
after child nodes or before an element is produced.  Attribute will be
ignored.
SystemId Unknown; Line #14; Column #80; Cannot add attribute description
after child nodes or before an element is produced.  Attribute will be
ignored.
 when accessing /mbean.xml (and objectnme and description of the mbean is
mising).

All error messages disappear when using xanlan 2.6.0. I checked by putting
xalan.jar from the 2.6.0 distribution to the endorsed directory of tomcat.
Furthermore the previously missing data now is included in the result
pages.

Thanks for considerung

Rainer Jung



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

Re: [VOTE] 4.1.31 maintenance release

[Rainer Jung]

I think there is no clear explanation of the TC4 support situation on 
the tomcat web site. Maybe to be fair to users you should start by 
adding statements, that TC 5 is the preferred version and TC 4 is soon 
to be supported only for major bugs and security patches. Furthermore 
you could expliciteley recommend an update to TC5 for all active TC4 users.

Rainer
Shapira, Yoav wrote:
Hola,

I think we long ago agreed not to vote -1 just because you want
somebody
to work on a different codebase :-)

It must have been long enough ago that I wasn't here ;)  I don't
remember it.  Anyways, since is a (non-lazy) majority vote so my -1 is
not a veto, just an opinion.  We already had two -1's on the lazy
majority vote, which is why this vote is needed.  Since there are more
than two more +1 than -1's, this vote will pass and 4.1.31 will happen..
I like to think that when we say something is "maintained" it doesn't
just mean doing a release.  It also means we support it on the mailing
list and by checking Bugzilla periodically and addressing issues.  But I
guess I'm fairly alone in this opinion, so too bad ;)  

I respect the voting system nonetheless, I have no issues with it.  The
vote passes, the release will happen, no problem.  I will still suggest
users having problems with 4.x upgrade to 5.x, but the people who want
this release so much are of course welcome to support it actively on the
mailing list as well ;)
Yoav

This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.
-
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]

Re: Tomcat 5.0.28 release

[Rainer Jung]

We are using it also and it is very helpful.
It is one of the standard product features of a container to be able to 
seperate container product installation from runtime instance specific 
files.

It works very nicely with tomcat. We can even allow instance admins to 
extend TC by changing to an alternate catalina.properties file 
(classloader definitions). It's not just a question of users sharing the 
base installation.

I have a small enhancement request: we regularly change catalina.sh to 
include a file setenvInstance.sh from CATALINA_BASE/bin if it exists. We 
do this immediately after CATALINA_TEMPDIR is set. This way all 
instances share the same catalina.sh and instance specific commandline 
flags (memory sizing, catalina.properties, ...) can be done in the 
instance local setenvInstance.sh without changing the product installation.

Please keep the separation of product installation and runtime instance.
Rainer Jung
kippdata informationstechnologie
George Sexton wrote:
How about stopping support for that scenario?  I mean drop 
the CATALINA_BASE versus CATALINA_HOME feature, (or set them 
to always equal each other, if we want to leave them in the 
code base), and don't allow users to share installations 
except by the user home directory valve.

I am really against this. I use CATALINA_HOME and CATALINA_BASE. The reason
that I use them is that they provide a clean way of upgrading frequently. It
lets me maintain a stock Tomcat Directory, with all of my customization
(conf files, etc) in a separate directory. 

Please don't drop this functinality.
George Sexton
MH Software, Inc. - Home of Connect Daily Web Calendar
http://www.mhsoftware.com/
Voice: 303 438 9585
 

-
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]

Re: [proxy] New implementation ready for testing

[Rainer Jung]

Concerning session stickyness: is the following scenario possible with 
your mod_proxy, at least in the future?

We support a critical high load application which is running in a two 
cell environment.

We replicate via TC cluster locally inside each cell (2 TCs) but not 
over the boundaries of the cells (cluster would be to big and for a cell 
outage it would be acceptable to loose sessions). So a cell is equal to 
a replication domain resp. to a TC cluster. Let's say TCs with jvmRoute 
A1, A2, B1, B2, where A and B are the cells.

Also we use session stickyness on multiple Apache/mod_jk to keep hopping 
of requests from primary to secondary TCs low. Any apache needs to send 
requests sticky to the correct TC instance. Both TC clusters provide the 
same webapps.

Now, if TC A1 is going down for maintenance (or breaks), and apache 
receives a request with jvmRoute A1, it should send the request to 
another member of the same cluster, in this case A2 and not to B1 or B2. 
Could this be done with mod_proxy?

I did some project patches for mod_jk to make this happen (adding an 
attribute "domain" to the balanced_workers and enhancing 
get_most_suitable_worker in the lb worker.

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

Enhancement: mod_jk-Logging

[Rainer Jung]

I have a proposal for a slight enhancement concerning the log format of 
mod_jk.

1) Include the log level of a message in the log line. That should be 
easy and is very helpful to find relevant messages. It is pretty standard.

2) Include the PID of the logging process in the log file. That helps a 
lot, because one can also log the PID in Apaches access log. So it is 
easier to relate access log lines and mod_jk log lines to each other. 
Also it helps to unmangle, if log lines from several parallel requests 
are mixed. Of course this argumentation mainly is for apache 1.3, but 
most people use mod_jk for it.

Both enhancements can be done in jk_util.c.
I attach a small patch. Since I'm not an experienced C developer please 
check. I borrowed a define for Netware for getpid() from Apache's code. 
Not sure If it will work for Netware, or if configure needs to be 
enhanced, if we use getpid(). It build well on Solaris.

Thank's for considering.
*** jk_util.c  Tue Jul 13 15:58:10 2004
--- jk_util.c.new  Thu Aug 12 18:11:50 2004
***
*** 85,90 
--- 85,98 
  
  const char * jk_log_fmt = JK_TIME_FORMAT;
  
+ int log_level_max = 3;
+ static const char *log_levels[] = {
+ JK_LOG_DEBUG_VERB,
+ JK_LOG_INFO_VERB,
+ JK_LOG_ERROR_VERB,
+ JK_LOG_EMERG_VERB
+ };
+ 
  static void set_time_str(char * str, int len)
  {
  time_t  t = time(NULL);
***
*** 250,255 
--- 258,274 
  f++;
  }
  
+ const char *log_level;
+ if ( level >=0 && level <= log_level_max ) {
+ log_level=log_levels[level];
+ } else {
+ log_level="unknown";
+ }
+ 
+ #ifdef NETWARE
+ #define getpid() ((pid_t)GetThreadGroupID())
+ #endif
+ 
  #ifdef USE_SPRINTF /* until we get a snprintf function */
  #ifdef NETWARE
  buf = (char *) malloc(HUGE_BUFFER_SIZE);
***
*** 256,268 
  if (NULL == buf)
 return -1;
  #endif
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
  if(line)
  used += sprintf(&buf[used], " [%s (%d)]: ", f, line);
  #else 
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
  if(line)
  used += snprintf(&buf[used], HUGE_BUFFER_SIZE, " [%s (%d)]: ", f, line); 
   
  #endif
--- 275,289 
  if (NULL == buf)
 return -1;
  #endif
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
! used += sprintf(&buf[used], "[%s] [%ld]", log_level, (long)getpid());
  if(line)
  used += sprintf(&buf[used], " [%s (%d)]: ", f, line);
  #else 
! set_time_str(buf, HUGE_BUFFER_SIZE);
! used = strlen(buf);
! used += snprintf(&buf[used], HUGE_BUFFER_SIZE, "[%s] [%ld]", log_level, 
(long)getpid());
  if(line)
  used += snprintf(&buf[used], HUGE_BUFFER_SIZE, " [%s (%d)]: ", f, line); 
   
  #endif

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

Re: Dynamic updates and Apache v2.0

[Rainer Jung]

Graham Leggett wrote:
Ideally tomcat should be able to pass to httpd info like "hey, there is 
a new server in the pool, and it's called foo" or "do me a favour, I'm 
being taken out of the pool, so don't send me any new requests".


Config of httpd would be as simple as
ProxyPass /myWebapp ajp://seedserver/myWebapp
The server seedserver could then tell httpd about all the other servers 
in the cluster dynamically. "seedserver" could resolve to one machine, 
or more than one machine.

From what I experienced I can give an analogy with BEA WebLogic:
The cluster client uses a URL to contact the WLS cluster. The URL has 
the form

protocol://server1,server2,...:port
The URL supports a list of servers to avoid bootstrapping problems in 
case of a single server breakdown. Usually two independent nodes of the 
cluster are statically configured in this URL.

While the client starts, it tries to contact all servers configured in 
the URL. The first server that answers the request replies with a list 
of all cluster members.

Then the client connects to all cluster members.
The communication of the client with the cluster members includes 
several obvious ways of dynamically adding or removing cluster nodes:

- a heartbeat protocol, so that the client detects a defect server by 
missing heartbeat packets
- a configurable time interval after which the client updates its 
cluster server list by asking one of the already known cluster servers
- a clean way of noticing the client by a cluster server that is in the 
process of being shut down

To ensure consistency, all cluster members exchange membership data, so 
that they have the same view of the cluster topology.

Furthermore the client loads communication code from the server. The 
code contains important information about load balancing. So the client 
learns from the cluster servers, if they should be used in a 
round-robin, or in a weight based way, and what their weights are. Again 
the cluster servers share this information via replication.

This setup is working well in many real world scenarios. Maybe it 
indicates, that it is a good idea to learn at least cluster topology and 
load balancing configuration from statically configured bootstrap 
cluster nodes. Of course some information still needs to be managed 
dynamically inside the cluster. But with all the JMX support in Tomcat, 
that seems to be a place, where that should be feasible.



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

TC 5: Support for multiple Coyote JK-Pools

[Rainer Jung]

Am I right, that by design TC 5 only fully supports one Coyote JK pool 
at the moment?

I enabled JMX HTTP adaptor via mx.enabled=true. Obviously 
org.apache.jk.common.JkMX tries to initialize the JMX HTTP adaptor not 
only once, but for every Coyote JK pool configured in server.xml. For 
the second pool I get an exception when starting tomcat (see below).

When trying to stop TC, the Coyote HTTP pool is shut down correctly, and 
one of the two JK pools doesn't listen any more, but the second JK pool 
still listens and TC does not shut down. Retrying shutdown does not 
help, the process is still alive.

Any plans (or work already done) to refactor JkMain/JkMX for 5.next?
Rainer Jung
Exception during start:
2004-07-26 12:37:58,929 (main) org.apache.jk.common.JkMX/ERROR: Can't 
load the MX4J http adapter
javax.management.InstanceAlreadyExistsException: Http:name=HttpAdaptor
at mx4j.server.MBeanServerImpl.register(MBeanServerImpl.java:1123)
at 
mx4j.server.MBeanServerImpl.registerImpl(MBeanServerImpl.java:1054)
at 
mx4j.server.MBeanServerImpl.registerMBeanImpl(MBeanServerImpl.java:1002)
at 
mx4j.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:978)
at org.apache.jk.common.JkMX.registerObject(JkMX.java:314)
at org.apache.jk.common.JkMX.loadAdapter(JkMX.java:157)
at org.apache.jk.common.JkMX.init(JkMX.java:268)
at org.apache.jk.server.JkMain.start(JkMain.java:339)
at 
org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.java:193)
at 
org.apache.coyote.tomcat5.CoyoteConnector.start(CoyoteConnector.java:1527)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:489)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)
at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:284)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:422)


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

Re: [PATCH] JK and load-balanced POSTs

[Rainer Jung]

Henri Gomez wrote:
Thanks to check if it works for you with the latest jk in CVS...
... and I think we expect the new 1.2.6 release soon. So either wait for 
the new release - or even better: send feedback on the CVS as soon as 
possible.

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

Re: Time for JkMountExclude in jk 1.2.x ?

[Rainer Jung]

As I started the discussion thread on releasing mod_jk 1.2.6 a few days 
ago, I would also prefer to have the stable code released and not adding 
new features. Releasing 1.2.6 as-is would already be benefitial to many 
people.

Henri: thank you very much for preparing the release.
For post-1.2.6 releases: JkMount only gives the ability to seperate 
between Apache and Tomcat on the basis of: default handled by Apache and 
special things handled by Tomcat.

Now often the situation is reversed: complete contexts (detected by 
URL-prefixes) should be handled by default by the web container, and 
only special static objects (subdirectorie or, file name suffixes) by 
apache. So JkMountExclude would make a lot of sense.

Henri Gomez wrote:
David Rees wrote:
I would suggest leaving it for the next release of mod_jk, unless it 
is simple and there is little chance of it adding any regressions.

-Dave
I'm puzzled with JkMount when I have to exclude some URL.
I won't do anything before release, if everybody agreed on a
quick 1.2.6 release.
But works should be conducted to add exclusions, may be also via
Notes

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

Ready for mod_jk 1.2.6 release?

[Rainer Jung]

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 ;-)

Another good argument: The documentation of the new features is already 
there 
(http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/workershowto.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]

Re: Any synchronization issues with SMP?

[Rainer Jung]

TC clustering uses GZIP(In|Out)putStream in replication. I don't know, 
if there is buffering on top. Filip?

Rainer
Martin Schulz wrote:
OT: The following is advice to servlet developers rather than container 
developers.

For what it's worth, just be careful when you use GZIP(In|Out)putStream,
since the native code uses a mutex (for no good reason, imho), to prevent
garbage collection from interfering with the array being used. Bottleneck
where I didn't expect one.
In particular, never place a Object(In|Out)putStream directly on top of the
GZIP streams, always use a buffer stream between the two.
Reason is that the object stream reads/writes in very small chunks,
causing four system calls per chunk.
Or else interesting things are going to happen on larger SMP systems.
 Martin

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

Re: Any synchronization issues with SMP?

[Rainer Jung]

Hi,
we know one application running on 9 systems with 4 US II CPUs each
under Solaris 9. Peak request rates at 20 requests/second per system.
Tomcat is 4.1.29, Java is 1.3.1_09. No symptoms like yours!
You should send a signal "QUIT" to the jvm process during the
unresponsiveness time. This is a general JVM mechanism (at least for sun
JVMs). The signal writes a stack trace for each thread on STDOUT (so you
should also start tomcat with redirection of STDOUT the output to some
file). Beware: older JVM in rare cases stopped working after getting
this signal (not expected with 1.3.1_09).
In this stack dump you should be able to figure out, in which methods
most of your threads stay and what the status is.
Is there native code included (via JNI)? Any synchronization done in the
application itself? Are you using Tomcat clustering? Which JVM?
Sincerely
Rainer Jung
Martin Schulz wrote:
Can someone confirm that Tomcat works well on busy SMP systems (e.g. Sun 
V1280),
or whether there are problems in Tomcat.

Here's what we have at our end:
We are currently performance testing our application (Tomcat 4.1.30) on 
Solaris 9,
on a V1280 system w. 8 CPUs. (SDK 1.4.2_04).  Transaction rates are 
moderate, around 30/s.

The application, after about 30-40 minutes, gets unresponsive for a 
little while (1-10 minutes),
gets back to work (for a varying period of time, but definitely under 30 
min), and then the cycle
repeats.  At half the transaction rate, the smptoms are no longer easily 
observed,.

The above symptoms disappear when we use a single CPU, or a single board 
of 4 CPUs.
That scenario seems to imply synchronization problems soemwhere in the 
Java code.
The problem could not be observed in development configurations either 
(Wintel, 1-CPU Sun
boxes.)

The behavior is such that connections get accepted, but no response is 
sent (established connections
remain at a fixed level).   The number of connections in this state 
varies (20-70).

 From the timers we keep we learn that the service gets stuck when 
reading the input.
Once unblocked the responses get sent out rapidly again.

We have tuned the system for efficient, high-volume TCP-IP traffic.
We tried the coyote connector and the HttpConnector, both with the same 
effect.

Please respond if you can confirm or dismiss threading issues in Tomcat.
We would also be ineterested in testing approaches for such a scenario.
.I have kept system statistics for both scenarios and can provide these 
on request.

Thanks!
   Martin Schulz
-
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]

TC Cluster: does SmartQueue fit into DeltaManager

[Rainer Jung]

Hi,

I opened Bug 28161 last week. I found out yesterday, that the problem comes
from using the SmartQueue together with DeltaManager and asynchronous
replication (see Bug-Report for details).

What are the plans now? If I knew, that a fix will take several days I might
substitute the SmartQueue by an improvised FIFO to proceed with further
tests on our application.

Any comments are welcome, especially your opinion on the problem and on what
to expect technically and with respect to time frame from a fix.

Thank you for the important and very good work you all do on Tomcat.

Sincerely

Rainer Jung
kippdata informationstechnologie



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

RE: Ever increasing heap size with Tomcat 3.2.3 !!!

[Rainer Jung]

Hi,

I know Tomcat 3.2.3 in a banking production doing heavy work with huge 
uptimes - no memory leaks have been found (but: OS is Solaris).

The only time I thought there were memory leaks was also during stress test 
in two cases:

1) Having a lot of debug log output (but really a lot)
2) Using JSPs (or Servlets) creating a lot of web container sessions in tomcat

Here point 2) perhaps needs further explanation:

By default a JSP is embedded in a web container session. This session can 
be used by the developper to put data in the session, that the same user 
should be able to use later. Even if the developer does not use a session 
the pure existence of a session consumes memory. In a JSP you can set the 
session attribute of the page directive to false, if you don't use web 
container sessions.

In case your stress test calls only small JSPs or servlets, which 
(implicitely) create sessions, you might end up creating 10s of sessions 
per second. Such an implicit session has a default timeout of 15 minutes, 
before it is freed. So it would be interesting how the memory bahaves with 
respect to time.

A general debug strategy: simplify your setup, e.g. throw away all the 
backend logic in your JSPs/Servlets/helper classes. Reduce to a very simple 
JSP/Servlet to check, if you can really reproduce the leak in tomcat. Maybe 
it's in the code of some helper classes?

Also if you have a possibility to try under a different platform (like 
Solaris) this might give an indication. You only need to put tomcat there, 
you can still leave IIS on Windows as the webserver.

Rainer Jung

At 17:31 19.12.01 , you wrote:
>Make sure you don't have lots of logging turned on.  Tomcat logs message
>don't get written to the log files immediately.  They go into a queue in
>memory and a low priority thread later flushes message from this queue to
>disk.  If the server is really busy the log writer thread won't get to
>execute and messages will back up in the in-memory queue.  When the load
>decreases the queue will be flushed and memory will be released.
>
>I've spent a fair amount of time running stress tests on Tomcat 3.2.x using
>JProbe and I have not seen any memory leaks.
>
>
>Marc Saegesser
>
> > -Original Message-
> > From: Hawkins, Keith (Keith) [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, December 18, 2001 11:34 AM
> > To: [EMAIL PROTECTED]; tomcat-user
> > Subject: Ever increasing heap size with Tomcat 3.2.3 !!!
> >
> >
> >
> > Hello,
> >
> > Before my manager insists that we switch to JRun,  can any of
> > the Tomcat
> > developers help with a problem of an ever increasing heap size of the
> > Tomcat java.exe. ??  (We are running Tomcat 3.2.3 and
> > JRE1.3.1. and the
> > IIS redirector)
> >
> > We are running a load test using LoadRunner scripts on some JSP and
> > servlets that are running under Tomcat.  The load is not all
> > that heavy
> > but the heap size of the Tomcat java.exe process keeps growing and
> > growing. We modified the java command line to start with  -Xmx128m to
> > allow 128 MB of heap but we still max out after a day or so.   We even
> > modified one of our servlets to create a thread that runs
> > Runtime.gc()
> > every 30 seconds.   The LoadRunner scripts just keep logging
> > in the same
> > 5 people via our authentication servlet so you would think memory use
> > would level out at some point.
> >
> > Nothing we do seems to keep the heap size from growing.
> >
> > Are there known issues with Tomcat and heap size??
> >
> > Doing a web search revealed numerous posts with people having similar
> > problems so I believe there is a problem.   The standard
> > response these
> > people receive is to increase the heap size via -Xmx   But that seems
> > like a band-aid rather than a real solution.   That just delays the
> > inevitable.
> >
> > Any insight as to how to keep the Tomcat process from
> > grabbing more and
> > more memory would be appreciated.
> >
> > Thanks,
> > Keith
> >
> >
> >
> >
> >
> >
> >
> >
>
>--
>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]>

Re: Session problems in Apache.

[Rainer Jung]

Hi,

which Tomcat-Version do you use? Everything before 3.2.3 has a serious bug 
in a pool-Utility which leads to several problem, one of them is breaking 
the relation between requests and responses. That one is fixed in 3.2.3, 
but maybe its related to your problem.

You should give more technical details about your setup.

Rainer Jung


At 12:01 27.08.01 , you wrote:
>Hi.
>
>We are developing a crucial site with payment options.
>
>We need to do server side session handling a lot.
>We have implemented the same using JSP/Bean and default sessionobjects of
>the webserver.  We assume that the implementation is correct.  The Webserver
>is Apache/tomcat.
>
>But when the load increases, say beyond 100 simultaneous users, we find that
>part of the variables between sessions swap.
>
>We want to know what can be done.
>Are there any parameters to be set in the webserver???
>
>
>M.S. Anand.

Some Tomcat JSP Performance Numbers

[Rainer Jung]

I thought it might be interesting to contribute some quickly taken JSP 
performance figures for tomcat.

The numbers were not taken especially for the list, so the setting might 
look a little strange.

All Measurements were short-time, typically running app. 2 minutes. I used 
a very simple JSP, with a page directive setting session to false, then a 
configurable sleep and then just writing out a stupid HTML-Page of varying 
length.


I varied the number of simulated client threads (concurrent requests), size 
of JSP output, number of server CPUs an finally I put apache and tomcat on 
seperate servers.

Configuration

Apache 1.3.14, Tomcat 3.2.2-beta2, AJP13, Solaris 2.6, JDK 1.2.1_03
HTTP-client simulation on another system, simulating 100 clients (differing 
numbers are mentioned),
100Mbit switched Ethernet between the systems,
Plattform webserver and client simulator seperate Sun E420R 4CPU/4GB, 400MHz
Apache andTomcat running on the same system, last two szenarios I put them 
on different servers,

Tuning

Apache uses max 256 Processes, AJP13-Pool max 256 Threads
TCP/IP close_wait_interval 30 Sec

Tests

variable Output Size, no Sleep

Size  Used BandwidthPerformance
25Bytes   - 430 JSP/sec
1KB   ->400 JSP/sec
4KB   2MBit/16MBit  415 JSP/sec
16KB  2MBit/44MBit  310 JSP/sec

variable Sleeps, 1KB Size of Output

Sleep Performance
0ms   >400 JSP/sec
  100ms360 JSP/sec
  400ms185 JSP/sec
1600ms 60 JSP/sec

variable Number of Client-Threads, no Sleep, 25 Bytes Size of Output

Clients  Performance
200  330 JSP/sec
175  360 JSP/sec
150  380 JSP/sec
125  405 JSP/sec
100  415 JSP/sec
  75  435 JSP/sec
  50  380 JSP/sec
  25  225 JSP/sec

variable Number of CPUs, no Sleep, 25 Bytes Size of Output

CPUs  Performance
4 430 JSP/sec
3 395 JSP/sec
2 320 JSP/sec
1 195 JSP/sec

And now two measurements with apache, tomcat and the client simulation 
running on three different systems of the above type:

no Sleep, 25 Bytes Size of Output

Clients  Performance
100  530 JSP/sec
200  370 JSP/sec

Again seperated, but variable Number of CPUs, no Sleep, 25 Bytes Size of Output

CPUs  Performance
4 500 JSP/sec
2 510 JSP/sec
1 415 JSP/sec


Rainer Jung

kippdata informationstechnologie GmbH
Bornheimer Straße 33a
D-53111 Bonn
Germany

Tel.: +49/0228/98549-0
Fax:  +49/0228/98549-50
email: [EMAIL PROTECTED]

AJP14 Suggestion

[Rainer Jung]

I want to know how the developers think about adding a request id to ajp14 
requests, which is then presented back in the response phase.

Background:

We had serious trouble in diagnosing problems with tomcat 3.2 related to 
bug 728 (SimplePool synchronization issue).

The problem caused customers in an ecommerce application to receive 
responses which belonged to other requests, i.e. were meant to be seen by 
some other customer. This bug is fixed now, but I wonder if one could make 
the whole request-response handling more robust by adding an id to the 
request. This id should then be given back by te response, preferably 
during a very late phase. The requesting component could then check, if the 
request and response ids are the same.

If furthermore the id would be part of the servlet infrastructure, then 
application developers could take the id and pass it on the application 
server etc.

I know, that at the moment this is not contained in a standard or existing 
product, but in a situation where money is involved on the customer side, 
people implementing solutions with tomcat would poosibly like very much 
such checking possibilities.

Once again: we had a hard time and were missing such a possibility a lot. 
In Tomcat 3.2 you can easily produce stress test situations where a request 
gets as response body two valied bodies concatenated, one of them belonging 
to another request, or some other body, or no body at all, or a corrupted 
one. An id would at least make sure the response belongs to the right request.

In the apache 1.3 szenario, the id would have to be generated by mod_jk!

Any comments?

Rainer Jung

kippdata informationstechnologie GmbH
Bornheimer Straße 33a
53111 Bonn

Tel.: 0228/98549-0
Fax:  0228/98549-50
email: [EMAIL PROTECTED]

Re: URI Rewritng using Apache/mod_ssl..the old story

[Rainer Jung]

As far as I understand the fix does not mean, that you get rid of jsse.jar 
and jnet.jar.

Core Java does not include an https protocol handler, but such a thing is 
implicitely used in http-URL-creation inside tomcat (although that could be 
done easier). Java is open to add new protocol handlers. The way it works 
is exactly by using own or third party protocol handlers and by defining

java.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol


(or to something else which knows about your own or third party protocol 
handlers).

At that point your java application will be https enabled. The problem does 
not occur with http, since standard java contains an http protocol handler 
and the standard java.protocol.handler.pkgs knows about that one.

Of course as long as you don't really want tomcat itself to talk https 
(e.g. the browser talks https to apache and you enable "JkExtractSSL On" 
for mod_jk, so that redirects and forwards go to a correct https-URL) you 
could think of supplying tomcat with basic https-URL-understanding not 
using the fully featured protocol handlers. On the other side, since one 
would like to have the ability to use https directly from tomcat you would 
have to prepare to use the protocol handlers any way.

Rainer Jung

At 08:49 30.05.01 , you wrote:

>I have just installed TC3.2.2 final, and URI Rewiting won't work over
>mod_ssl
>and apache.
>without ssl it works fine, also.
>I have set the TOMCAT_HOME and the JAVA_HOME... but it won't work
>Or isn't it fixed on TC3.2.2 ??
>When I install the two external classes from jdk jsse.jar and jnet.jar
>in tomcat/lib and start it with an environment variable like bleow (old
>bug #578 walkaround) it will work.
>The only thing that's gone is that I don't have to patch the
>HttpServletResponseFacade.java file out of
>tomcat/lib/webserver.jar...
>I've indeed tested this behavior with the standard class to test the
>sessiontracking whoch comes with tomcat.
>
>Greetings and thanks for inconvenience,
>Michael
>plz wrote back
>
>Marc Saegesser wrote:
>
> > A change very similar to what you propose for
>HttpServletResponseFacade.java
> > was already made for Tomcat 3.2.2b4.  There are two conditions that I
>know
> > of where URL rewritting won't work.  If you using AJP12 and an SSL
>port
> > other than 443 then Tomcat won't be told that the connection is secure
>and
> > will think that that the URL scheme is HTTP not HTTPS.
> > HttpServletResponseFacade checks that the scheme of the URL to be
>encoded
> > and the scheme of the current request are the same.  To encode an
>HTTPS url
> > you must be on an HTTPS request.  [Note:  I'm sure I really understand
>this
> > requirement, but its been this way for a long time.]
> >
> > So the two ways I know of for URL rewriting to fail are if you using
>AJP12
> > and SSL on something other than 443 or if your encoding an HTTPS URL
>during
> > an HTTP request.  Are either of these true for your case?
> >
> > To help diagnose this, could you access the SnoopServlet that comes
>with
> > Tomcat via your SSL connection and post the results.  This page will
> > indicate whether Tomcat thinks the request is secure or not, and if it
>
> > thinks the URL scheme is HTTPS.
> >
> > Thanks, we'll get this worked out.
> >
> > > -Original Message-
> > > From: Wolle [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, May 04, 2001 5:19 AM
> > > To: [EMAIL PROTECTED]; GOMEZ Henri
> > > Subject: Re: TC 3.2.2b4 URI Rewriting with mod_ssl
> > >
> > >
> > >
> > > Hello,
> > > sorry I just wake up ;-)
> > > Wolle wrote:
> > >
> > > > GOMEZ Henri wrote:
> > > >
> > > > > >That is a known Bug ,see
> > > > > >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=578
> > > > > >Marc has said, that he has fixed in the current release
> > > > > >TC3.2.2b4, but it
> > > > > >won't work.
> > > > > >What should I describe now ? The workaround was
> > > > >
> > > > > Fixed by costin in TC 3.3 since 01/04/22 11:56:03
> > > >
> > > > so I have all these things  in TC3.2.2b4, fill it be insert in
> > > TC3.2.2 final ?
> > >
> > > not fill -> new sentence
> > > so I have to do all these things in TC3.2.2b4, will it be
> > > completly insert in
> > > TC3.2.2 final ?
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > &g

Re: missing content-length from the header, Apache/Tomcat/AJP12 Connector spins out of control

[Rainer Jung]

Hi,

did you get any answers?

I would be very interested if anybody investigated your problem. If not 
consider logging a bug tu bugzilla.

Rainer Jung

At 18:33 20.05.01 , you wrote:

>Hi!
>
>it will be best if I describe our configuration at first:
>
>We are running Solaris 7, Tomcat 3.2.2 b4 (beta 4) + AJP12 Connector (Tomcat
>configured with max of 500 threads), JVM: Sun 1.3.0_02 Hot Spot Native
>Threads, Apache 1.3.19 (max of 1024 child processes)
>
>We have had substantial traffic on our server (we have 7 servers load
>balanced with the configuration specified above)
>
>We found that if the incoming HTTP request has content-length missing from
>the header, and the request gets channeled
>via the AJP12 connector to the Tomcat and the servlet, it appears that all
>subsequent request are causing AJP12 connections
>to raise (All in ESTABLISHED mode) and Tomcat refuses to process any more
>request , eventually eating up great deal of CPU time, we needed to do
>restart and both Apache and the Tomcat to recover from this condition.
>
>We have then decided to bypass all requests with the content-length missing
>in the Ajp12ConnectionHandler.java
>
> int contentLength = 
> reqA.getMimeHeaders().getIntHeader("content-length");
> if (contentLength != -1) {
> BufferedServletInputStream sis =
> (BufferedServletInputStream)reqA.getInputStream();
> sis.setLimit(contentLength);
> }
>+   else {
>+   resA.finish();
>+   socket.close();
>+   return;
>+   }
>
> contextM.service( reqA, resA );
> //resA.finish(); // is part of contextM !
> socket.close();
> } catch (Exception e) {
> // XXX
> // this isn't what we want, we want to log the problem somehow
> System.out.println("HANDLER THREAD PROBLEM: " + e);
> e.printStackTrace();
> }
>
>Note that in the above socket.close() is not executed when an exception is
>thrown in the service method
>
>we are considering adding a "finally" clause to handle such a case: i.e
>
> contextM.service( reqA, resA );
> //resA.finish(); // is part of contextM !
>-   socket.close();
> } catch (Exception e) {
> // XXX
> // this isn't what we want, we want to log the problem somehow
> System.out.println("HANDLER THREAD PROBLEM: " + e);
> e.printStackTrace();
> }
>+   } finally() {
>+   if (socket != null)
>+   socket.close();
>+   }
>
>
>-
>
>I believe that potential offending code could in the servlet application
>that tries to read input stream "request.getInputStream() without the
>content-length
>
>following is what the servlet code looks like:
>
>private int readInputStream(HttpServletRequest request) {
>
> int clientDayOfYear = 0;
>
> try {
> InputStreamReader isr=new
>InputStreamReader(request.getInputStream());
> BufferedReader br=new BufferedReader(isr);
> clientDayOfYear = new
>Integer(br.readLine().toString()).intValue();
> isr.close();
> isr=null;
> br.close();
> br=null;
> } catch (IOException e) {
> clientDayOfYear=0;
> }
> return clientDayOfYear;
> }
>
>
>We know that our change to the Tomcat code is temporary at best (it allows
>us to go on!) I am looking for the feedback
>on the "quality" of our code change as well as maybe to a deeper reasons why
>content-length missing from the header
>together with request.getInputStream() would cause Apache/AJP12 to have
>connections open (All in ESTABLISHED mode) and
>eventually eat up all available CPU resources
>
>Thanks for any feedback/help!
>

RE: 3.2.2b3 mod_jk gets stuck in readFully

[Rainer Jung]

If 100 is a constraint for the pool size, it should be stated in the Tomcat 
User's manual, since there it is explained how to increase the pool, but no 
max is given.

I observed Exceptions when using more than 100 threads in the pool, coming 
from one or two arrays which have fixed size 100 in the tomcat code.

I could not reproduce these errors after I updated from 3.2 to 3.2.2 and to 
3.3. Is there a reason, why I could stably use a bigger pool with these 
version? I put 240 concurrent requests on apache.

Which was the apache version you used, when the hang problem occured?

At 16:47 22.04.01 , you wrote:
>Two things.  First, the other problem that I was seeing turned out to be an
>Apache problem.  I switched to Apache 1.3.19 and my thread hang problems
>went away.  That problem seemed to be a synchronization thing that occurred
>if requests showed up too close together.
>
>As for the thread pool stuff.  By default, Tomcat 3.2.x thread pools create
>10 threads.  This can be changed using the min_spare_threads parameter.  The
>pools will grow as needed up to the maximum number of threads allowed (100,
>by default).  You can increase the maximum number of allowed threads using
>the max_threads parameter.  See if this fixes your problem better than using
>SimpleTcpConnector.
>
>
> > -Original Message-
> > From: Pogo Com [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, April 21, 2001 5:39 PM
> > To: Marc Saegesser; [EMAIL PROTECTED]
> > Subject: RE: 3.2.2b3 mod_jk gets stuck in readFully
> >
> >
> > After quite a bit of struggle, I think I found out what is going on.  The
> > problem is that the default configuration of Tomcat does not have enough
> > threads in its thread pool for the default configuration of Apache.  This
> > issue would only be apparent if many Apache children were in use.
> >
> > The result was that any Apache children over the number of Tomcat threads
> > would hang waiting for Tomcat to respond to requests.  Tomcat would not
> > respond until threads became available, which could be quite a
> > long time if
> > Apache children were not dying off (ie, because load was
> > increasing during the
> > day).
> >
> > I was wrong about the threads being stuck in readFully.  The real
> > problem is
> > that not enough threads existed at all (ie, the thread handling
> > socket accept
> > would be blocked).
> >
> > The simplest workaround is to change the AJP13 connector to
> > SimpleTcpConnector
> > rather than PoolTcpConnector in server.xml.
> >
> > I strongly suggest that thread pool exhaustion emit a log
> > message, since this
> > was quite difficult to track down.  Additionally, it would be
> > better for the
> > default configuration to be more robust.
> >
> > Bill
> >
> >
> >
> > --- Marc Saegesser <[EMAIL PROTECTED]> wrote:
> > > I finally got some time to look at this and I think I can duplicate the
> > > problem your seeing.  Hopefully, its the problem your seeing, or else we
> > > have two serious problems.
> >
> >
> > __
> > Do You Yahoo!?
> > Yahoo! Auctions - buy the things you want at great prices
> > http://auctions.yahoo.com/

Patch suggestions mod_jk/ajp13

[Rainer Jung]

Hello Henri,

I participated in the mod_jk fdatasync discussion on Friday. I have 4 more 
mod_jk/ajp13 patches on my personal wishlist. The first three (these are 
mod_jk patches) apply to 3.2.2 as well as to 3.3-milestone2. The fourth 
(which is the tomcat ajp13 patch)  is already fixed in 3.3, but not in 3.2.2.

I describe the four and add some diff-output for 3.2.2-beta2. I'm not an 
experienced Java/C-developper, so do not blindly use the code, although all 
patches are very small.

1) In jk_ajp12_worker.c the HTTP return reason phrase (the text that 
belongs to the numeric status, like "OK" for "200") is not handled correct. 
If the phrase consists of more than one token, like "Not Found", only the 
first token is read from tomcat and returned to the client. (change two 
lines, add 5 lines)

2) I suggest adding a timestamp to mod_jk-logging in jk_util.c. Logging 
without a timestamp is not very useful. (change 1 line, add 2 lines)

3) I think in jk_uri_worker_map.c is a little bug. For me it loggs (very 
rarely) "NULL parameters" and looking at the code I can see, that the two 
places are exactly those, where the code does not return before the log 
statement, even if it succesfully completes the call. All other places 
where "NULL parameters" could be logged first try to do something 
successful, if yes return, if no do logging. So I think one gets the 
logging although it should not have happened. (delete 4 lines, change 3 
lines, add 1 line)

4) In Ajp13ConnectorResponse.java the http reason phrase is missing in the 
returned status line. The change that has been done to tomcat 3.3 milestone 
2, and maybe could be added to 3.2.2 also. (change 1 line)

Maybe some of these could go into 3.2.2 or 3.3?

Thanks

Rainer

 jk_util.c_patch
 jk_ajp12_worker.c_patch
 jk_uri_worker_map.c_patch
 Ajp13ConnectorResponse.java_patch

kippdata informationstechnologie GmbH
Bornheimer Straße 33a
53111 Bonn

Tel.: 0228/98549-0
Fax:  0228/98549-50
email: [EMAIL PROTECTED]

Re: fdatasync in mod_jk

[Rainer Jung]

If my vote counts +1 since we saw how dramatic performance goes down.

As far as I can see from the Solaris documentation (and the system 
behaviour)  fdatasync really writes to the physical disk. It would be 
enough to flush file buffers to the file system (which will be cached in 
modern operating systems and the data will be visible to other processes 
looking at the file although it is not already physically on the disk). I 
think the file system is the right layer to use and the fflush call is 
already in the code right before the fdatasync.

Rainer Jung

At 15:34 20.04.01 , you wrote:
>I'm strongly to remove the fdatasync in mod_jk since :
>
>- it slow down too much Apache when running in DEBUG/TRACE mode
>- not very portable (not PORTABLE/FREEBSD/WIN32)
>
>-
>Henri Gomez ___[_]
>EMAIL : [EMAIL PROTECTED](. .)
>PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
>
>
> >-Original Message-
> >From: Arkadiusz Rychlinski [mailto:[EMAIL PROTECTED]]
> >Sent: Friday, April 20, 2001 8:53 AM
> >To: [EMAIL PROTECTED]
> >Subject: I made some changes in Tomcat's sources
> >
> >
> >I made some changes in (maybe not exacly) Tomcat's sources.
> >How can I make
> >it public?
> >
> >I've added support for encoding different than ISO-8859-1 in
> >form data from
> >GET/POST request and processing multipart forms and file upload.
> >
> >What should I do to present these changes to tomcat team?
> >
> >
> >
> >Arek
> >
> >
> >
> >

Logging Memory Leak 3.2.2-beta2

[Rainer Jung]

Hi!

I use tomcat 3.2.2-beta2 on Solaris 2.6 with JDK 1.2.2_06 and apache 1.3.14 
on a Sun E420R with 4 CPUs and 4GB Memory.

If I turn on verbosityLevel INFORMATION for JASPER_LOG in server.xml I can 
see a big memory leak. The leak does neither show up in version 3.2 nor 
does it appear when I use level WARNING:

Also the leak only appears when I stress test tomcat with more than 32 
threads. Up to 30 Client Threads are handled without a leak, somewhere 
between the 32nd and 34th client thread the leak starts.

After the leak appears I rapidly loose memory. If I give java as heap size 
513MB and use verbose:gc I can see the heap growing in minutes and finally 
the Garbage collection locks up:

GC[0] in 99 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[0] in 106 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[0] in 25 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[0] in 26 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[0] in 25 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[0] in 27 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[0] in 28 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[0] in 29 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[1] in 11622 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[0] in 129 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[0] in 99 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[0] in 24 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[0] in 25 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[0] in 25 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[0] in 22 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[1] in 12220 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[1] in 5479 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[1] in 9866 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[1] in 11792 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[1] in 11695 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[1] in 11869 ms: (512Mb, 0% free) -> (512Mb, 0% free)
GC[1] in 11572 ms: (512Mb, 0% free) -> (512Mb, 0% free)

Then essentially tomcat does no longer answer to requests.

In my simple test-JSP I set the session attribute to false in the page 
directive:

<%@ page session="false" %>


X




Any comments?

Sincerely

Rainer Jung


kippdata informationstechnologie GmbH
Bornheimer Straße 33a
53111 Bonn

Tel.: 0228/98549-0
Fax:  0228/98549-50
email: [EMAIL PROTECTED]