Re: Question: Strange Session Remove Attribute

[Remy Maucherat]

Peter Rossbach wrote:
Hmm,
but I can't find a statement that the valueUnbound get an invalid 
session, when it called after sessionDestoryed.

HttpSessionBindingListener ===
  /**
*
* Notifies the object that it is being unbound
* from a session and identifies the session.
*
* @param eventthe event that identifies
*the session
*   * @see #valueBound
*
*/
   public void valueUnbound(HttpSessionBindingEvent event);
  
I thing the part "identifies the session" is in conflict with the 
current tomcat implementation.
Interface HttpSessionBindingListener:
Causes an object to be notified when it is bound to or unbound from a 
session. The object is notified by an HttpSessionBindingEvent object. 
This may be as a result of a servlet programmer explicitly unbinding an 
attribute from a session, due to a session being invalidated, or due to 
a session timing out.

Today the user get a IllegalStateException at event.getSession().getId() 
instead the session identifier.
The current servlet spec is not clear at this session event definition. :(

What is correct?
-   current handling
-   emit remove session event and after this the session is invalid
-   remove emit event after invalidation
What we can do?
-   document the situation
   Add lifecycle diagrams ( state flow)
-propose a change to the spec team
Don't emit remove session attribute events, when session 
destoryed, like ServletContext and ServletRequest handling ( my favorit)
Only direct removeAttribute calls, emit remove event.
I give up ;)
Yes, the current behavior is certain to be the correct one.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Question: Strange Session Remove Attribute

[Peter Rossbach]

Hmm,
but I can't find a statement that the valueUnbound get an invalid 
session, when it called after sessionDestoryed.

HttpSessionBindingListener ===
  /**
*
* Notifies the object that it is being unbound
* from a session and identifies the session.
*
* @param eventthe event that identifies
*the session
*   
* @see #valueBound
*
*/

   public void valueUnbound(HttpSessionBindingEvent event);
  


I thing the part "identifies the session" is in conflict with the 
current tomcat implementation.

Today the user get a IllegalStateException at event.getSession().getId() 
instead the session identifier.
The current servlet spec is not clear at this session event definition. :(

What is correct?
-   current handling
-   emit remove session event and after this the session is invalid
-   remove emit event after invalidation
What we can do?
-   document the situation
   Add lifecycle diagrams ( state flow)
-propose a change to the spec team
Don't emit remove session attribute events, when session 
destoryed, like ServletContext and ServletRequest handling ( my favorit)
Only direct removeAttribute calls, emit remove event.

Peter
Remy Maucherat schrieb:
Peter Rossbach wrote:
Hups,
the remove session attribute events after session destory is 
documented at the servlet spec?
Any hint welcome

Yes, read the javadoc for HttpSessionBindingListener.
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: Question: Strange Session Remove Attribute

[Remy Maucherat]

Peter Rossbach wrote:
Hups,
the remove session attribute events after session destory is documented 
at the servlet spec?
Any hint welcome
Yes, read the javadoc for HttpSessionBindingListener.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Question: Strange Session Remove Attribute

[Peter Rossbach]

Hups,
the remove session attribute events after session destory is documented 
at the servlet spec?
Any hint welcome

Peter
Remy Maucherat schrieb:
Peter Rossbach wrote:
Good answer!
But why we emit remove session attribute events when sesssion is 
destroy?
I think the session expire is also a clean up thing and nobody need 
the remove attribute events.

Because the stupid wording which explicitely mandates the nonsense for 
sessions isn't present for context attributes ;)
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: Question: Strange Session Remove Attribute

[Remy Maucherat]

Peter Rossbach wrote:
Good answer!
But why we emit remove session attribute events when sesssion is destroy?
I think the session expire is also a clean up thing and nobody need the 
remove attribute events.
Because the stupid wording which explicitely mandates the nonsense for 
sessions isn't present for context attributes ;)
Rémy

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

Re: Question: Strange Session Remove Attribute

[Peter Rossbach]

Good answer!
But why we emit remove session attribute events when sesssion is destroy?
I think the session expire is also a clean up thing and nobody need the 
remove attribute events.

Peter
Remy Maucherat schrieb:
Peter Rossbach wrote:
Hey Remy,
can you please explain why the remove attribute event notification is 
wrong when
context is destroy?

Because you're not actually removing them, you're just cleaning up 
objects.
Did you notice you don't get notifications on start, etc ?

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: Question: Strange Session Remove Attribute

[Remy Maucherat]

Peter Rossbach wrote:
Hey Remy,
can you please explain why the remove attribute event notification is 
wrong when
context is destroy?
Because you're not actually removing them, you're just cleaning up objects.
Did you notice you don't get notifications on start, etc ?
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Question: Strange Session Remove Attribute

[Peter Rossbach]

Hey Remy,
can you please explain why the remove attribute event notification is 
wrong when
context is destroy?

Thanks
Peter
Remy Maucherat schrieb:
Peter Rossbach wrote:
Hmm,
I see the following problem with the current session expire strategie.
Today
   a) Notify session destroy event
 => All session attributes are active
   b) Set session as invalid
   c) Notify session remove attribute event - Hups
=> Now the listener detect IllegalStateExceptions
The session attribute listener in normal mode can access the session 
and this is very usefull
to monitoring the app behaviour. At expire session the listener have 
no chance to detect the
invalidation mode.

Now I see to chance to make better support for this case:
1)  add HttpSession.isValid() method
   => Very fine then also other code filter, and jsp can detect the 
Session invalidation.
2)  Add event methods to HttpSessionListener
   public void sessionDestroyed ( HttpSessionEvent se );
   public void sessionAfterDestroyed ( HttpSessionEvent se );
=> Second method emit after all attribute remove from session and now 
session is invalid ;-(

I vote for the first case, but this means wait for Servlet API 2.5.

Another problem I detect is at StandardContext listener event 
notification
   At listenerStop (L 3721)
  we remove the ApplicationEvent Listeners
<<
  setApplicationEventListeners(null);
  setApplicationLifecycleListeners(null);
 >>

but we need the Listener at
  StandardContext#clearAttributes => 
ApplicationContext#removeAttribute L695

=> Currently we don't emit removeAttribute Events when Context. stop.
Simple fix integrate clearAttributes at listenerStop before remove 
listeners.
OK?

No, it's not ok, it's wrong ;)
This came up recently, and caused problems.
=
Other thing is: that we don't emit remove request attribute events 
after ServletRequestListener was notify with requestDestory.
I can find this handling at 
org.apache.catalina.connector.Request.recycle
At L 391 we clear the attributes, but don't notify the request 
attribute listener.
Is this behaviour spec conform?
What is with request attributes that exist before or after request 
wrapper is active ( s. StandardContextValve#invoke)?
Must we have extra map for real application request attributes and 
another one for container side request attributes ?
  Sounds really strange :-)

This is also outside the application scope.
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: Question: Strange Session Remove Attribute

[Remy Maucherat]

Peter Rossbach wrote:
Hmm,
I see the following problem with the current session expire strategie.
Today
   a) Notify session destroy event
 => All session attributes are active
   b) Set session as invalid
   c) Notify session remove attribute event - Hups
=> Now the listener detect IllegalStateExceptions
The session attribute listener in normal mode can access the session and 
this is very usefull
to monitoring the app behaviour. At expire session the listener have no 
chance to detect the
invalidation mode.

Now I see to chance to make better support for this case:
1)  add HttpSession.isValid() method
   => Very fine then also other code filter, and jsp can detect the 
Session invalidation.
2)  Add event methods to HttpSessionListener
   public void sessionDestroyed ( HttpSessionEvent se );
   public void sessionAfterDestroyed ( HttpSessionEvent se );
=> Second method emit after all attribute remove from session and now 
session is invalid ;-(

I vote for the first case, but this means wait for Servlet API 2.5.

Another problem I detect is at StandardContext listener event notification
   At listenerStop (L 3721)
  we remove the ApplicationEvent Listeners
<<
  setApplicationEventListeners(null);
  setApplicationLifecycleListeners(null);
 >>
but we need the Listener at
  StandardContext#clearAttributes => 
ApplicationContext#removeAttribute L695

=> Currently we don't emit removeAttribute Events when Context. stop.
Simple fix integrate clearAttributes at listenerStop before remove 
listeners.
OK?
No, it's not ok, it's wrong ;)
This came up recently, and caused problems.
=
Other thing is: that we don't emit remove request attribute events after 
ServletRequestListener was notify with requestDestory.
I can find this handling at org.apache.catalina.connector.Request.recycle
At L 391 we clear the attributes, but don't notify the request 
attribute listener.
Is this behaviour spec conform?
What is with request attributes that exist before or after request 
wrapper is active ( s. StandardContextValve#invoke)?
Must we have extra map for real application request attributes and 
another one for container side request attributes ?
  Sounds really strange :-)
This is also outside the application scope.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Question: Strange Session Remove Attribute

[Peter Rossbach]

Hmm,
I see the following problem with the current session expire strategie.
Today
   a) Notify session destroy event
 => All session attributes are active
   b) Set session as invalid
   c) Notify session remove attribute event - Hups
=> Now the listener detect IllegalStateExceptions
The session attribute listener in normal mode can access the session and 
this is very usefull
to monitoring the app behaviour. At expire session the listener have no 
chance to detect the
invalidation mode.

Now I see to chance to make better support for this case:
1)  add HttpSession.isValid() method
   => Very fine then also other code filter, and jsp can detect the 
Session invalidation.
2)  Add event methods to HttpSessionListener
   public void sessionDestroyed ( HttpSessionEvent se );
   public void sessionAfterDestroyed ( HttpSessionEvent se );
=> Second method emit after all attribute remove from session and now 
session is invalid ;-(

I vote for the first case, but this means wait for Servlet API 2.5.

Another problem I detect is at StandardContext listener event notification
   At listenerStop (L 3721)
  we remove the ApplicationEvent Listeners
<<
  setApplicationEventListeners(null);
  setApplicationLifecycleListeners(null);
>>
but we need the Listener at
  StandardContext#clearAttributes => 
ApplicationContext#removeAttribute L695

=> Currently we don't emit removeAttribute Events when Context. stop.
Simple fix integrate clearAttributes at listenerStop before remove 
listeners.
OK?

=
Other thing is: that we don't emit remove request attribute events after 
ServletRequestListener was notify with requestDestory.
I can find this handling at org.apache.catalina.connector.Request.recycle
At L 391 we clear the attributes, but don't notify the request 
attribute listener.
Is this behaviour spec conform?
What is with request attributes that exist before or after request 
wrapper is active ( s. StandardContextValve#invoke)?
Must we have extra map for real application request attributes and 
another one for container side request attributes ?
  Sounds really strange :-)

Regards
Peter
Remy Maucherat schrieb:
Bill Barker wrote:
Hey
I have review the getIdInteral changes. At expire (StandardSession, 
DeltaSession) we send first the "SessionDestory events" and after 
this the "Remove Session Attribute" events. Before we send the 
remove attribute events the session set to invalid. Hmm: Why we do 
that? I have read the spec 2.4 but I can find a hint. With this 
handling nobody can access the getId without IllegalStateException 
in a HttpSessionBindingListener or HttpSessionAttributeListener! 
That I can't find this very nice?

What can I say, we needed to generate more BZ reports to mark as 
INVALID ;-).

The tester actually has example code of using getId in a 
HttpSessionAttributeListener to get an ISE.

Can anyone explain this session event handling?

There was just a long discussion of this.  For the details, check the 
list archives.  The short version is that it's mandated by section 
15.1.7 + Errata 
(http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/154errata.txt). 

(maybe I shouldn't have mentioned it, as Jan didn't appear to have 
noticed it before: I may have started the trouble ...)

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: Question: Strange Session Remove Attribute

[Remy Maucherat]

Bill Barker wrote:
Hey
I have review the getIdInteral changes. At expire (StandardSession, 
DeltaSession) we send first the "SessionDestory events" and after this 
the "Remove Session Attribute" events. Before we send the remove 
attribute events the session set to invalid. Hmm: Why we do that? I 
have read the spec 2.4 but I can find a hint. With this handling 
nobody can access the getId without IllegalStateException in a 
HttpSessionBindingListener or HttpSessionAttributeListener! That I 
can't find this very nice?
What can I say, we needed to generate more BZ reports to mark as INVALID 
;-).
The tester actually has example code of using getId in a 
HttpSessionAttributeListener to get an ISE.

Can anyone explain this session event handling?
There was just a long discussion of this.  For the details, check the 
list archives.  The short version is that it's mandated by section 
15.1.7 + Errata 
(http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/154errata.txt). 
(maybe I shouldn't have mentioned it, as Jan didn't appear to have 
noticed it before: I may have started the trouble ...)

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

Re: Question: Strange Session Remove Attribute

[Bill Barker]

- Original Message - 
From: "Peter Rossbach" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Sunday, April 03, 2005 5:04 AM
Subject: Question: Strange Session Remove Attribute


Hey
I have review the getIdInteral changes. At expire (StandardSession, 
DeltaSession) we send first the "SessionDestory events" and after this the 
"Remove Session Attribute" events. Before we send the remove attribute 
events the session set to invalid. Hmm: Why we do that? I have read the 
spec 2.4 but I can find a hint. With this handling nobody can access the 
getId without IllegalStateException in a HttpSessionBindingListener or 
HttpSessionAttributeListener! That I can't find this very nice?

What can I say, we needed to generate more BZ reports to mark as INVALID 
;-).

Can anyone explain this session event handling?
There was just a long discussion of this.  For the details, check the list 
archives.  The short version is that it's mandated by section 15.1.7 + 
Errata 
(http://jcp.org/aboutJava/communityprocess/maintenance/jsr154/154errata.txt).

regards
Peter

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


This message is intended only for the use of the person(s) listed above as 
the intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.

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

Re: Question about new mod_jk jk_lb_worker.c

[David Rees]

Rainer Jung wrote, On 11/16/2004 1:11 AM:
Unfortunately I don't understand. Trying to combine rotatelogs with 
mod_jk.log in the following way (apache 1.3):
Doh.  I've been using Apache 2 for so long I forgot that it doesn't work 
with Apache 1.3.  It does work using Apache 2 / mod_jk.

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

Re: Question about new mod_jk jk_lb_worker.c

[Mladen Turk]

Rainer Jung wrote:
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.
Of course it doesn't.
As said: "The only reasonable solution is to use the 'native'
logging and then use rotatelogs program.".
It means that it'll need to be done to support the native logger like
JK2 does. Seems like 1.2.8 feature to me, cause it's a lot backporting.
That way the request logging will go to access.log and error logging
to error.log, and youl'll be able to use rotatelogs on them.
MT.
-
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

[Mladen Turk]

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]

Re: Question about new mod_jk jk_lb_worker.c

[David Rees]

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]

Re: Question about new mod_jk jk_lb_worker.c

[Mladen Turk]

Rainer Jung wrote:
Hi Mladen,
0) Any ideas on rotating the mod_jk log file?
Implementing inside apache's error.log is
the only solution. But that'll have to wait
for 1.2.8.

Are the mathematically
foundations behind that simple algorithm described anywhere?

The idea behind this scheduler is the following:
lbfactor is "how much we expect this worker to work", or "the worker's
work quota".
lbstatus is "how urgent this worker has to work to fulfill its quota
of work".
We distribute each worker's work quota to the worker, and then look
which of them needs to work most urgently (biggest lbstatus).  This
worker is then selected for work, and its lbstatus reduced by the
total work quota we distributed to all workers.  Thus the sum of all
lbstatus does not change.(*)
If some workers are disabled, the others will
still be scheduled correctly.
If a balancer is configured as follows:
worker abcd
lbfactor  25   25   25   25
lbstatus   0000
And b gets disabled, the following schedule is produced:
lbstatus -500   25   25
lbstatus -250  -25   50
lbstatus   0000
(repeat)
That is it schedules: a c d a c d a c d ...
The following asymmetric configuration works as one would expect:
worker ab
lbfactor  70   30
lbstatus -30   30
lbstatus  40  -40
lbstatus  10  -10
lbstatus -20   20
lbstatus -50   50
lbstatus  20  -20
lbstatus -10   10
lbstatus -40   40
lbstatus  30  -30
lbasatus   00
(repeat)
That is after 10 schedules, the schedule repeats and 7 a are selected
with 3 b interspersed.


1) Limiting new application sessions if load is to high.
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).
Can you open a bugzilla report and enter those patches so they
don't get lost.
I very much like the idea and I have apache2 code for counting
busy workers:
int server_limit, thread_limit;
/* Get the number of busy workers from scoreboard */
static int jk_server_busy_workers()
{
int i, j, res;
int busy = 0;
worker_score *ws_record;
process_score *ps_record;
if (!ap_exists_scoreboard_image()) {
return 0;
}
for (i = 0; i < server_limit; ++i) {
ps_record = ap_get_scoreboard_process(i);
for (j = 0; j < thread_limit; ++j) {
int indx = (i * thread_limit) + j;
ws_record = ap_get_scoreboard_worker(i, j);
res = ws_record->status;
if (!ps_record->quiescing
&& ps_record->pid) {
if (res == SERVER_READY &&
res != SERVER_DEAD &&
res != SERVER_STARTING &&
res != SERVER_IDLE_KILL)
busy++;
}
}
}
return busy;
}
inside jk_post_config
+ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, &thread_limit);
+ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, &server_limit);

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):
You are running that on unix or windows?

a) In common/service.h in jk_worker define an additional JK_METHOD check
to be implemented by the workers:
Please, do another bugzilla entry for that.
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%205
Component: Native:JK
Severity: Enhancement
Thank's for the discussion!!
Thank you!
Regards,
Mladen
-
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

[Peter Rossbach]

Hello Mladen,
I have two use case for the Multi Cluster Routing:
Use Case 1: More Scaling cluster
=
A tomcat standard we replicated the session to all tomcat node at a cluster.
This replication strategie not scale very well, but when we split
the tomcat nodes to some domain  and the lb knows that, the system scale 
better.

   Apache 1
   domain and cluster 1
worker   w1.1 for T1.1
worker   w1.2 for T1.2
worker   w1.3 for T1.3
  domain and cluster 2
worker   w2.1 for T2.1
worker   w2.2 for T2.2
worker   w2.3 for T2.3
  When a worker w1 at domain 1 failed the  made the next try to w1.2 
and w1.3,
  only this worker fail also, the balancer give the w2.x worker a 
chance. Ok, the client
  lose the session but than you have really hardware problems...

Use Case 2: Switch smoothly to next software generation ( preferred domain)

Release a new software at runtime without drop the current user sessions.
Start complete new tomcat instances with new application release.
Say the Loadbalancer that all new sessions start to domain 2 workers,
but as you lost a worker at domain 1 (old release) switch to worker at 
same domain.

Apache 1
   domain and cluster 1  ( Software Release 1)
worker   w1.1 for T1.1
worker   w1.2 for T1.2
worker   w1.3 for T1.3
  domain and cluster 2 ( Software Release 2) - preferred
worker   w2.1 for T2.1
worker   w2.2 for T2.2
worker   w2.3 for T2.3
  Both use case work perfect with the mod_jk2 level concept, with a 
little patch.
  Only the level limit is a real problem for scaling well..

---
I check also the newest jk_lb_worker and it works fine for me...
The increment technic is simple and powerful :-)
Some examples
w1+ w2   lb_factor 1 lb_value 0
   values after calc
   request  |   w1   w2|  comment
   1   |0*   2   |w1 get the Session
   2   |0 0* |w2 get the Session
   3   |0 0* |w2 get the Session, w1 is in 
error state

w1 lb_factor 3 lb_value 0
w2 lb_factor 1 lb_value 0
  values after calc
   request   |  w1   w2   |comment
   1|   -1*   1| w1 get the Session
   2|   -2*   2| w1 get the Session
   3|   -3 3| w1 get the Session, w1 is 
first lb worker
   4|   0 0*| w2 get the Session
   5|   -1*   1| w1 get the Session
   6|   -1 0*  | w2 get the Session, w1 is in error
   7|   -1 0*  | w2 get the Session, w1 is in error
   7|   -1*   1| w1 get the Session, w1 recover

great.
regards
peter
Mladen Turk schrieb:
Rainer Jung wrote:
I include my original posting.
Hi Rainer,
First of all thank you for ideas.
They are great!
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.

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

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) 

This should work now with the latest patches.
Best 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

[Mladen Turk]

Rainer Jung wrote:
I include my original posting.
Hi Rainer,
First of all thank you for ideas.
They are great!
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.

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

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) 
This should work now with the latest patches.
Best regards,
Mladen.
-
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]

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 
at service() function ?
  After a longer fail the recovered worker get for a long time all 
new sessions...

OK. Will check. Seems very reasonable.
  See also Rainers Jung

Re: Question about new mod_jk jk_lb_worker.c

[Mladen Turk]

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 at 
service() function ?
  After a longer fail the recovered worker get for a long time all 
new sessions...
OK. Will check. Seems very reasonable.
  See also Rainers Jung mail
Can you forward that. Seems I can not find it.
b)   I have play around with the mod_jk2  lb algo and find the level 
feature (hot-standby) very usefull.
I'll have to check whether it will break something.
Some patch would be more then welcome :).
MT.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Question about the connection between Apache and Tomcat with JK

[Mladen Turk]

Kan Deng wrote:
MT,
Many thanks for the prompt reply. I read into the document, however,
didn't find the answer to my question as following,
3. If using sockets, jdk 1.4 has only socket for TCP and UDP. But when
the apache and tomcat are deployed in the same machine, isn't it an
overhead to go down to the lower layers when sending data stream, and
go upwards when receiving data?
Depends on the operating system itself.
The smart one will never go down to the physical network layer for local 
communications.

MT.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Question about the connection between Apache and Tomcat with JK

[Kan Deng]

MT,

Many thanks for the prompt reply. I read into the document, however,
didn't find the answer to my question as following,

3. If using sockets, jdk 1.4 has only socket for TCP and UDP. But when
the apache and tomcat are deployed in the same machine, isn't it an
overhead to go down to the lower layers when sending data stream, and
go upwards when receiving data?


Any hint?

Kan




On Thu, 23 Sep 2004 09:14:34 +0200, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Kan Deng wrote:
> > Hi, there,
> >
> > Apache is a C application while Tomcat is in pure Java. Would you
> > please complain the mechanism for the communication between these two?
> > Especially, does it use shared memory or a temporary file or sockets?
> >
> 
> It uses sockets and AJP13 protocol for communication.
> 
> >
> > Would you please give me a conceptual explanation or a pointer to some
> > documents, and in addition what classes in Tomcat source code handling
> > this IPC as well as the C modules of Apache?
> >
> 
> The best way to start is:
> http://jakarta.apache.org/tomcat/connectors-doc/jk2/index.html
> 
> Regards,
> MT.
> 
> 
> 
>

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

Re: Question about the connection between Apache and Tomcat with JK

[Mladen Turk]

Kan Deng wrote:
Hi, there, 

Apache is a C application while Tomcat is in pure Java. Would you
please complain the mechanism for the communication between these two?
Especially, does it use shared memory or a temporary file or sockets?
It uses sockets and AJP13 protocol for communication.
Would you please give me a conceptual explanation or a pointer to some
documents, and in addition what classes in Tomcat source code handling
this IPC as well as the C modules of Apache?
The best way to start is:
http://jakarta.apache.org/tomcat/connectors-doc/jk2/index.html
Regards,
MT.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Question about CVS tagging for a release

[Remy Maucherat]

Shapira, Yoav wrote:
Hi,
I notice the jakarta-servletapi-5 CVS module has tags up to tomcat
5.0.19, but not beyond (.20-.24).  Should I tag it for 5.0.25 and beyond
when I do releases?
Yes, it should be tagged with the others.
As far as I can see in my revision graph, it does have tags as well (but 
it likely didn't have any updates). So cool, I didn't screw up again :)

Actually, any codebase for which we include a "dev" version for whatever 
reason should be tagged. Currently, there's none (good :) ).

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

Re: Question on 5.0.23

[Remy Maucherat]

Costin Manolache wrote:
Remy Maucherat wrote:

Au menu:
- Using Embedded
- Using JMX (which I think is cool)
- Using the in-memory connector
Speaking of which, the in-memory connector might be good for a bare 
bones JNI connector, if someone wants to try. The current JK JNI has 
about the same overhead os a socket, so it could improve performance.
What do you mean by same overhead as a socket ?
If you remember, when I benched it (some time ago), it had about the 
same performance as a regular socket based AJP connection. It was 
slightly faster than socket on some configurations (with IIS, for 
example), but still significantly slower than the standalone connector. 
I still don't see where I made a mistake, but it would be good if 
someone tested this again.

It does go through the same marshaling process - because JNI has a huge 
cost on Strings and almost anything that requires allocation. But at 
least the current version should be a bit faster than TCP or unix domain.
That's quite possible, I don't know.

Rémy

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

Re: Question on 5.0.23

[Costin Manolache]

Remy Maucherat wrote:

Au menu:
- Using Embedded
- Using JMX (which I think is cool)
- Using the in-memory connector
Speaking of which, the in-memory connector might be good for a bare 
bones JNI connector, if someone wants to try. The current JK JNI has 
about the same overhead os a socket, so it could improve performance.
What do you mean by same overhead as a socket ?

It does go through the same marshaling process - because JNI has a huge 
cost on Strings and almost anything that requires allocation. But at 
least the current version should be a bit faster than TCP or unix domain.

Costin

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

Re: Question on 5.0.23

[Remy Maucherat]

Petr Jiricka wrote:
Remy Maucherat wrote:

Petr Jiricka wrote:

BTW, this isn't really relevant, but the in memory connector is now 
working (= no socket). The older TC 4.x could be invoked in memory as 
well, but the API was cumbersome.
I thought this could be useful in Netbeans (but last time, you weren't 
interested, apparently), and now it's actually a little bit tested.
We actually do use an embedded Tomcat in NetBeans. It's based on Tomcat 
3.2 ;-)

I must say we don't really feel the need to upgrade to a newer version, 
as our current integration works for what it need it for, plus the 
download size and memory footprint are really small.
Lol. It's quite slow though, you should use 3.3 ;)

(I really need to write a small docs page on embedding ...)
Well, if there is a simple and documented way to embed Tomcat in Java 
processes, then we may be interested :-) Thanks.
I think I'll write the docs :)

Au menu:
- Using Embedded
- Using JMX (which I think is cool)
- Using the in-memory connector
Speaking of which, the in-memory connector might be good for a bare 
bones JNI connector, if someone wants to try. The current JK JNI has 
about the same overhead os a socket, so it could improve performance.

Rémy

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

Re: Re: Question on 5.0.23 {Virus Engine Scanned}

[infected]

The SMEA web sever has detected virus(s) in your Email.
Please scan your email before resending.

The Mail was auto generated by the recepient's web host provider.



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

Re: Question on 5.0.23

[Petr Jiricka]

Remy Maucherat wrote:

Petr Jiricka wrote:

BTW, this isn't really relevant, but the in memory connector is now 
working (= no socket). The older TC 4.x could be invoked in memory as 
well, but the API was cumbersome.
I thought this could be useful in Netbeans (but last time, you weren't 
interested, apparently), and now it's actually a little bit tested.


We actually do use an embedded Tomcat in NetBeans. It's based on Tomcat 
3.2 ;-)

I must say we don't really feel the need to upgrade to a newer version, 
as our current integration works for what it need it for, plus the 
download size and memory footprint are really small.

(I really need to write a small docs page on embedding ...)


Well, if there is a simple and documented way to embed Tomcat in Java 
processes, then we may be interested :-) Thanks.

Petr

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: Question on 5.0.23

[Remy Maucherat]

Petr Jiricka wrote:

BTW, this isn't really relevant, but the in memory connector is now 
working (= no socket). The older TC 4.x could be invoked in memory as 
well, but the API was cumbersome.
I thought this could be useful in Netbeans (but last time, you weren't 
interested, apparently), and now it's actually a little bit tested.

(I really need to write a small docs page on embedding ...)

Rémy

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

Re: Question on 5.0.23

[Remy Maucherat]

Petr Jiricka wrote:
Well, this sounds quite alarming to me. Looks like there is no guarantee 
that the contents of the build really contains the intended codeline. 
If you are worried, you should make verifications. Get the source bundle 
and diff.

Rémy

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

Re: Question on 5.0.23

[Petr Jiricka]

Remy Maucherat wrote:

Shapira, Yoav wrote:

Hi,
I have a strange issue with 5.0.23 that's making me question my stable
vote from earlier today.  It has to do with a 3rd party servlet which
checks for the presence of a cookie, if not found prompts for some user
information, and then redirects (response.sendRedirect) to another page.
The exact same code base and test case works in 5.0.19 but not in
5.0.23.  Was something relevant changed?
Looking at the changelog, I'd like clarification on:
"Optimization: delay parsing of the cookies (remm)"
I'm running Sun JDK 1.4.2 on Solaris 8 (all patches installed).  As I
mentioned it works with tomcat 5.0.19.  I'll proceed to try the
intermediate builds 5.0.20, 5.0.21, and 5.0.22 to further narrow the
possibilities.  Thanks,


I did find what the problem was: I did some testing, so I checked out 
an earlier revision of the file (CoyoteRequest, of course). 
Unfortunately, I'm using a new CVS tool with which I have less 
experience (tortoise) - not that I wanted to, but WinCVS decided to 
simply stop working one day - which doesn't display tags in a visible 
way, and the result is that an older revision of the file is in the 
build :(

Well, this sounds quite alarming to me. Looks like there is no guarantee 
that the contents of the build really contains the intended codeline. 
Could some practices be established that would prevent such situation 
from happening?

For example:
- use command line CVS to check out sources for production builds
- for production builds, always do a clean check out (use an empty 
directory)
- write an Ant script that checks out sources for production build

Would this help?

Thanks
Petr
I'll have to do a new 5.0.24 build today, then.

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: Question on 5.0.23

[Remy Maucherat]

Kin-Man Chung wrote:
Which watchdog is it?  Can you send me the other part (tld and tag handler)
of it?
It's Watchdog 4. It's the XML tests (obviously), and it is run in the 
release target.

If the tag is of a TAGDEPENDENT body type, then its body is should not
be evaluated.  It used to be evaluated in XML syntax, which is wrong and
which is what the patch intend to fix.  If this is the case, then the
golden file for the watchdog test should be replaced.
This is the declaration for the tag:

  
  test
  tags.TestTag
  tags.TestTagExtraInfo
  tagdependent
  
test message.
  
  
toBrowser
false
  
  
att1
true
  
  
att2
false
  

So this looks tagdependent, and it's ok then. I think the other similar 
problems are the same. Thanks.

(surprise, no 5.0.25 then)
(I have to assume some people will complain)
Rémy

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

Re: Question on 5.0.23

[Kin-Man Chung]

Which watchdog is it?  Can you send me the other part (tld and tag handler)
of it?

If the tag is of a TAGDEPENDENT body type, then its body is should not
be evaluated.  It used to be evaluated in XML syntax, which is wrong and
which is what the patch intend to fix.  If this is the case, then the
golden file for the watchdog test should be replaced.

-Kin-man

> Date: Wed, 05 May 2004 02:26:32 +0200
> From: Remy Maucherat <[EMAIL PROTECTED]>
> Subject: Re: Question on 5.0.23
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> 
> I have some possible problems with Jasper and XML syntax. One example 
> from old watchdog:
> 
>  xmlns:jsp="http://java.sun.com/JSP/Page"; version="1.2"
> xmlns:direct="urn:jsptld:/WEB-INF/tlds/example-taglib.tld"
>  >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Generates for the tag:
> 
>  do {
>out.write("");
>out.write("\n");
>out.write("Validated\n");
>out.write("");
>out.write('\n');
>int evalDoAfterBody = _jspx_th_direct_test_0.doAfterBody();
>member = (String) _jspx_page_context.findAttribute("member");
>if (evalDoAfterBody != 
> javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN)
>  break;
>  } while (true);
> 
> So the tag body is not getting evaluated. I suspect this patch, which 
> was not yet present in 5.0.22:
> 
> kinman  2004/04/16 16:22:30
> 
>Modified:jasper2/src/share/org/apache/jasper/compiler
>  JspDocumentParser.java
>Log:
>- Fix a bug where a custom tag with tagdependent body type is not
>  handled correctly in XML syntax.  The fix would have been trivial 
> if not
>  for the cases where  and/or  is present.
> 
> I'm not too big on tags though, so I don't know for sure if it's even a bug.
> 
> (et hop, 5.0.25 ... :/ )
> 
> 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: Question on 5.0.23

[Remy Maucherat]

I have some possible problems with Jasper and XML syntax. One example 
from old watchdog:

http://java.sun.com/JSP/Page"; version="1.2"
xmlns:direct="urn:jsptld:/WEB-INF/tlds/example-taglib.tld"
>








Generates for the tag:

do {
  out.write("");
  out.write("\n");
  out.write("Validated\n");
  out.write("");
  out.write('\n');
  int evalDoAfterBody = _jspx_th_direct_test_0.doAfterBody();
  member = (String) _jspx_page_context.findAttribute("member");
  if (evalDoAfterBody != 
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN)
break;
} while (true);

So the tag body is not getting evaluated. I suspect this patch, which 
was not yet present in 5.0.22:

kinman  2004/04/16 16:22:30

  Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java
  Log:
  - Fix a bug where a custom tag with tagdependent body type is not
handled correctly in XML syntax.  The fix would have been trivial 
if not
for the cases where  and/or  is present.

I'm not too big on tags though, so I don't know for sure if it's even a bug.

(et hop, 5.0.25 ... :/ )

Rémy

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

RE: Question on 5.0.23

[Shapira, Yoav]

Hi,

>I don't like moving tags, so it's 5.0.24, and I picked up the right
>version for CoyoteRequest this time :-/

Downloaded and tested 5.0.24, it works fine.  You hit the nail right on
the head.  I'm ready to vote on it.  Thanks again,

Yoav Shapira



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]

Re: Question on 5.0.23

[Remy Maucherat]

Shapira, Yoav wrote:
Thanks.  Is it still 5.0.23 then, and I should re-download and retest?
I don't like moving tags, so it's 5.0.24, and I picked up the right 
version for CoyoteRequest this time :-/

Rémy

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

RE: Question on 5.0.23

[Shapira, Yoav]

Hi,

>I did update the build.

Thanks.  Is it still 5.0.23 then, and I should re-download and retest?

Yoav Shapira



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]

Re: Question on 5.0.23

[Remy Maucherat]

Shapira, Yoav wrote:
Thanks for the quick investigation and resolution.  ;)

I'm formally withdrawing my stable vote for 5.0.23 because of this bug.
I couldn't find 5.0.20-5.0.22 for download, but IIRC 5.0.22 worked fine.
I'll gladly test 5.0.24 as soon as it's available.  Thanks again,
I did update the build.

BTW, all past builds are available here: 
http://archive.apache.org/dist/jakarta/tomcat-5/

Rémy

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

RE: Question on 5.0.23

[Shapira, Yoav]

Hi,

>I did find what the problem was: I did some testing, so I checked out
an
>earlier revision of the file (CoyoteRequest, of course). Unfortunately,
>I'm using a new CVS tool with which I have less experience (tortoise) -
>not that I wanted to, but WinCVS decided to simply stop working one day
>- which doesn't display tags in a visible way, and the result is that
an
>older revision of the file is in the build :(
>
>I'll have to do a new 5.0.24 build today, then.

Thanks for the quick investigation and resolution.  ;)

I'm formally withdrawing my stable vote for 5.0.23 because of this bug.
I couldn't find 5.0.20-5.0.22 for download, but IIRC 5.0.22 worked fine.
I'll gladly test 5.0.24 as soon as it's available.  Thanks again,

Yoav Shapira



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]

Re: Question on 5.0.23

[Remy Maucherat]

Shapira, Yoav wrote:
Hi,
I have a strange issue with 5.0.23 that's making me question my stable
vote from earlier today.  It has to do with a 3rd party servlet which
checks for the presence of a cookie, if not found prompts for some user
information, and then redirects (response.sendRedirect) to another page.
The exact same code base and test case works in 5.0.19 but not in
5.0.23.  Was something relevant changed?
Looking at the changelog, I'd like clarification on:
"Optimization: delay parsing of the cookies (remm)"
I'm running Sun JDK 1.4.2 on Solaris 8 (all patches installed).  As I
mentioned it works with tomcat 5.0.19.  I'll proceed to try the
intermediate builds 5.0.20, 5.0.21, and 5.0.22 to further narrow the
possibilities.  Thanks,
I did find what the problem was: I did some testing, so I checked out an 
earlier revision of the file (CoyoteRequest, of course). Unfortunately, 
I'm using a new CVS tool with which I have less experience (tortoise) - 
not that I wanted to, but WinCVS decided to simply stop working one day 
- which doesn't display tags in a visible way, and the result is that an 
older revision of the file is in the build :(

I'll have to do a new 5.0.24 build today, then.

Rémy

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

Re: Question on 5.0.23

[Remy Maucherat]

Shapira, Yoav wrote:
Hi,
I have a strange issue with 5.0.23 that's making me question my stable
vote from earlier today.  It has to do with a 3rd party servlet which
checks for the presence of a cookie, if not found prompts for some user
information, and then redirects (response.sendRedirect) to another page.
The exact same code base and test case works in 5.0.19 but not in
5.0.23.  Was something relevant changed?
Looking at the changelog, I'd like clarification on:
"Optimization: delay parsing of the cookies (remm)"
The cookies are parsed (and allocated) when getCookies() is called.

I'm running Sun JDK 1.4.2 on Solaris 8 (all patches installed).  As I
mentioned it works with tomcat 5.0.19.  I'll proceed to try the
intermediate builds 5.0.20, 5.0.21, and 5.0.22 to further narrow the
possibilities.  Thanks,
Rémy

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

Re: Question about HttpServletRequest.getParameterValues()

[Jan Luehe]

Remy Maucherat wrote:
Jan Luehe wrote:

This is a bug. The String[] returned by req.getParameterValues() should
have been a clone.
I just committed a fix.


I'd like to point out that this "bug" is not worth any performance drop. 
You should move those clones to the case where there's a security manager.
Fair enough.

Jan



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

Re: Question about HttpServletRequest.getParameterValues()

[Remy Maucherat]

Jan Luehe wrote:
This is a bug. The String[] returned by req.getParameterValues() should
have been a clone.
I just committed a fix.
I'd like to point out that this "bug" is not worth any performance drop. 
You should move those clones to the case where there's a security manager.

Rémy

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

Re: Question about HttpServletRequest.getParameterValues()

[Jan Luehe]

Hi Christian,

The 2.3 HttpServletRequest interface provides a setAttribute() method to
change the values of a given attribute. It does NOT however provide a
similar setParameter() method, allowing you to programatically modify the
values that accompany the request - I assume this means that we shouldn't be
able to change these values.
What I've discovered however, is that if I _can_ modify parameter values by
calling getParameterValues() (which returns String[]) and set the values
that way. For instance:
Enumeration enum = req.getParameterNames();
while (enum.hasMoreElements()) {
String key =(String) enum.nextElement();
String vals[] = req.getParameterValues(key);
for (int i=0, max=vals.length; i
This has the surprising (to me anyway) effect of actually _modifying_ the
underlying value for the particular key. Is this simply an implementation
oversight? I had assumed that the method would be returning a copy of the
underlying data structure, rather than a reference to the structure itself.
This isn't really a problem for me, but I thought it was interesting and I'm
curious to know if this was intentional or not. Anyone care to comment?
This is a bug. The String[] returned by req.getParameterValues() should
have been a clone.
I just committed a fix.

Thanks,

Jan


Thanks much,
Christian
--
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
"Coffee? I could quit anytime, just not today"
-
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 a JCP proposition

[Eric Jung]

Hi Yoav,

Thanks for the replies. Beleive it or not, this request comes directly
from my attempts to extends commons-fileupload to support a progress bar.
I have spent a lot of time on this topic and can add a lot to the
discussions on commons-dev.

I would be very interested to see how the other two have done an
implementation
with commons-fileupload since I was not able to achieve one reliably
without
modifying some Tomcat classes (e.g:
org.apache.coyote.http11.InternalInputBuffer,
InternalOutputBuffer, Http11Processor).

I have checked the mail-archives.com but the posts aren't there yet...

Anxiously waiting,
Eric


On Tue, 23 Dec 2003 13:23:28 -0500, "Shapira, Yoav"
<[EMAIL PROTECTED]> said:
> 
> Howdy,
> 
> >> - It'd be hard for the container to support these listeners in a
> >> performant manner.
> >
> >Agreed. It would surely affect the i/o buffer size if set to a small
> >value.; in the case of Tomcat I believe this is
> >org.apache.coyote.http11.Constants.DEFAULT_HTTP_HEADER_BUFFER_SIZE
> (48k).
> >However, wouldn't prolific JavaDoc ameliorate that issue?
> 
> JavaDoc along with a default configuration that retains current
> performance might be OK.
> 
> >One use-case is to be able to provide an accurate upload or download
> >meter; I'm not aware of any way to do this with Servletsare you?
> >(Note I said "accurate", not something like an animated gif which is
> >just a fancy wait cursor).
> 
> It's funny you raise this point now.  We're discussing adding a progress
> bar to commons-fileupload on the commons-dev list.  You may wish to
> join/follow the discussion, as two other people have what they claim are
> accurate implementations.  Needless to say, neither of them is asking
> for a servlet specification change.
> 
> Do you have any other use cases?
> 
> Yoav Shapira
> 
> 
> 
> 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]
> 

-- 
http://www.fastmail.fm - Accessible with your email software
  or over the web

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

RE: Question about a JCP proposition

[Shapira, Yoav]

Howdy,

>> - It'd be hard for the container to support these listeners in a
>> performant manner.
>
>Agreed. It would surely affect the i/o buffer size if set to a small
>value.; in the case of Tomcat I believe this is
>org.apache.coyote.http11.Constants.DEFAULT_HTTP_HEADER_BUFFER_SIZE
(48k).
>However, wouldn't prolific JavaDoc ameliorate that issue?

JavaDoc along with a default configuration that retains current
performance might be OK.

>One use-case is to be able to provide an accurate upload or download
>meter; I'm not aware of any way to do this with Servletsare you?
>(Note I said "accurate", not something like an animated gif which is
>just a fancy wait cursor).

It's funny you raise this point now.  We're discussing adding a progress
bar to commons-fileupload on the commons-dev list.  You may wish to
join/follow the discussion, as two other people have what they claim are
accurate implementations.  Needless to say, neither of them is asking
for a servlet specification change.

Do you have any other use cases?

Yoav Shapira



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]

RE: Question about a JCP proposition

[Eric Jung]

> You must be in a big rush -- I just got the message, I figure others may
> have not even checked their mail yet ;)

I didn't post that "no answer?" message.

> It's too low-level for the spirit of the Servlet Specification,

That's discouraging.

> - It'd be hard for the container to support these listeners in a
> performant manner.

Agreed. It would surely affect the i/o buffer size if set to a small
value.; in the case of Tomcat I believe this is
org.apache.coyote.http11.Constants.DEFAULT_HTTP_HEADER_BUFFER_SIZE (48k).
However, wouldn't prolific JavaDoc ameliorate that issue?

> it much.  What's a realistic use-case?

One use-case is to be able to provide an accurate upload or download
meter; I'm not aware of any way to do this with Servletsare you?
(Note I said "accurate", not something like an animated gif which is
just a fancy wait cursor).



On Tue, 23 Dec 2003 08:43:36 -0500, "Shapira, Yoav"
<[EMAIL PROTECTED]> said:
> 
> Howdy,
> 
> >no answer??
> 
> You must be in a big rush -- I just got the message, I figure others may
> have not even checked their mail yet ;)
> 
> >There is currently no way in the Servlet spec to know the number
> >of bytes that have been read as a ServletRequest is being processed.
> >By the time Servlet.service() or Filter.doFilter() are called,
> >the *entire* InputStream has been read from the socket.
> >
> >But what if one is trying to implement certain behavior after every
> >n bytes have been consumed? There is presently no way to do this
> >without writing a custom Servlet Container (or extending Coyote).
> 
> I'm not a big fan of the request, for two reasons:
> - It's too low-level for the spirit of the Servlet Specification,
> - It'd be hard for the container to support these listeners in a
> performant manner.
> 
> The above are just IMHO, off the top of my head, without thinking about
> it much.  What's a realistic use-case?
> 
> As to your other question: I've never seen this request before.
> 
> Yoav Shapira
> 
> 
> 
> 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]
> 

-- 
http://www.fastmail.fm - mmm... Fastmail...

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

RE: Question about a JCP proposition

[Shapira, Yoav]

Howdy,

>no answer??

You must be in a big rush -- I just got the message, I figure others may
have not even checked their mail yet ;)

>There is currently no way in the Servlet spec to know the number
>of bytes that have been read as a ServletRequest is being processed.
>By the time Servlet.service() or Filter.doFilter() are called,
>the *entire* InputStream has been read from the socket.
>
>But what if one is trying to implement certain behavior after every
>n bytes have been consumed? There is presently no way to do this
>without writing a custom Servlet Container (or extending Coyote).

I'm not a big fan of the request, for two reasons:
- It's too low-level for the spirit of the Servlet Specification,
- It'd be hard for the container to support these listeners in a
performant manner.

The above are just IMHO, off the top of my head, without thinking about
it much.  What's a realistic use-case?

As to your other question: I've never seen this request before.

Yoav Shapira



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]

Re: Question about a JCP proposition

[mahadevan iyer]

no answer??

=
A.Mahadevan

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

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

Re: Question on Tomcat 4

[Eduardo Campoy]

Great News, and thanks a lot. 
But How do i implement this feature ?




Eduardo Campoy
Technology Account Manager
Novell, THE leading provider of net business solutions
Tel - 55 11 3345-3938
Cel - 55 11 9232-7456
AIM - ecampoy sao
MSN - [EMAIL PROTECTED]

>>> [EMAIL PROTECTED] 11/26/03 5:55 PM >>>
The "secureCookie" attribute was added to 3.3.2 only to allow backwards
compatibility with 3.3.1.  Like Tomcat 4 and higher, the default is
'true'.
It's a pretty small patch:
http://cvs.apache.org/viewcvs/jakarta-tomcat/src/share/org/apache/tomcat/mod
ules/session/SessionId.java.diff?r1=1.20&r2=1.21

if you just want to add the feature to 3.3.1.  Like Yoav said, TC 4 and
higher always uses secure cookies.

- Original Message -
From: "Shapira, Yoav" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 26, 2003 8:37 AM
Subject: RE: Question on Tomcat 4



Howdy,
Tomcat 4 and later are so different from 3.x.  I suggest you do the
migration, if only for the speed and feature increases.  I don't think
there's an "attribute" called "secureCookie" in tomcat4, as there is no
"un-secure" mode.  Perhaps a tomcat 3 guru like Senor Barker can fill in
more information...

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Eduardo Campoy [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, November 26, 2003 11:33 AM
>To: [EMAIL PROTECTED]
>Cc: Jason Rivard
>Subject: Question on Tomcat 4
>
>Hello,
>
>I am using Tomcat 3.3.1 with Internet Web Application and after doing a
>ETHICAL HACKING TEST, they discovered a problem in Tomcat session
cookie
>(JSESSIONID).
>After reading Tomcat 3.3.2 manual , there is a atribute called
>"secureCookie" that resolve my issue. BUT tomcat 3.3.2 is not released
>yet.
>My question is "Does this atribute called "secureCookie" exist in
>TOMCAT 4 ?"
>
>Thanks in advanced
>
>
>
>Eduardo Campoy
>Technology Account Manager
>Novell, THE leading provider of net business solutions
>Tel - 55 11 3345-3938
>Cel - 55 11 9232-7456
>AIM - ecampoy sao
>MSN - [EMAIL PROTECTED]




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: Question on Tomcat 4

[Bill Barker]

The "secureCookie" attribute was added to 3.3.2 only to allow backwards
compatibility with 3.3.1.  Like Tomcat 4 and higher, the default is 'true'.
It's a pretty small patch:
http://cvs.apache.org/viewcvs/jakarta-tomcat/src/share/org/apache/tomcat/mod
ules/session/SessionId.java.diff?r1=1.20&r2=1.21

if you just want to add the feature to 3.3.1.  Like Yoav said, TC 4 and
higher always uses secure cookies.

- Original Message -
From: "Shapira, Yoav" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 26, 2003 8:37 AM
Subject: RE: Question on Tomcat 4



Howdy,
Tomcat 4 and later are so different from 3.x.  I suggest you do the
migration, if only for the speed and feature increases.  I don't think
there's an "attribute" called "secureCookie" in tomcat4, as there is no
"un-secure" mode.  Perhaps a tomcat 3 guru like Senor Barker can fill in
more information...

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Eduardo Campoy [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, November 26, 2003 11:33 AM
>To: [EMAIL PROTECTED]
>Cc: Jason Rivard
>Subject: Question on Tomcat 4
>
>Hello,
>
>I am using Tomcat 3.3.1 with Internet Web Application and after doing a
>ETHICAL HACKING TEST, they discovered a problem in Tomcat session
cookie
>(JSESSIONID).
>After reading Tomcat 3.3.2 manual , there is a atribute called
>"secureCookie" that resolve my issue. BUT tomcat 3.3.2 is not released
>yet.
>My question is "Does this atribute called "secureCookie" exist in
>TOMCAT 4 ?"
>
>Thanks in advanced
>
>
>
>Eduardo Campoy
>Technology Account Manager
>Novell, THE leading provider of net business solutions
>Tel - 55 11 3345-3938
>Cel - 55 11 9232-7456
>AIM - ecampoy sao
>MSN - [EMAIL PROTECTED]




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]



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

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

RE: Question on Tomcat 4

[Shapira, Yoav]

Howdy,
Tomcat 4 and later are so different from 3.x.  I suggest you do the
migration, if only for the speed and feature increases.  I don't think
there's an "attribute" called "secureCookie" in tomcat4, as there is no
"un-secure" mode.  Perhaps a tomcat 3 guru like Senor Barker can fill in
more information...

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Eduardo Campoy [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, November 26, 2003 11:33 AM
>To: [EMAIL PROTECTED]
>Cc: Jason Rivard
>Subject: Question on Tomcat 4
>
>Hello,
>
>I am using Tomcat 3.3.1 with Internet Web Application and after doing a
>ETHICAL HACKING TEST, they discovered a problem in Tomcat session
cookie
>(JSESSIONID).
>After reading Tomcat 3.3.2 manual , there is a atribute called
>"secureCookie" that resolve my issue. BUT tomcat 3.3.2 is not released
>yet.
>My question is "Does this atribute called "secureCookie" exist in
>TOMCAT 4 ?"
>
>Thanks in advanced
>
>
>
>Eduardo Campoy
>Technology Account Manager
>Novell, THE leading provider of net business solutions
>Tel - 55 11 3345-3938
>Cel - 55 11 9232-7456
>AIM - ecampoy sao
>MSN - [EMAIL PROTECTED]




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]

Re: question on how to work IIS with Tomcat

[Martin Algesten]

tomcat-dev is for developing Tomcat. This question is a user question 
and should be directed to the tomcat-user list.

Martin

On Wednesday, July 16, 2003, at 04:38 PM, Dhar, Subhashish wrote:

Hello
  I try to configure the Tomcat in-process to work with IIS,I did all 
the configuration as suggested by Document, and restart IIS,The 
index.html page work, but the JSP and servlet didn't work .If I try to 
run jsp or servlet,the browser tell me to wait looking for the 
website. and then it display page not found. I have a question there 
are two uriworker.properties file one in "jk" directory and one in 
"auto" directory. I modified the one in "jk" directory. Am I doing the 
correct way? just wondering. I makes all the change in the 
worker.properties file as given in the document. but the jsp and 
servlet don't work unless I physically start Tomcat. I would 
appreciate if any one can help me and let me know where I am making 
mistake. I hope to hear from you soon.
Thanks
Best Regards
Subhashish Dhar
Purdue Pharma L .P
One Stamford Forum
Stamford, CT 06901-3431
Tel : 203-588-7469
[EMAIL PROTECTED]
www.purduepharma.com



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

[Bill Barker]

- Original Message -
From: "Cui Xiaojing-a13339" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, June 18, 2003 7:38 PM
Subject: Question about session


> Hello All,
>
> I have used <%@ page session="false" %> to set the page not to join
session, but when I use HttpSession session = request.getSession(false) to
get session, I still can get the session that created before. Do you think
it is a correct status? Why? Thanks.
>

Yes, this is the "correct status".  If you want to know why, either read the
JSP spec, or ask the question on the tomcat-users list.

> <%@ page session="false" %>
> <%
>   HttpSession session = request.getSession(false);
> %>
>
> Regards,
> Xiaojing
>
>
> -
> 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 duplication of secure property in RequestBase and HttpRequestBase

[John Sisson]

Thanks for the reply Tim, but I don't think my question was clear enough.

Both the RequestBase and HttpRequestBase classes have their own isSecure
instance variable and have their own setSecure() and isSecure() methods.
The code in both classes seems to do the same thing.  My question is, is
there any reason why the methods and instance variable are duplicated in the
HttpRequestBase class.  It seems that the code in HttpRequestBase relating
to the "secure" instance variable is not needed, as it is provided in its
superclass, RequestBase.

Thanks,

John

- Original Message -
From: "Tim Funk" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, January 26, 2003 2:28 AM
Subject: Re: Question about duplication of secure property in RequestBase
and HttpRequestBase


> org.apache.catalina.connector.RequestBase implements ServletRequest.
>
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/catalina/docs/api/org/apache
/catalina/connector/RequestBase.html
>
> And isSecure is part of the interface of ServletRequest.
>
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletReques
t.html#isSecure()
>
> -Tim
>
> John Sisson wrote:
> > Hi,
> >
> > I noticed that both org.apache.catalina.connector.RequestBase and
org.apache.catalina.connector.HttpRequestBase both have a "secure" instance
variable and the setSecure(bool) isSecure() methods.  Does anybody know the
reason for this?
> >
> > Thanks,
> >
> > John
> >
>
>
> --
> 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: Question about duplication of secure property in RequestBaseand HttpRequestBase

[Tim Funk]

org.apache.catalina.connector.RequestBase implements ServletRequest.
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/catalina/docs/api/org/apache/catalina/connector/RequestBase.html

And isSecure is part of the interface of ServletRequest.
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletRequest.html#isSecure()

-Tim

John Sisson wrote:

Hi,

I noticed that both org.apache.catalina.connector.RequestBase and org.apache.catalina.connector.HttpRequestBase both have a "secure" instance variable and the setSecure(bool) isSecure() methods.  Does anybody know the reason for this?

Thanks,

John




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

RE: Question about Internationalization

[iasandcb]

Hi,

I tested a GB2312-based JSP page on Tomcat 4.1.12, and it worked fine.
(The attached file).
It shows ni-hao-ma in simplified Chinese character system and the
response encoding, i.e. GB2312. The key point I'd like to make clear is
that encoding of a JSP page should keep up with that of response that
the page generates for the best delivery of content, in particular,
under non-latin-1 character sets.
This concept is actually introduced to JSP 2.0 spec explicitly with JSP
configuration feature. I believe localization issues will be smoothly
gone with Tomcat 5 and other containers compliant with JSP 2 style.
P.S. a tech-tip for page encoding: Dreamweaver helps adjust page
encoding to a specific character set, such as EUC-KR, and certainly
GB2312. (I did this with Dreamweaver MX although I use Windows XP Korean
version.)

-Original Message-
From: Steve Chai [mailto:[EMAIL PROTECTED]] 
Sent: Friday, September 27, 2002 2:11 AM
To: [EMAIL PROTECTED]
Subject: Question about Internationalization

Hi,

I am using Tomcat 4.1 now. I got the internationalization problem.
In my jsps, the charset is set to gb2312, which is for chinese, but the 
chinese character can not show up correctly.

These jsps are running very well in Tomcat 4.0.4. However after I did
the 
following replacement, they are also running well in Tomcat 4.1.

What I did is:

In Tomcat 4.1\common\lib folder, just simply replace jasper-compiler.jar

jasper-runtime.jar and servlet.jar with Tomcat 4.0.4 version's. Then it 
works well.

Is it a bug ? or I have to config something in Tomcat 4.1 for 
Internationalization.

Please give me feedback.

Thanks

Steve Cai





_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


--
To unsubscribe, e-mail:

For additional commands, e-mail:




test.jsp
Description: Binary data

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

Re: Question about Session in Tomcat 3.3 -- continued...

[Bill Barker]

Yes, it seems to be true that sessions are lost on reloading with
fullReload=true.  I don't think that the case of fullReload=false has been
tested much, so it is possible that there could be some strange bugs like in
3.2.x.

It looks like the best way to fix this (for the default fullReload=true
case) would be to add another hook to the API (e.g. copyContext(Context old,
Context new)).  This way, SimpleSessionStore could move the old sessions
into the new Context before they get destroyed.

Comments?

- Original Message -
From: "Hugh J. L." <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, August 12, 2002 5:50 AM
Subject: Question about Session in Tomcat 3.3 -- continued...


> I changed switch "fullReload" in ReloadInterceptor
> from true to false, and sessions are maintained
> through context reloading. (Of course, because the old
> context remains.) Is there any disadvantage if I set
> this way? Anyway fullReload=true is default setting.
>
> Thanks.
>
> Hugh
>
>
> __
> Do You Yahoo!?
> HotJobs - Search Thousands of New Jobs
> http://www.hotjobs.com
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

Re: Question about patch submission

[Martin van den Bemt]

Putting the patch in bugzilla makes it easier to track and cannot get
lost that way ;-)

Mvgr,
Martin

On Wed, 2002-07-03 at 01:10, Russ Trotter wrote:
> Hey all,
> 
>   Quick question about patch submission:  I submitted a patch a week or so ago 
> and was curious if it was even received or acknowledged or anything or simply 
> diverted to /dev/null.  If it was rejected is there any protocol for the 
> submitter getting notice or anything?
> 
> thx,
> russ
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 



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

Re: Question on JTC native/apache2.0 mod_jk.c

[costinm]

On Tue, 7 May 2002, Larry Isaacs wrote:

> #ifdef REUSE_WORKER

> I think it would be best to programmatically determine if
> "tpool" is usable to fetch a thread unique endpoint, and
> do something appropriate if it is not.  Before I go digging
> into Apache 2.0 code, I would appreciate any suggestions or
> words of wisdom that might speed the process.  Thanks.

I think it's better to just undefine REUSE_WORKER ( and/or 
remove the code ).

It is just a way to avoid few allocations and/or mutexes,
there is no proof that this has any effect on performance
( and it shouldn't - compared with the socket operations
this is nothing ).

Note that the endpoint will still be recycled - this is 
just to use per-thread data for the objects used in 
processing the request.


Costin


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

Re: Question about jsp/servlet performance

[Remy Maucherat]

> Hi,
>
> As i tested, the jsp/servlet performance of Tomcat 4.0
> is only 50%-70% of Tomcat 3.3. Can any expert tell me
> what causes it? Http processing, request mapping or
> something else? I may integrate Tomcat 4.0 into our
> system so I should be aware of its reason and possible
> ways to improve it.

You can try using Coyote HTTP/1.1 to replace the default HTTP/1.1 connector.
You can also try to use Jasper 2 intead of Jasper 1 (TC 3.3 has ways to get
around the performance problems in the Jasper servlet, and so doesn't need
the performance optimizations).
Also, you should disable the access log valve (enabled in Tomcat 4.0.x,
disabled in Tomcat 3.3 and Tomcat 4.1.x).

You can test the 4.1.0 build to get a better idea on performance using all
the changes mentioned above.

Remy


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

Re: Question: does Tomcat4 manage jsp/servlet threads?

[Craig R. McClanahan]

On Mon, 1 Apr 2002, Hugh J. L. wrote:

> Date: Mon, 1 Apr 2002 00:15:36 -0800 (PST)
> From: Hugh J. L. <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Question: does Tomcat4 manage jsp/servlet threads?
>
> Hi, everyone,
>
> I need some help on Tomcat 4 architecture. Does Tomcat
> 4 manage jsp/servlet threads? For example, can it
> report condition of those threads, stop dead thread
> and release resource, etc? And, does it use thread
> pool?
>

In the 4.0.x releases, there is an
org.apache.catalina.connector.http.HttpProcessor instance for each request
processing thread.  Requests are handed off by the HttpConnector instance
which does the socket accept calls.  The number of request processing
threads is managed by the minProcessors and maxProcessors configuration
properties.

The processor threads are recycled, so that's sort of a thread pool
(although the threads themselves are not stored in a separate thread
pool).

> Thanks. I have to know this before I have time to read
> its source code. :-(
>

That's too bad, because that is where all the answers are.  Check the
classes in the org.apache.catalina.connector.http package.

> Regards,
> Hugh
>

Craig


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

Re: Question on JServ - High Priority

[Bill Barker]

At http://jakarta.apache.org/tomcat/ there are documentation links on the
left side of the page.  Select the version you are using.

In the future, questions like this should be directed to
[EMAIL PROTECTED]
- Original Message -
From: "Samatha Sajja" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 02, 2001 10:27 AM
Subject: Question on JServ - High Priority


> Hi,
>
>   I have a question on Tomcat and JServ. Right now my application is
running
> with Apache  and JServ. I want to change JServ to Tomcat. Do you have any
> document on this? Like where to place jar files, html files,settings,
etc.,.
> I am searching on web since yesterday i couldn't find any document. It
would
> be great if you send me a document.
>
> Thanks in advance,
> Samatha
>


**

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

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

Re: Question on chunked responses.

[Remy Maucherat]

> > Well, after looking at the algorithm (and trying with a telnet), I think
> the
> > flag does the job. However, this is likely to be a capability which will
> be
> > going away when I rewrite the connector (since it adds complexity
without
> > adding anything useful - see below).
>
> After the 'allowChunking=false' flag, I still got chunked responses. I can
> make a simple test case if you would like that.

Sure.

I tried a normal request to a servlet which didn't set the content length,
and it worked as expected.

> > Chunking is not optional for HTTP/1.1 compliance. If you support
HTTP/1.1,
> > you have to support chunked encoding (it's quite easy to do, actually,
as
> > it's a very simple encoding).
> >
> > Remy
>
> The company I work for controls both the client and server. It is a
> worldwide network for message delivery.
> We have 3 web server constraints.
> - Support for HTTP 1.1.
> - Support for Keep-Alive.
> - We do not want chunked encoding. Streamed responses will have the
content
> length in the header.

If you have specific need about features, the best would be to modify an
existing connector.

Remy

Re: Question on chunked responses.

[Harmeet]

> Well, after looking at the algorithm (and trying with a telnet), I think
the
> flag does the job. However, this is likely to be a capability which will
be
> going away when I rewrite the connector (since it adds complexity without
> adding anything useful - see below).

After the 'allowChunking=false' flag, I still got chunked responses. I can
make a simple test case if you would like that.

>
> Chunking is not optional for HTTP/1.1 compliance. If you support HTTP/1.1,
> you have to support chunked encoding (it's quite easy to do, actually, as
> it's a very simple encoding).
>
> Remy

The company I work for controls both the client and server. It is a
worldwide network for message delivery.
We have 3 web server constraints.
- Support for HTTP 1.1.
- Support for Keep-Alive.
- We do not want chunked encoding. Streamed responses will have the content
length in the header.

While HTTP 1.1 Compilance includes handling Cunked Encoding, it is not
necessary for a HTTP 1.1 response to be have chunked encoding. It is the
latter that I want.

The closest I have come to is replacing code in

-  useChunking = (!response.isCommitted()
-  && response.getContentLength() == -1
-  && response.getStatus() !=
- HttpServletResponse.SC_NOT_MODIFIED);
+ useChunking = false;

This causes problems with static resources and some other problems. I have a
feeling that this is really bad to do. Also I do not want to mentain such a
patch.

If the flag for 'allowChunking' is removed would it be possible to suggest
how one can cleanly add an extension to disable chunking. It is a must have
for us. Are there things in the Servlets that we can do to turn of chunking
? Can a servlet tell the Web Server , not to return data in chunks.

Is there a way to turn off chunking cleanly in the present. Any idiom/hint
etc. would be very appreciated.

thanks,
Harmeet

Re: Question on chunked responses.

[Remy Maucherat]

> > You can use the HTTP/1.0 connector.
> >
> > Remy
>
> Unfortunatly I cannot. The application I have, requires HTTP 1.1 and
> Keep-Alive.
> HTTP 1.0 is not an option. However the client side libraries do not handle
> chunked encoding. So I am a bit stuck.
> Any help with turning off chunked encoding with HTTP 1.1 Connector would
be
> very valuable to us.

Well, after looking at the algorithm (and trying with a telnet), I think the
flag does the job. However, this is likely to be a capability which will be
going away when I rewrite the connector (since it adds complexity without
adding anything useful - see below).

Chunking is not optional for HTTP/1.1 compliance. If you support HTTP/1.1,
you have to support chunked encoding (it's quite easy to do, actually, as
it's a very simple encoding).

Remy

Re: Question on chunked responses.

[Harmeet]

> You can use the HTTP/1.0 connector.
>
> Remy

Unfortunatly I cannot. The application I have, requires HTTP 1.1 and
Keep-Alive.
HTTP 1.0 is not an option. However the client side libraries do not handle
chunked encoding. So I am a bit stuck.
Any help with turning off chunked encoding with HTTP 1.1 Connector would be
very valuable to us.

thanks,
Harmeet

Re: Question on chunked responses.

[Remy Maucherat]

> Is there a way to completly disable chunking ?
> I have set allowChunking="false" in server.xml
> 
> but  may still turn chunking on for
> individual requests
> 
> It has this code
> useChunking = (!response.isCommitted()
>  && response.getContentLength() == -1
>  && response.getStatus() !=
> HttpServletResponse.SC_NOT_MODIFIED);
> 
> Is there a way I can turn off chunking for all requests.
> 
> I am using Tomcat 4.0B7 and HTTP 1.1 connector.

You can use the HTTP/1.0 connector.

Remy

RE: Question on HTTPConnector.

[mettu . kumar]

Deacon,

As I mentioned in my ealier mail, setting maxProcessors to -ve values doesn't 
really mean unlimited  max processors as there is not code to do the same(Though 
comments in the code says -ve value indicates unlimited). 

kumar.

-Original Message-
From: Deacon Marcus [mailto:[EMAIL PROTECTED]]
Sent: Sunday, July 08, 2001 7:34 AM
To: [EMAIL PROTECTED]
Subject: RE: Question on HTTPConnector.


Hi,

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, July 08, 2001 2:45 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Question on HTTPConnector.
>
>
> On Sat, 7 Jul 2001 [EMAIL PROTECTED] wrote:
>
> >
> > Looking at org.apache.catalina.connector.http.HTTPConnector I got a
> > question regarding the way its implemented.(I am looking at 4.0b3 src)
> >
> >
> > Look at this block of code(in run method of HTTPConnector):
> > // Hand this socket off to an appropriate processor
> > HttpProcessor processor = createProcessor();
> > if (processor == null) {
> > try {
> > log(sm.getString("httpConnector.noProcessor"));
> > socket.close();
> > } catch (IOException e) {
> > ;
> > }
> > continue;
> > }
> >
> > As per my understanding if no. of HTTPConnections == maxProcessors(
> > parameter in server.xml), when a new HTTPRequest comes server just
> > closes the Socket with any wait period.
>
> Yes, that's exactly what happens.
>
> > Isn't this Bad? In cases where
> > Load suddenly increases this could cause problems.
> >
>
> Well yes, it's bad, but so will any other reaction.  What choices are
> there in handling it?
>
> (1) Current behavior of closing the connection and go back to
> accepting new connections (causes a client-side protocol error)

The best option in my opinion.

> (2) Pause and try again in a bit (but in the mean time, this
> thread cannot accept any new connections, so they stack up
> inside the server socket up to acceptCount and then start
> getting refused)

Now that's BAD :(

> (3) Ignore the maxProcessors parameter and create a new processor (and
> its associated thread) anyway (can lead to denial of service attacks)

We have maxProcessors so site owner can - and should - tune this himself, if
he really wants (3) he can just set -1.

> Have you a suggestion on how we might deal with this more effectively?
>
> The real key is to configure maxProcessors to the maximum number of
> simultaneous requests you want your server to handle, based on the
> hardware capabilities and the processing requirements of your
> application.  For example, if your response time starts going through the
> roof once you exceed N simultaneous requests (because you've encountered
> some sort of bottleneck), it doesn't make sense to set maxProcessors
> higher than N -- that will just cause response times to slow down for
> everyone.
>
> >
> > Any info on this is greatly appreciated.
> >
> > Thanks,
> > Kumar.
> >
>
> Craig
>

Greetings,
 deacon Marcus

RE: Question on HTTPConnector.

[Deacon Marcus]

Hi,

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, July 08, 2001 2:45 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Question on HTTPConnector.
>
>
> On Sat, 7 Jul 2001 [EMAIL PROTECTED] wrote:
>
> >
> > Looking at org.apache.catalina.connector.http.HTTPConnector I got a
> > question regarding the way its implemented.(I am looking at 4.0b3 src)
> >
> >
> > Look at this block of code(in run method of HTTPConnector):
> > // Hand this socket off to an appropriate processor
> > HttpProcessor processor = createProcessor();
> > if (processor == null) {
> > try {
> > log(sm.getString("httpConnector.noProcessor"));
> > socket.close();
> > } catch (IOException e) {
> > ;
> > }
> > continue;
> > }
> >
> > As per my understanding if no. of HTTPConnections == maxProcessors(
> > parameter in server.xml), when a new HTTPRequest comes server just
> > closes the Socket with any wait period.
>
> Yes, that's exactly what happens.
>
> > Isn't this Bad? In cases where
> > Load suddenly increases this could cause problems.
> >
>
> Well yes, it's bad, but so will any other reaction.  What choices are
> there in handling it?
>
> (1) Current behavior of closing the connection and go back to
> accepting new connections (causes a client-side protocol error)

The best option in my opinion.

> (2) Pause and try again in a bit (but in the mean time, this
> thread cannot accept any new connections, so they stack up
> inside the server socket up to acceptCount and then start
> getting refused)

Now that's BAD :(

> (3) Ignore the maxProcessors parameter and create a new processor (and
> its associated thread) anyway (can lead to denial of service attacks)

We have maxProcessors so site owner can - and should - tune this himself, if
he really wants (3) he can just set -1.

> Have you a suggestion on how we might deal with this more effectively?
>
> The real key is to configure maxProcessors to the maximum number of
> simultaneous requests you want your server to handle, based on the
> hardware capabilities and the processing requirements of your
> application.  For example, if your response time starts going through the
> roof once you exceed N simultaneous requests (because you've encountered
> some sort of bottleneck), it doesn't make sense to set maxProcessors
> higher than N -- that will just cause response times to slow down for
> everyone.
>
> >
> > Any info on this is greatly appreciated.
> >
> > Thanks,
> > Kumar.
> >
>
> Craig
>

Greetings,
 deacon Marcus

RE: Question on HTTPConnector.

[mettu . kumar]

Craig,

Thanks for clarification. I do agree with you given the three options the one 
choosen by tomcat group is the best one(Option one).
But there need to be an option for tomcat users to use option 3 in case where 
DOS issues are solved by some other means (ex: using a switch which does the same).
HttpConnector.java has following lines:
/**
 * The maximum number of processors allowed, or <0 for unlimited.
 */
private int maxProcessors = 20;

Which gives an impression if maxProcessors  is set to a -ve value in server.xml 
unlimited option is used. But this is not implemented. 
A way to test this is set minProcessors="0" maxProcessors="-1". You will notice that 
server is not responding for request.


Kumar.


-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 07, 2001 5:45 PM
To: [EMAIL PROTECTED]
Subject: Re: Question on HTTPConnector.




On Sat, 7 Jul 2001 [EMAIL PROTECTED] wrote:

> 
> Looking at org.apache.catalina.connector.http.HTTPConnector I got a
> question regarding the way its implemented.(I am looking at 4.0b3 src)
> 
> 
> Look at this block of code(in run method of HTTPConnector):
>   // Hand this socket off to an appropriate processor
>   HttpProcessor processor = createProcessor();
>   if (processor == null) {
>   try {
>   log(sm.getString("httpConnector.noProcessor"));
>   socket.close();
>   } catch (IOException e) {
>   ;
>   }
>   continue;
>   }
> 
> As per my understanding if no. of HTTPConnections == maxProcessors(
> parameter in server.xml), when a new HTTPRequest comes server just
> closes the Socket with any wait period.

Yes, that's exactly what happens.

> Isn't this Bad? In cases where
> Load suddenly increases this could cause problems.
> 

Well yes, it's bad, but so will any other reaction.  What choices are
there in handling it?

(1) Current behavior of closing the connection and go back to
accepting new connections (causes a client-side protocol error)

(2) Pause and try again in a bit (but in the mean time, this
thread cannot accept any new connections, so they stack up
inside the server socket up to acceptCount and then start
getting refused)

(3) Ignore the maxProcessors parameter and create a new processor (and
its associated thread) anyway (can lead to denial of service attacks)

Have you a suggestion on how we might deal with this more effectively?

The real key is to configure maxProcessors to the maximum number of
simultaneous requests you want your server to handle, based on the
hardware capabilities and the processing requirements of your
application.  For example, if your response time starts going through the
roof once you exceed N simultaneous requests (because you've encountered
some sort of bottleneck), it doesn't make sense to set maxProcessors
higher than N -- that will just cause response times to slow down for
everyone.

> 
> Any info on this is greatly appreciated.
> 
> Thanks,
> Kumar.
> 

Craig

RE: Question on HTTPConnector.

[mettu . kumar]

Donald,

I believe this is logged. See the following lines of code:
if (processor == null) {
try {
log(sm.getString("httpConnector.noProcessor"));
socket.close();
} catch (IOException e) {
;
}

Kumar.  


-Original Message-
From: Donald Ball [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 07, 2001 7:16 PM
To: [EMAIL PROTECTED]
Subject: Re: Question on HTTPConnector.


On Sat, 7 Jul 2001, Craig R. McClanahan wrote:

> Well yes, it's bad, but so will any other reaction.  What choices are
> there in handling it?
>
> (1) Current behavior of closing the connection and go back to
> accepting new connections (causes a client-side protocol error)
>
> (2) Pause and try again in a bit (but in the mean time, this
> thread cannot accept any new connections, so they stack up
> inside the server socket up to acceptCount and then start
> getting refused)
>
> (3) Ignore the maxProcessors parameter and create a new processor (and
> its associated thread) anyway (can lead to denial of service attacks)
>
> Have you a suggestion on how we might deal with this more effectively?

shouldn't this event be logged? it would be nice if this happened too
frequently for a warning to be sent to the server's administrator.

- donald

Re: Question on HTTPConnector.

[Donald Ball]

On Sat, 7 Jul 2001, Craig R. McClanahan wrote:

> Well yes, it's bad, but so will any other reaction.  What choices are
> there in handling it?
>
> (1) Current behavior of closing the connection and go back to
> accepting new connections (causes a client-side protocol error)
>
> (2) Pause and try again in a bit (but in the mean time, this
> thread cannot accept any new connections, so they stack up
> inside the server socket up to acceptCount and then start
> getting refused)
>
> (3) Ignore the maxProcessors parameter and create a new processor (and
> its associated thread) anyway (can lead to denial of service attacks)
>
> Have you a suggestion on how we might deal with this more effectively?

shouldn't this event be logged? it would be nice if this happened too
frequently for a warning to be sent to the server's administrator.

- donald

Re: Question on HTTPConnector.

[Craig R. McClanahan]

On Sat, 7 Jul 2001 [EMAIL PROTECTED] wrote:

> 
> Looking at org.apache.catalina.connector.http.HTTPConnector I got a
> question regarding the way its implemented.(I am looking at 4.0b3 src)
> 
> 
> Look at this block of code(in run method of HTTPConnector):
>   // Hand this socket off to an appropriate processor
>   HttpProcessor processor = createProcessor();
>   if (processor == null) {
>   try {
>   log(sm.getString("httpConnector.noProcessor"));
>   socket.close();
>   } catch (IOException e) {
>   ;
>   }
>   continue;
>   }
> 
> As per my understanding if no. of HTTPConnections == maxProcessors(
> parameter in server.xml), when a new HTTPRequest comes server just
> closes the Socket with any wait period.

Yes, that's exactly what happens.

> Isn't this Bad? In cases where
> Load suddenly increases this could cause problems.
> 

Well yes, it's bad, but so will any other reaction.  What choices are
there in handling it?

(1) Current behavior of closing the connection and go back to
accepting new connections (causes a client-side protocol error)

(2) Pause and try again in a bit (but in the mean time, this
thread cannot accept any new connections, so they stack up
inside the server socket up to acceptCount and then start
getting refused)

(3) Ignore the maxProcessors parameter and create a new processor (and
its associated thread) anyway (can lead to denial of service attacks)

Have you a suggestion on how we might deal with this more effectively?

The real key is to configure maxProcessors to the maximum number of
simultaneous requests you want your server to handle, based on the
hardware capabilities and the processing requirements of your
application.  For example, if your response time starts going through the
roof once you exceed N simultaneous requests (because you've encountered
some sort of bottleneck), it doesn't make sense to set maxProcessors
higher than N -- that will just cause response times to slow down for
everyone.

> 
> Any info on this is greatly appreciated.
> 
> Thanks,
> Kumar.
> 

Craig

Re: question about the reloading of servlet

[Mike Anderson]

There was a problem with the reload code on 3.2.2.  Since reloading
has been rewritten for 3.3, you can try that or you can get the latest
source from the tomcat_32 branch and use it.  The fix is in 
org.apache.tomcat.core.ServletWrapper.java if you just want the one
file.

>>> [EMAIL PROTECTED] 06/25/01 09:51AM >>>
hello,

I have Tomcat 3.2.2, Apache 1.3.19 and mod_jk.

One of my user is currently developing a servlet, and
change very frequently this one.

from times to times, Tomcat stops reloading it, and I have
to restart it. Is it normal ? Why does he stop reloading ?

I have read numerous posts on this subject, including ones
telling that the reloading of servlet is difficult, since the
classes are loaded into a JVM, which doesn't accept easily
to change a loaded class into memory...

So, my question is:
Will the reloading working well in future versions of Tomcat
(should I try catalina ?), or should I suggest another way of
developing servlet to my user ?

Thanks a lot

__
| Henri Delebecque[EMAIL PROTECTED] |
| Webmaster   |
| Supelec  Tel (33)  01.69.85.14.91   |
| 3 rue Joliot-Curie  |
| Plateau de Moulon Fax:(33) 01.69.85.12.34   |
| 91190 Gif sur Yvette|
| FRANCE  |
|_|

Re: question about the reloading of servlet

[Craig R. McClanahan]

On Mon, 25 Jun 2001, Henri Delebecque wrote:

> hello,
> 
> I have Tomcat 3.2.2, Apache 1.3.19 and mod_jk.
> 
> One of my user is currently developing a servlet, and
> change very frequently this one.
> 
> from times to times, Tomcat stops reloading it, and I have
> to restart it. Is it normal ? Why does he stop reloading ?
> 
> I have read numerous posts on this subject, including ones
> telling that the reloading of servlet is difficult, since the
> classes are loaded into a JVM, which doesn't accept easily
> to change a loaded class into memory...
> 
> So, my question is:
> Will the reloading working well in future versions of Tomcat
> (should I try catalina ?), or should I suggest another way of
> developing servlet to my user ?
> 

Class reloading works differently in Tomcat 4.0 than in Tomcat 3.2.  In
particular, it is implemented by a background thread looking at changes in
*any* class that has already been loaded, where Tomcat 3.2 checks as a
request is procesed (which normally catches changes to the servlet class
itself, but doesn't always catch changes to bean classes).

> Thanks a lot
> 

Craig McClanahan


> __
> | Henri Delebecque[EMAIL PROTECTED] |
> | Webmaster   |
> | Supelec  Tel (33)  01.69.85.14.91   |
> | 3 rue Joliot-Curie  |
> | Plateau de Moulon Fax:(33) 01.69.85.12.34   |
> | 91190 Gif sur Yvette|
> | FRANCE  |
> |_|
> 
> 
> 

Re: Signing releases [was Re: question]

[Shane_Curcuru]

I'm not a security expert, but I *think* xml-xalan does it correctly.

- Several Xalan committers have PGP keys (including a joint one called
'Lotusxsl team').  You can use a freeware PGP version
(http://www.pgp.com/products/freeware/default.asp), buy a license, or
probably use a GPG version instead (http://www.gnupg.org/).

- We published the public halves of our keys to a well-known public
keyserver, so other people have an independent way to get our keys.

- We exported our public keys into an ascii file called KEYS in our CVS
repository  xml-xalan/java/KEYS

- Our Ant build script copies this KEYS file into the root of our
distribution, which then gets .zip'd and .tar.gz'd.  This is important!

- When shipping a release, we sign the actual .tar.gz/.zip files before
posting to xml.apache.org - we also post the .sig files for each distro as
well

- When a user downloads a release, they should download the .sig file too.
Then can then use PGP/GPG to verify the signature on the distro is still
valid.  Then can also check that the signature matches one of the keys that
was shipped inside the distro in the KEYS file.  They could also go to
well-known public keyservers and check for keys there.  The truly paranoid
could ask on xalan-dev for the actual signer to confirm their key's
fingerprint, etc. but I haven't met many people that paranoid yet.

Comments on better ways to do this appreciated.  Release security and
authenticity should definitely be an issue for each PMC to decide and then
report on to the ASF, since our released code is a lot of our reputation.
Sounds like PGP/GPG is already used in a number of projects, and is a very
widely used product, so perhaps that can just be the apache standard.

- Shane
 you "Marc Saegesser" <[EMAIL PROTECTED]> wrote 

Subject:  Signing releases [was Re: question]

I've checked the Tomcat 3.2.2b5 distribution and it looks OK.

Regarding signing the releases.  Could someone describe the procedures use
by other Apache projects for signing their releases?  Tomcat 3.2.2 will
going out in the near future and I would like to have a signing mechanism
in
place prior to that.

Re: Signing releases [was Re: question]

[Ben Hyde]

Marc Saegesser wrote:
 > Regarding signing the releases.  Could someone describe the procedures use
 > by other Apache projects for signing their releases?  Tomcat 3.2.2 will
 > going out in the near future and I would like to have a signing mechanism in
 > place prior to that.

Step #16 in http://dev.apache.org/how-to-release.html

RE: Signing releases [was Re: question]

[Larry Isaacs]

FWIW: I have checked the Tomcat 3.3 Milestone 3 distribution
and all files match the originals I have locally.

Larry

> -Original Message-
> From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 24, 2001 12:59 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Signing releases [was Re: question]
> 
> 
> I've checked the Tomcat 3.2.2b5 distribution and it looks OK.
> 
> Regarding signing the releases.  Could someone describe the 
> procedures use
> by other Apache projects for signing their releases?  Tomcat 
> 3.2.2 will
> going out in the near future and I would like to have a 
> signing mechanism in
> place prior to that.
> 
> > -Original Message-
> > From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, May 24, 2001 11:20 AM
> > To: Jon Stevens; Brian Behlendorf
> > Cc: [EMAIL PROTECTED]; tomcat-dev
> > Subject: Re: question
> >
> >
> > Jon Stevens at [EMAIL PROTECTED] wrote:
> > >
> > > WHAT?? I don't think that there should be .sea files there!
> > >
> > > .sea is a MacOS Stuffit Archive.
> > >
> > > Also, the .war files are == .jar files which are equal to .zip
> > files. They
> > > are auto "uncompressed" by the servlet engine when it 
> starts up. So, the
> > > file will probably be located in the ROOT.war.
> > >
> > > We really should take all of our distributions offline ASAP.
> >
> > Hold it hold it hold it... I made the SEA of Tomcat 3.2.1 
> to work with
> > Apple's MRJ on MacOS 8.6-9.1... (And it works!)
> >
> > >> This *looks* like a false alarm.  Ask him for an md5 of 
> the tarball he
> > >> downloaded, as well as where he downloaded it from.  You guys
> > might want
> > >> to consider signing your releases at some point, too.
> > >
> > > This is a project by project thing to do. Most of the 
> projects do it
> > > correctly.
> >
> > Might want to enforce it from a PMC standpoint?? :)
> >
> > Pier
> 

Signing releases [was Re: question]

[Marc Saegesser]

I've checked the Tomcat 3.2.2b5 distribution and it looks OK.

Regarding signing the releases.  Could someone describe the procedures use
by other Apache projects for signing their releases?  Tomcat 3.2.2 will
going out in the near future and I would like to have a signing mechanism in
place prior to that.

> -Original Message-
> From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 24, 2001 11:20 AM
> To: Jon Stevens; Brian Behlendorf
> Cc: [EMAIL PROTECTED]; tomcat-dev
> Subject: Re: question
>
>
> Jon Stevens at [EMAIL PROTECTED] wrote:
> >
> > WHAT?? I don't think that there should be .sea files there!
> >
> > .sea is a MacOS Stuffit Archive.
> >
> > Also, the .war files are == .jar files which are equal to .zip
> files. They
> > are auto "uncompressed" by the servlet engine when it starts up. So, the
> > file will probably be located in the ROOT.war.
> >
> > We really should take all of our distributions offline ASAP.
>
> Hold it hold it hold it... I made the SEA of Tomcat 3.2.1 to work with
> Apple's MRJ on MacOS 8.6-9.1... (And it works!)
>
> >> This *looks* like a false alarm.  Ask him for an md5 of the tarball he
> >> downloaded, as well as where he downloaded it from.  You guys
> might want
> >> to consider signing your releases at some point, too.
> >
> > This is a project by project thing to do. Most of the projects do it
> > correctly.
>
> Might want to enforce it from a PMC standpoint?? :)
>
> Pier

Re: question

[Pier P. Fumagalli]

Jon Stevens at [EMAIL PROTECTED] wrote:
> 
> WHAT?? I don't think that there should be .sea files there!
> 
> .sea is a MacOS Stuffit Archive.
> 
> Also, the .war files are == .jar files which are equal to .zip files. They
> are auto "uncompressed" by the servlet engine when it starts up. So, the
> file will probably be located in the ROOT.war.
> 
> We really should take all of our distributions offline ASAP.

Hold it hold it hold it... I made the SEA of Tomcat 3.2.1 to work with
Apple's MRJ on MacOS 8.6-9.1... (And it works!)

>> This *looks* like a false alarm.  Ask him for an md5 of the tarball he
>> downloaded, as well as where he downloaded it from.  You guys might want
>> to consider signing your releases at some point, too.
> 
> This is a project by project thing to do. Most of the projects do it
> correctly.

Might want to enforce it from a PMC standpoint?? :)

Pier

Re: question

[Brian Behlendorf]

On Thu, 24 May 2001, Jon Stevens wrote:
> WHAT?? I don't think that there should be .sea files there!
>
> .sea is a MacOS Stuffit Archive.

To be clear, I'm talking about the .sea and .sea.hqx files found at

http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.1/bin/

They were created (ostensibly) on Jan 9th by Pier.  Pier, do you recall
putting them there?  These are separate files, *not* within the .tar.gz or
.zip distributions.  I seem to recall people talking about running tomcat
on MacOS9, so I'm not tempted to automatically state they're a problem,
but please tell me if they are.

> Also, the .war files are == .jar files which are equal to .zip files. They
> are auto "uncompressed" by the servlet engine when it starts up. So, the
> file will probably be located in the ROOT.war.

OK, I unzipped the ROOT.war file, and the index.html file in that dir
looks "normal" (i.e., not that index.htm file that person claimed was
there), as do the rest of the files that get unzipped.  I also looked at
all the other .war files, and none of them have that file.

So it seems OK.

Brian

Re: question

[Jon Stevens]

on 5/24/01 7:00 AM, "Brian Behlendorf" <[EMAIL PROTECTED]> wrote:

> Hmm; I looked at the following:
> 
> http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.1/bin/jakarta-tom
> cat-3.2.1.tar.gz
> http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.1/bin/jakarta-tom
> cat-3.2.1.zip
> 
> and in both of these, the webapps folder contained four files,
> 
> [taz3] 6:54am webapps > ls
> total 1247
> 1024 ROOT.war 7 admin.war   128 examples.war88 test.war
> 
> I didn't look inside the .sea archives, nor did I see a webapps dir in the
> servletapi tarballs.  Are there any other tarballs to look at?

WHAT?? I don't think that there should be .sea files there!

.sea is a MacOS Stuffit Archive.

Also, the .war files are == .jar files which are equal to .zip files. They
are auto "uncompressed" by the servlet engine when it starts up. So, the
file will probably be located in the ROOT.war.

We really should take all of our distributions offline ASAP.

> This *looks* like a false alarm.  Ask him for an md5 of the tarball he
> downloaded, as well as where he downloaded it from.  You guys might want
> to consider signing your releases at some point, too.

This is a project by project thing to do. Most of the projects do it
correctly.

-jon

Re: question

[Pier P. Fumagalli]

Correct... I went out and looked at the file, then did some research on the
virus itself, and, it doesn't (luckily) comes from our Tomcat 3.2.1
distribution (I'm paranoia mode right now!). The file is totally harmless
and it seems that "Casper" has a SunOS box which has been infected...

2 hours wasted... What-EVER! :)

Pier

Casper Gjerris at [EMAIL PROTECTED] wrote:

> Hi Pier,
> 
> I just picked up
> tomcat-3.2.1.zip
> tomcat-3.2.1.tar.gz
> tomcat.zip (from the nigthly 3.3)
> 
> And none of them seems to have any problems with index.html.
> 
> It seems to me that you have already fixed the problem or that "casper" in
> taiwan has been hacked himself.
> 
> Regards
> Casper Gjerris
> 
> 
> 
> 
> - Original Message -
> From: "Pier P. Fumagalli" <>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Thursday, May 24, 2001 12:18 PM
> Subject: FW: question
> 
> 
> Here's what it seems they did with the exploit... Rerolling the binaries
> *balls of Tomcat putting a new index.htm...
> 
> I'm downloading the supposedly wrong binary as we speak, but it's kinda slow
> from my 56kbps connection...
> 
> Fuck shit...
> 
>   Pier
> 
> -- Forwarded Message
> From: "casper"<[EMAIL PROTECTED]>
> Reply-To: "casper"<[EMAIL PROTECTED]>
> Date: Thu, 24 May 2001 14:07:14 +0800
> To: "webmaster @ jakarta . apache . org" <[EMAIL PROTECTED]>
> Subject: question
> 
> Hi
> 
> I download tomcat3.2.1 version software but when i to set my file in the
> \webapps .I find one file and file name is index.htm and this file is from
> china.
> i send this file to you,pls to check your server is okay and i have check my
> server is no any hacker.
> I download file date is 2001/05/23.
> If it's right pls send mail to me.
> 
> thanks
> Casper
> 
> 
> 
> ??·?  http://mail.kimo.com.tw
> < ? ? ? ?·? ? ? ? >  http://www.kimo.com.tw
> 
> 
> 
> -- End of Forwarded Message
> 
> 

Re: question

[Pier P. Fumagalli]

Noticed, and that seems to have affected one of our Tomcat distributions...
Still checking...

Pier

Reilly, John at [EMAIL PROTECTED] wrote:

> Hi Pier,
> Apparently there is a virus in the index.htm  - I got the following attached
> to your mail.
> 
> John
> 
> 
>    Network Associates GroupShield Exchange  **
>   Alert generated at: Thursday, May 24, 2001 11:23:27 GMT Daylight
> Time
> **
> 
> 
> The file index.htm has been replaced as it contains the SunOS/BoxPoison.worm
> virus.
> Please consult your administrator for further help.
> 
> 
> 
>> -Original Message-
>> From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, May 24, 2001 11:18 AM
>> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>> Subject: FW: question
>> 
>> 
>> Here's what it seems they did with the exploit... Rerolling
>> the binaries
>> *balls of Tomcat putting a new index.htm...
>> 
>> I'm downloading the supposedly wrong binary as we speak, but
>> it's kinda slow
>> from my 56kbps connection...
>> 
>> Fuck shit...
>> 
>> Pier
>> 

Re: question

[Pier P. Fumagalli]

DO NOT (I repeat) DO NOT OPEN the index.htm file I sent in my previous
post... It's infected with a copy of SunOS/BoxPoison.worm AND it seems it's
coming from one of our distributions of Tomcat 3.2.x...
I'm still digging thru it...

Pier

Pier P. Fumagalli at [EMAIL PROTECTED] wrote:

> Here's what it seems they did with the exploit... Rerolling the binaries
> *balls of Tomcat putting a new index.htm...
> 
> I'm downloading the supposedly wrong binary as we speak, but it's kinda slow
> from my 56kbps connection...
> 
> Fuck shit...
> 
>   Pier

RE: question

[Reilly, John]

Hi Pier,
Apparently there is a virus in the index.htm  - I got the following attached
to your mail.

John


   Network Associates GroupShield Exchange  **
  Alert generated at: Thursday, May 24, 2001 11:23:27 GMT Daylight
Time
**


The file index.htm has been replaced as it contains the SunOS/BoxPoison.worm
virus.
 Please consult your administrator for further help.



> -Original Message-
> From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 24, 2001 11:18 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: FW: question
> 
> 
> Here's what it seems they did with the exploit... Rerolling 
> the binaries
> *balls of Tomcat putting a new index.htm...
> 
> I'm downloading the supposedly wrong binary as we speak, but 
> it's kinda slow
> from my 56kbps connection...
> 
> Fuck shit...
> 
> Pier
> 

RE: Question version 1.1

[Marc Saegesser]

OK, that goes right to the top of the "Why didn't I think of that" list.
I'll add section to the Tomcat page describing the various releases.

> -Original Message-
> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 15, 2001 3:35 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Question version 1.1
>
>
> > Nothing is going on... Tomcat 3.x is the reference implementation
> > of the old
> > Servlet 2.2/JSP 1.1 APIs, while Tomcat 4.x is the reference
> implementation
> > of the upcoming new Servlet 2.3/JSP 1.2 APIs.
> > Depending on which API version you want, you might want to try
> either the
> > 3.2 tree or the 4.0 tree...
>
> Maybe something like this should be placed in an impossible to miss place
> for whomever tries to download/get info on Tomcat.
>
> It is the most efficient way to stop USERs confusion.
>
>
> Have fun,
> Paulo Gaspar
>
>
> > -Original Message-
> > From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, May 13, 2001 8:05 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Question version 1.1
> > Importance: High
> >
> >
> > Michael G. Anderson at [EMAIL PROTECTED] wrote:
> >
> > > See Question version 1.0!
> > > Is version 3.2.2 beta 5 the latest?
> > > or is Tomcat 4(4.4) the latest?
> > >
> > > What is the latest version?
> > >
> > > What am I missing?
> > >
> > >
> > > What is going on...
> >
> > Nothing is going on... Tomcat 3.x is the reference implementation
> > of the old
> > Servlet 2.2/JSP 1.1 APIs, while Tomcat 4.x is the reference
> implementation
> > of the upcoming new Servlet 2.3/JSP 1.2 APIs.
> > Depending on which API version you want, you might want to try
> either the
> > 3.2 tree or the 4.0 tree...
> >
> > Pier
> >

RE: Question version 1.1

[Paulo Gaspar]

> Nothing is going on... Tomcat 3.x is the reference implementation
> of the old
> Servlet 2.2/JSP 1.1 APIs, while Tomcat 4.x is the reference implementation
> of the upcoming new Servlet 2.3/JSP 1.2 APIs.
> Depending on which API version you want, you might want to try either the
> 3.2 tree or the 4.0 tree...

Maybe something like this should be placed in an impossible to miss place
for whomever tries to download/get info on Tomcat.

It is the most efficient way to stop USERs confusion.


Have fun,
Paulo Gaspar


> -Original Message-
> From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, May 13, 2001 8:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Question version 1.1
> Importance: High
>
>
> Michael G. Anderson at [EMAIL PROTECTED] wrote:
>
> > See Question version 1.0!
> > Is version 3.2.2 beta 5 the latest?
> > or is Tomcat 4(4.4) the latest?
> >
> > What is the latest version?
> >
> > What am I missing?
> >
> >
> > What is going on...
>
> Nothing is going on... Tomcat 3.x is the reference implementation
> of the old
> Servlet 2.2/JSP 1.1 APIs, while Tomcat 4.x is the reference implementation
> of the upcoming new Servlet 2.3/JSP 1.2 APIs.
> Depending on which API version you want, you might want to try either the
> 3.2 tree or the 4.0 tree...
>
> Pier
>

Re: Question version 1.1

[Pier P. Fumagalli]

Michael G. Anderson at [EMAIL PROTECTED] wrote:

> See Question version 1.0!
> Is version 3.2.2 beta 5 the latest?
> or is Tomcat 4(4.4) the latest?
> 
> What is the latest version?
> 
> What am I missing?
> 
> 
> What is going on...

Nothing is going on... Tomcat 3.x is the reference implementation of the old
Servlet 2.2/JSP 1.1 APIs, while Tomcat 4.x is the reference implementation
of the upcoming new Servlet 2.3/JSP 1.2 APIs.
Depending on which API version you want, you might want to try either the
3.2 tree or the 4.0 tree...

Pier

Re: Question version 1.1

[William A. Rowe, Jr.]

From: "Michael G. Anderson" <[EMAIL PROTECTED]>
Sent: Friday, May 11, 2001 9:19 PM


> See Question version 1.0!
> Is version 3.2.2 beta 5 the latest?
> or is Tomcat 4(4.4) the latest?
> 
> What is the latest version?

I'll try to answer this, and be resoundingly corrected, or if folks are silent
you can assume I've got the gist of this...

Tomcat 3.2.2 beta 5 is a release-candidate.  Everyone hopes it will be the
next release of Tomcat 3.2.2 since it incorporates security fixes you _need_.
You are encouraged to test this _now_ if you are a 3.2.1/3.2.2 user today.

Tomcat 3.3 is in development, and should near release over the next few months.
It incorporates new APIs and may include new connectors sometime in the near 
future (or does right now, I'm not certain.)  But treat it as a work-in-progress
until the beta nears, and if you like life on the edge, try using it instead.
It will be changing a bit between now and it's release.


Tomcat 4.0 is in development, and should near release sometime [?].  But it's a
rather new beast, supporting the next [not yet published] java servlets api
which is subject to change.  It will bring Apache's 'filters' to Tomcat and
offer a host of new things, including [probably] a brand new apache connector
module [which of two, or both, isn't determined yet.]  If you like life on the
bleeding edge, try tomcat 4.0 with apache 2.0, but be prepared to stay current
with the repositories on both, and don't put your money on building successfully
at any given point in time :-)  It is likely to change alot between now and it's
release.

If I blew it, please correct me.

Bill

> What am I missing?
> 
> 
> What is going on...
> 
> Marc Saegesser wrote:
> 
> > I am pleased to announce that the Tomcat 3.2.2 beta 5 release is now
> > available for download at
> >
> > http://jakarta.apache.org/builds/tomcat/release/v3.2.2-beta-5
> >
> > The beta 5 release fixes a security problem that caused a URL such as
> >
> > http://localhost:8080/examples/jsp/num/numguess.jsp%00
> >
> > to return the JSP source text on some platforms.  If you are using any
> > previous beta release of Tomcat 3.2.2 please upgrade to beta 5 as soon as
> > possible.
> >
> > The release notes file in src/doc/readme covers the details of the Tomcat
> > 3.2.2 release.
> >
> > Marc A. Saegesser
> 
> 

Re: Question - Re: cvs commit: DefaultCMSetter.java

[Kazuhiro Kazama]

Arieh,

From: Arieh Markel <[EMAIL PROTECTED]>
Subject: Question - Re: cvs commit: DefaultCMSetter.java
Date: Fri, 16 Mar 2001 17:34:30 -0700 (MST)
Message-ID: <[EMAIL PROTECTED]>
> Shouldn't the charset be according to the Locale and Charset of the
> request that was passed ?

I think there are three localization (or internationalization) model
on servlet container:

1, Based on Java (= platform) default locale. This model is used for
internal modules which output native messages (for example, errors of
native libraries or applications etc.) or administration messages.

2, Based on the specified locale by service providers. This model is
general.

3, Based on the specified locale by users. This model is used for
servlets which use content nagotiation and output messages according
to their language requests.

The reason that we selected model "1" for DefaultCMSetter.java is to
enable error outputs. On japanese Solaris or Windows, tomcat sometimes
returns error messages in japanese but they aren't display correctly
in the case of content type is "text/html" (= "text/html;
charset=iso-8859-1"). We must change charset.

And another problem is naming scheme about Java character encoding
converters. Most of Java VM uses non MIME prefered name. Someone
thinks that it is better to use "file.encoding" property but it is
"eucJP" (cf, MIME prefered name is "EUC-JP") on Japanese Solaris 2.
We need normalization to MIME prefered names.

But I think there may be another solution. I hope you will do better
jobs.

Kazuhiro Kazama ([EMAIL PROTECTED]) NTT Network Innovation Laboratories

Re: Re: Question about CLIENT-CERT on web.xml file ?

[jerome . camilleri]

Yes I understand what you said about CLIENT-CERT and I add a new entry in my tomcat-usr.xml file :

  
  
  
  


Functions getSubjectDN().getName() return OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr value for the
first certificate chain, so I consider this value is the new user name.
I have yet auth-method into CLIENT-CERT value and when I try to connect on my tomcat serveur I have the same message :

"You are not authorized to view this page"

My local_host_access.log file give me this information :
camilleri - OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr [21/Dec/2000:11:07:50 1000] "GET /examples/servlet/SnoopServlet HTTP/1.1" 200 4017
camilleri - OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr [21/Dec/2000:11:08:32 1000] "GET /examples/servlet/SnoopServlet HTTP/1.1" 403 -

So I try to cut attribut password on tomcat-users file because when I use a certificate I don't understand what I would say... but 
with no success...

So thank you if you are a another good idea ?

Best Regards

Jérôme

Re: Question about CLIENT-CERT on web.xml file ?

[Craig R. McClanahan]

[EMAIL PROTECTED] wrote:
 
Hello,
I try to use the auth-method of
web.xml to CLIENT-CERT value like it's precise on web.dtd
So the fragment of web.xml file
:
    
    
 
CLIENT-CERT
 
Example Form-Based Authentication Area
 

   
/jsp/security/login/login.jsp
   
/jsp/security/login/error.jsp
 

    
When I try to access on 
a  url-pattern who is protect by a  
with https on port 8443,
I always have the same response
on the catalina server :
  
You are not authorized to view this page
 
 
When you use CLIENT-CERT login plus a security constraint, what you are
asking Catalina to do is look up the authenticated client in its Realm
(by default, the MemoryRealm that reads from $CATALINA_HOME/conf/tomcat-users.xml),
to (a) make sure that the client is present in the Realm, and (b) look
up the associated roles to verify against the security constraint.
The "username" that is looked up is the value returned by calling getSubjectDN().getName()
on the first certificate in the certificate chain -- in other words, the
principal name of the client that was authenticated by this certificate.
If all you want to do is make sure the client has a valid certificate,
you don't need to use a security constraint at all -- just set the "clientAuth"
property on the Connector to true, and no requests will be accepted without
a certificate.  On the other hand, if you want to use security constraints
in addition, you will need to define the user (and associated roles) in
your Realm, just as you would for any other login method.
 
Anybody know where do I find
any information about this fonctionnality whas I bad used ?
Best regards
Jérôme
Craig McClanahan