Re: Question: Strange Session Remove Attribute
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
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
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
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
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
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
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
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
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
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
- Original Message - From: Peter Rossbach [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org 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: Strange Session Remove Attribute
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 about new mod_jk jk_lb_worker.c
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
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 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 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
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
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 method for all workers in the worker_map:
Re: Question about new mod_jk jk_lb_worker.c
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 not null and not empty.
+ */
+ static
Re: Question about new mod_jk jk_lb_worker.c
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 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
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 mail Can you forward that. Seems I can not
Re: Question about new mod_jk jk_lb_worker.c
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
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
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
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 the connection between Apache and Tomcat with JK
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
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 on 5.0.23
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
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 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
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:
jsp:root
xmlns:jsp=http://java.sun.com/JSP/Page; version=1.2
xmlns:direct=urn:jsptld:/WEB-INF/tlds/example-taglib.tld
jsp:text![CDATA[html
titlepositiveDirectTldReference/title
body
]]/jsp:text
jsp:text![CDATA[
]]/jsp:text
direct:test toBrowser=true att1=att1
jsp:text![CDATA[
Validated
]]/jsp:text
/direct:test
jsp:text![CDATA[
/body
/html
]]/jsp:text
/jsp:root
Generates for the tag:
do {
out.write(jsp:text);
out.write(\n);
out.write(Validated\n);
out.write(/jsp:text);
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 jsp:attribute and/or jsp:body 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
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: tag nametest/name tag-classtags.TestTag/tag-class tei-classtags.TestTagExtraInfo/tei-class body-contenttagdependent/body-content description test message. /description attribute nametoBrowser/name requiredfalse/required /attribute attribute nameatt1/name requiredtrue/required /attribute attribute nameatt2/name requiredfalse/required /attribute /tag 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
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 on 5.0.23
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
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
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
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
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
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
I have some possible problems with Jasper and XML syntax. One example
from old watchdog:
jsp:root
xmlns:jsp=http://java.sun.com/JSP/Page; version=1.2
xmlns:direct=urn:jsptld:/WEB-INF/tlds/example-taglib.tld
jsp:text![CDATA[html
titlepositiveDirectTldReference/title
body
]]/jsp:text
jsp:text![CDATA[
]]/jsp:text
direct:test toBrowser=true att1=att1
jsp:text![CDATA[
Validated
]]/jsp:text
/direct:test
jsp:text![CDATA[
/body
/html
]]/jsp:text
/jsp:root
Generates for the tag:
do {
out.write(jsp:text);
out.write(\n);
out.write(Validated\n);
out.write(/jsp:text);
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 jsp:attribute and/or jsp:body 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 about HttpServletRequest.getParameterValues()
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()
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()
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; imax; i++) {
if (key.equalsIgnoreCase(password)) vals[i] = ;
logger.info(...key:+key+ value:+vals[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
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 about a JCP proposition
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
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
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
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 on Tomcat 4
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.20r2=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
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 Tomcat 4
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.20r2=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 how to work IIS with Tomcat
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
- 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
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
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Question about Internationalization
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] test.jsp Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Question about Session in Tomcat 3.3 -- continued...
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: 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 patch submission
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: 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 on JTC native/apache2.0 mod_jk.c
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Question about jsp/servlet performance
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Question: does Tomcat4 manage jsp/servlet threads?
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Question on JServ - High Priority
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Question on chunked responses.
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.
Is there a way to completly disable chunking ? I have set allowChunking=false in server.xml but HttpResponseStream:checkChunking 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 chunked responses.
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.
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 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,
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.
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.
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,
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.
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 about the reloading of servlet
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: question about the reloading of servlet
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: Signing releases [was Re: question]
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: question
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
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
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
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
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 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 version 1.1
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
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
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
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: Question about compiling the servlets.
Milan Kuchtiak wrote: I am partly working on Tomcat integration into Forte4j IDE. Could anybody tell me how the servlets are compiled into classes. I supose that not JDK javac compiler is used. In general, the JDK compiler is probably used by most people, although any Java compiler should be able to do the trick. Because a servlet is just a Java class, you should be able to compile it the same way you compile any other Java class. Thank You Milan Craig McClanahan See you at ApacheCon Europe http://www.apachecon.com! Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ Applications to Tomcat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
