Re: [VOTE] 5.5.12 Stability
Tested with Mac OS (10.4) , Win32 and Suse 9.3 prof. Tomcat 5.5.12 is: [x] Stable - no major issues, [ ] Beta - at least one major issue: what is it? [ ] Alpha - multiple things or a real showstopper: please provide details.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.15
Hey Mladen, can we also integrate the better domain loadbalancer support at jk_lb_worker.c? I think that we don't change the lb_value inside sticky mode at every request. Can we comment out or remove lines L413-431? Thanks, Peter Mladen Turk schrieb: There has been couple of major bug fixes against 1.2.14, see: http://jakarta.apache.org/tomcat/connectors-doc/changelog.html They have been fixed in the CVS, and since couple of them actually makes 1.2.14 unusable on some platforms like Solaris 2.8 and Irix we need a release. I plan to tag the 1.2.15 by the end of this week, and pursue for a vote next week for this bug-fixing release. Any objections? Since there were no objections I plan to tag the 1.2.15 later this evening at 19:00 GMT. This will eventually be the last release from CVS, cause IIUC the transition will be made this weekend. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK 1.2.15
Yes, is is only a real problem when workers are grouped inside an domain. I have check this many times and without the lb_value change loadbalancing works as I aspected, and with it not. I also think that we need a real lb concept check. Greater changes can we better realize after jk 2.1.15. But this little change was very helpful at some of my production customers sites :-) Peter Mladen Turk schrieb: Peter Rossbach wrote: Hey Mladen, can we also integrate the better domain loadbalancer support at jk_lb_worker.c? I think that we don't change the lb_value inside sticky mode at every request. Yes we do. They will be updated only for domain workers. This is needed to load balance between the workers that are members of the same domain. In other case the total_factor will be zero and lb_value will not be changed. 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: Bug or Feature inside mod_jk loadbalancer algo?
Sounds good to me. Wrote a spec before implementation is very helpfull :-) The domain case with sticky session and real clustered szenarios is not easy. Peter Mladen Turk schrieb: Peter Rossbach wrote: Hey, I have a strange loadbalancer behaviour at a customer site with Apache 2/mod_jk 1.2.14, JVM 1.5, Tomcat 5.5.9 (cluster), (Suse 9.1) Hi guys, Peter you are correct about this... I found by myself too, that balancer is misbehaving in some cases. One of them is 'domain' model, where multiple workers should behave like one on the global scale, but still maintain internal load. The other is for worker-like mpm's when cachesize is lower then the ThreadsPerChild. I've been able to fix that (sort of), but I'm not happy with the fix. What would I suggest is that we gather all the 'use cases' and write down what the predicted results should be. I'll create a separate .txt file (that will later be part of loadbalancer howto) upon which we can enter the configuration and expected behavior. How that sounds? I'm moving this discussion to the tomcat-dev@, so that we have the trace of it. OK? 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm UserDatabaseRealm.java
Hey Bill,
many thanks to clean this up
Peter
[EMAIL PROTECTED] schrieb:
billbarker2005/08/17 21:41:02
Modified:catalina/src/share/org/apache/catalina/realm
UserDatabaseRealm.java
Log:
Clean up previous patch so it works with Custom UserDatabases, not just the
Memory one.
Revision ChangesPath
1.14 +22 -18
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/UserDatabaseRealm.java
Index: UserDatabaseRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/UserDatabaseRealm.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- UserDatabaseRealm.java 17 Aug 2005 10:40:33 - 1.13
+++ UserDatabaseRealm.java 18 Aug 2005 04:41:02 - 1.14
@@ -142,6 +142,12 @@
* @param role Security role to be checked
*/
public boolean hasRole(Principal principal, String role) {
+if( principal instanceof GenericPrincipal) {
+GenericPrincipal gp = (GenericPrincipal)principal;
+if(gp.getUserPrincipal() instanceof User) {
+principal = gp.getUserPrincipal();
+}
+}
if(! (principal instanceof User) ) {
//Play nice with SSO and mixed Realms
return super.hasRole(principal, role);
@@ -203,29 +209,27 @@
*/
protected Principal getPrincipal(String username) {
-Principal principal = database.findUser(username);
-if(principal instanceof GenericPrincipal)
-return principal ;
-
+User user = database.findUser(username);
+if(user == null) {
+return null;
+}
+
List roles = new ArrayList();
-if(principal instanceof MemoryUser) {
-MemoryUser user = (MemoryUser)principal;
-Iterator uroles = user.getRoles();
+Iterator uroles = user.getRoles();
+while(uroles.hasNext()) {
+Role role = (Role)uroles.next();
+roles.add(role.getName());
+}
+Iterator groups = user.getGroups();
+while(groups.hasNext()) {
+Group group = (Group)groups.next();
+uroles = user.getRoles();
while(uroles.hasNext()) {
Role role = (Role)uroles.next();
roles.add(role.getName());
}
-Iterator groups = user.getGroups();
-while(groups.hasNext()) {
-Group group = (Group)groups.next();
-uroles = user.getRoles();
-while(uroles.hasNext()) {
-Role role = (Role)uroles.next();
-roles.add(role.getName());
-}
-}
}
-return new GenericPrincipal(this, username, getPassword(username),
roles, principal);
+return new GenericPrincipal(this, username, user.getPassword(),
roles, user);
}
-
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: why is Principal not serialized for clustering replication of ses sion?
Hey Dirk,
I thing you have found a strange missing feature inside the cluster
implementation. Currently
all other realm MemoryRealm, DataSourceRealm,JNDIRealm, JAASRealm and
JDBCRealm create a GenericPrincipal that used inside the
DeltaRequest.setPrincipal method. The UserDatabaseRealm create a
o.a.c.users.MemoryUser principal. Very bad thing!! Integrate a spezial
handling for this is easy, but :-(
I have tested with MemoryRealm successfull with basic auth. Sorry, but
this means that at every request a message is replicated.
The session principal is set at every request. I don't like this
behaviour. Any ideas to change it are very welcomed!
Please open a bug report that we can work together at this auth topic
and documened it well at changelog.
Thanks for reporting this.
Peter
Peter Rossbach schrieb:
Hmm,
I have look inside source of DeltaRequest
public void setPrincipal(Principal p) {
int action = (p==null)?ACTION_REMOVE:ACTION_SET;
SerializablePrincipal sp = null;
if ( p != null ) {
sp =
SerializablePrincipal.createPrincipal((GenericPrincipal)p);
}
addAction(TYPE_PRINCIPAL,action,NAME_PRINCIPAL,sp);
}
public synchronized void execute(DeltaSession session, boolean
notifyListeners) {
...
Principal p = null;
if ( info.getAction() == ACTION_SET ) {
SerializablePrincipal sp =
(SerializablePrincipal)info.getValue();
p =
(Principal)sp.getPrincipal(session.getManager().getContainer().getRealm());
}
session.setPrincipal(p,false);
break;
}//case
and this look like that we explizit replicated the principal.
I will test you use case with the newest 5.5.x code base again and
describe
the results later.
peter
PS: SingleSignOn is currently not supported at the cluster
implementation :-(
Dirk de Kok schrieb:
hi all,
we are having a problem with our Tomcat 5.5.9 cluster. We run 2 Tomcat
instances on physically different machines. For security we use normal
container managed security, configured in the web.xml. Session
replication
works fine, and session id's are same across the two instances. We
only have
trouble with the authentication.
For instance, if you are logged in on instance1, if in case of error the
load balancer redirects subsequent request to instance2, you have to
login
again. Turning on Single Signon did not help.
Browsing through the Tomcat source code I noticed that very explicit the
security Principal is not saved in a serialized session. Has anybody
an idea
why this is not done? What way would we be able to let the security
information propagate throughout the cluster?
Configuration:
- OS: RH 4
- App server: Tomcat 5.5.9
- Session replication: in-memory, pooled
- Load balancing via hardware load balancer (Cisco) with sticky sessions
tia,
Dirk
- Lost Boys creates and delivers internet mobile solutions -
Dirk de Kok | Java Specialist
Lost Boys B.V. | Joop Geesinkweg 209 | 1096 AV Amsterdam The
Netherlands |
Tel: +31 20 4604500 | Fax: +31 20 4604501 | [EMAIL PROTECTED] |
www.lostboys.nl
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: why is Principal not serialized for clustering replication of ses sion?
Hmm,
I have look inside source of DeltaRequest
public void setPrincipal(Principal p) {
int action = (p==null)?ACTION_REMOVE:ACTION_SET;
SerializablePrincipal sp = null;
if ( p != null ) {
sp = SerializablePrincipal.createPrincipal((GenericPrincipal)p);
}
addAction(TYPE_PRINCIPAL,action,NAME_PRINCIPAL,sp);
}
public synchronized void execute(DeltaSession session, boolean
notifyListeners) {
...
Principal p = null;
if ( info.getAction() == ACTION_SET ) {
SerializablePrincipal sp =
(SerializablePrincipal)info.getValue();
p =
(Principal)sp.getPrincipal(session.getManager().getContainer().getRealm());
}
session.setPrincipal(p,false);
break;
}//case
and this look like that we explizit replicated the principal.
I will test you use case with the newest 5.5.x code base again and describe
the results later.
peter
PS: SingleSignOn is currently not supported at the cluster
implementation :-(
Dirk de Kok schrieb:
hi all,
we are having a problem with our Tomcat 5.5.9 cluster. We run 2 Tomcat
instances on physically different machines. For security we use normal
container managed security, configured in the web.xml. Session replication
works fine, and session id's are same across the two instances. We only have
trouble with the authentication.
For instance, if you are logged in on instance1, if in case of error the
load balancer redirects subsequent request to instance2, you have to login
again. Turning on Single Signon did not help.
Browsing through the Tomcat source code I noticed that very explicit the
security Principal is not saved in a serialized session. Has anybody an idea
why this is not done? What way would we be able to let the security
information propagate throughout the cluster?
Configuration:
- OS: RH 4
- App server: Tomcat 5.5.9
- Session replication: in-memory, pooled
- Load balancing via hardware load balancer (Cisco) with sticky sessions
tia,
Dirk
- Lost Boys creates and delivers internet mobile solutions -
Dirk de Kok | Java Specialist
Lost Boys B.V. | Joop Geesinkweg 209 | 1096 AV Amsterdam The Netherlands |
Tel: +31 20 4604500 | Fax: +31 20 4604501 | [EMAIL PROTECTED] |
www.lostboys.nl
-
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: New tag ?
Hey Remy, I talk with Stefan Bodwig at ApacheCon about the revision problem. He has implement a small antlib project and hope this help http://svn.apache.org/repos/asf/ant/sandbox/antlibs/svn/trunk/ I have not test it yet, but it seams that we can use this ... == I can help to migrate to svn after 15.te august. Peter Remy Maucherat schrieb: Yoav Shapira wrote: Hi, I'm OK with cutting 5.5.10 tomorrow or Saturday. If that's too early, let's pick a different time. I don't have further code changes to add in this build, it seems. After 5.5.10, I want to talk about SVN migration again ;) I'm aware of the lack of satisfaction among the CVS GUI users, but infra is cutting off CVS on January 1st, and for me personally, August seems like a great time to do the transition since it's traditionally a low-activity period. It's not really a UI thing for me. One feature I use often are revision lists for a particular file, to be able to tell where a bug has been introduced (I then do diffs between revisions). It seems with SVN I have to retrieve the full revision list for the repository (which will take hours). If someone can offer a workaround for this problem, then I'll support a move to SVN :) 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: New tag ?
Yes, I also think we can build a 5.5.10 release with all the new stuff. The new cluster redesign version is yet only tested under small load. Better I commit my new jkstatus task after my three week holiday for next release (5.5.11). I have add a new lib (catalina-jmx-ant.jar) for jmx ant tasks to server/lib and two ant scripts include at bin, but I have not test the release included this things also. Greetings from ApacheCon Peter Remy Maucherat schrieb: Hi, I think the APR capabilities that we added are now sufficiently stable to warrant testing. If the other areas that saw changes recently (clustering, JK) are ok too, then it could be a good idea to release a new build. 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: Tomcat Session Replication Portlets
Hey Eric, which tomcat release you use? I have change a lot inside the current 5.5 cvs head and hope your work is compatible with this changes. I thing your changes is not easy and you must reflect that other Valves and Listener must also reflect your API deprecated CrossContext feature. Why the Portlet API need CrossContext? Implementatation help: Your must rewrote the complete ReplicationValve and JvmRouteBinderValve Look inside ReplicationValve.invoke and get from Container the Cluster CatalinaCluster cluster = (CatalinaCluster) getContainer.getCluster(); Currently you can get the complete list of the registerted application managers It is not easy to detected changes coordinate the startup and restart manager phase.. ( Look inside DeltaManager :-) I thing you must coordinate your replication with other threads ... ( very bad sync blocks). have fun... Peter Eric Dalquist schrieb: I have been working on getting session replication working with some web applications that use cross context dispatching. In this case it is uPortal and JSR-168 portlets running via the Jakarta Pluto portlet container. Session replication is working as expected with uPortal. Portlets on the other hand are not having their sessions replicated. In this application configuration the follow calls are happening. The browser makes a request to tomcat for the uPortal web application. While uPortal is rendering it makes cross context dispatch calls to servlets in the portlet web applications to render the results in the portal's response. After some digging and stack traces to figure out how session replication in tomcat is implemented I've determined why the portlet applications are not having their sessions replicated. It appears that there is a ReplicationValve which is enabled by the presence of the Cluster tag in Tomcat's server.xml. This valve is only present in the stack for a direct call to the container and is not present in a cross context dispatched call. I would like to work with the Tomcat developers to implement the ability for cross context calls to also notify the session manager that replication should be considered for the context. I am prepared to do the work for this task but would like to get some feed back from the tomcat developer community on recommendations and in what way the work could be done to ensure its eventual inclusion in the tomcat codebase. Thank you, Eric Dalquist - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh
Hey, I can build the binaries for suse 9.3, 9.1 and I hope for MAC OS X 10.4 I am ready to commit an ant task to represent current apache jk status show command result. I am no sure that the jkstatus ant task are a new submodule from jakarta-tomcat-connectors/jk/ (my current place) or better integrate inside catalina core o.a.c.ant.jkstatus subpackage. I used the o.a.c.ant.BaseRedirectorHelperTask for output and error handling. Jkstatus ant task todo - docs -integrate also the JkStatusUpdate Task -Represent and update the apaches also with a MBean. Peter Henri Gomez schrieb: make a source tarball bvefore release so I could check on iSeries 2005/7/1, jean-frederic clere [EMAIL PROTECTED]: Mladen Turk wrote: jean-frederic clere wrote: Well there are still 20 bugs in tomcat5/mod-jk, what do with them? Not sure. Lot's of obsolete things that need a simple cleanup. Ok I will start to clean bugzilla. I can only tell the current CVS is the best ever mod_jk we had. If it builds on all platforms (ant it does AFAICT), we should go for the release ASAP. I will test it on BS2000, if it builds and runs there it is ready for a release! There are just too many things that has been fixed since last stable, that we should ignore or try to wait much further. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Remy Maucherat schrieb: [EMAIL PROTECTED] wrote: billbarker2005/06/29 19:49:38 With a 16K bufferSize, the APR connector is no longer the clear winner in performance. For BC, it's currently disabled by default, but it's easy enough to change that after some more testing. Yes, I can see performance is better too. It's also possible that taking the APR code, and rewriting it with regular Java IO would also yield slightly better results (regular HTTP is still a little faster than APR HTTP - some VMs make the difference very small, but the VM I use for testing is definitely not the best for JNI). Now that I've looked at it a lot, however, I dislike the Java AJP impl, as it's way overengineered in comparison to what it required by the current Tomcat. Very true I don't like this part of the source. I think we can implement the AJP integration simpler and extract the jk2 mbeans and mx4j JMX integration. Peter Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper HostMap.java Mapper.java
Hey Remy, For usefull feature I don't give up :-) The default of host alias matching is off. The current implementation is little bit fast then the old one. (Great) Every user of this feature can limit the dynamic host addition with Connector port=8080 allowedAliasMatches=10 / The wild card alias usage is very useful for tomcat hoster. Now the customer can use a new host subdomain without change the server.xml. Very nice and the admin must do nothing. simple add first time Alias*.mydomain.net/Alias to your host. +1 vote for this feature. Peter Remy Maucherat schrieb: [EMAIL PROTECTED] wrote: pero2005/06/04 05:32:53 Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java Added: util/java/org/apache/tomcat/util/http/mapper HostMap.java Log: Support Host Alias matching with Connector attribute allowedAliasMatches Submitted by George Sexton You're not giving up, eh ? ;) Good, because neither do I. First, the bad behavior of the algorithm (adding hosts) has not been changed. Everything seems to indicate that the algorithm is bound to mess up any possible dynamic management of hosts. I also have to insist that this feature addition is useless. The idea of using a different algorithm for exact matching is good (not critical, but good), but I am agaist this wildcard host feature. -1. 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: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper HostMap.java Mapper.java
Hey. Remy Maucherat schrieb: Peter Rossbach wrote: Hey Remy, For usefull feature I don't give up :-) Fine, I'll just revert your patch then ;) Hmm, thanks for that... :-( The default of host alias matching is off. The current implementation is little bit fast then the old one. (Great) Every user of this feature can limit the dynamic host addition with Connector port=8080 allowedAliasMatches=10 / The issue is that this mechanism is bad, period. Why it is so bad? The implementation was faster then the revert mapper state. What is a better way to implement this feature? The wild card alias usage is very useful for tomcat hoster. Now the customer can use a new host subdomain without change the server.xml. Very nice and the admin must do nothing. And the usefulness of that is non existent as well. What's the purpose of adding hosts if they are all the same ? Easy: Hoster has installed the site with mydomain.net and later your customer want www.mydomain.net, foto.mydomain.net, or you have an application (blog,wiki,cms) that people can register and then there get an own universe (new subdomain). Currently I add new Alias to the Host section and save the server.xml without context.xml writing ( feature from new storeconfig module). (Bill: the com.sun... package not used inside code... My fault.) simple add first time Alias*.mydomain.net/Alias to your host. +1 vote for this feature. -1 vote for this feature. 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: Summer of code
Hey Tim, Have you see this fine mod_rewrite filter at http://tuckey.org/urlrewrite/. What you mean, can we use the common httpclient for backend proxy implementation? It has a stable pooling with keepalive handling and http/https support. Peter Tim Funk schrieb: Here is more detail of what I was pondering with the reverse proxy. Topic - Extend the balancer webapp to allow for reverse proxy Description - Write a 2.4 compliant Servlet Filter which will allow tomcat (or any other compliant engine) to act as a reverse proxy. Constraints --- - Use no tomcat internal specific api's - Allow for other filters to wrap this so caching would be allowed - Allow for pluggable proxy rules much like the balancer is implemented Rules to create --- - simple match rule which is one-to-one mapping back to a single server based on a URL prefix Nice to haves - - Use a pool of connections to take advantage of keep-alive capabilitites - A partner caching filter which can cache to memory/disk/??? - A partner filter which can provide rudimentary content rewriting for hosts which return an incorrect hostname - cluster rule - So tomcat fronts a cluster of servers for the following scenarios 1) round robin 2) random 3) sticky Remy Maucherat wrote: I think there should be proposals, like this one which seems good, then have a vote on all these. Please be quick for the proposals as there's a deadline, apparently, so I'd say this needs to be wrapped up and the wiki edited by the end of next week. - 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: [ANN/VOTE] JK 1.2.12 Released
[X] Stable -- good build [ ] Alpha -- something serious is wrong: what is it? I vote for stable and build now the jk 1.2.12 for Suse 9.3. Peter Mladen Turk schrieb: Hi, JK 1.2.12 has been released. This is mostly a bug fix release over JK 1.2.10 and fixes wc_close bug found in 1.2.11. Please see the: http://jakarta.apache.org/tomcat/connectors-doc/changelog.html for a full list of changes. Sources can be found at: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.12/ Binaries can be found at: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/ For now there is a set of win32 binaries: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/win32/jk-1.2.12/ and some linux binaries: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/linux/jk-1.2.12/ Feel free to add any other binaries for your favorite platform :) I would also like to make a stability VOTE at once (to keep the email noise at minimum). The vote will run for a week. [ ] Stable -- good build [ ] Alpha -- something serious is wrong: what is it? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging 1.2.12
Hi Mladen, yersterday I fix the stopped flag bug. In some case the stopped flag was ignored. I test one case that is not well handled: Configure only one disabled lb worker and requests without session id was handled. Hups! I think the special case only one worker at jk_lb_worker.c#get_mostsuitable_worker not handle the disabled case correct. Peter Mladen Turk schrieb: Hi, It's been a week since 1.2.11 has been tagged and released. Because of bug in wc_close, and sice no other bugs have been reported for a week, I plan to tag the 1.2.12 tomorrow morning, 10:00 GMT. Any objections? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging 1.2.12
Hey, I thing we are ready to build a release. The 1.2.11 have little bugs but was stable and now the bug fix 1.2.12 coming soon. I have test a couple of weeks the cvs head and thing it is a good release. A lot of people waiting for it. Thats my problem :-) Peter Mladen Turk schrieb: William A. Rowe, Jr. wrote: Any objections? Yes, one. What's the rush? One week is not enough time for folks to really stress 1.2.11, and this sure looks to me, from the pace of supposedly stable releases, as though mod_jk has become much less trustworthy, and much more suspect, for a stable production install. Well, I really can not tell what someone might think eventually. You are saying exactly the same thing (what's the rush) for the every release ;). But OK, we can wait for another week or couple of them. No problem. 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: Code Submission - Wild Card Aliases
Great news, can you post your new code that we can test it also? Many thanks Peter George Sexton schrieb: The measurement was calculated by taking the median reading of 10 consecutive executions. Just for your edification they were: New Code: 7373ms 7395ms 7383ms 7370ms 7384ms 7385ms 7395ms 7376ms 7378ms 7393ms Median: 7383.5ms Old code: 8561ms 8560ms 8771ms 8774ms 8771ms 8767ms 8860ms 8775ms 8775ms 8782ms Median: 8772.5ms Difference: 1389ms ~ 15.8% improved My mistake for not wanting to bore the list with minutiae. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- The original code you submitted looks quite bad so I don't trust your measurements at all, sorry. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] - benchmark on APR stuff
Thanks it works with the cvs head from jmeter (2.1) Peter Jason Brittain schrieb: Peter Rossbach wrote: Hey Peter, I have download and install Jmeter 2.0.3 and want load your testplans, but I got this error: 2005/05/03 06:45:43 INFO - jmeter.gui.action.Load: Loading file: D:\peterlintestplan\concurrent_1.jmx 2005/05/03 06:45:43 ERROR - jmeter.save.SaveService: Problem loading part of file org.apache.avalon.framework.configuration.ConfigurationException: No attribute named class is associated with the configuration element testelement at - [snip] What I made wrong? Apparently JMeter 2.0.3 is too old. :) I downloaded and built JMeter from CVS head, and that allowed me to load and run his test plans. Cheers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Submission - Wild Card Aliases
Hey Remy and George, I have analyse the patch and find it very usefull. When you have a lot of customer at one tomcat with a lot of virtual hosts and customer can change there subdomains mapping, this * Alias Feature is a great help. I have the next two week limit time, but I thing we can integrate the patch. The performance reduction is very small at production use case/envs. Vote +1 to add this patch with small modifications. . Peter Remy Maucherat schrieb: George Sexton wrote: I have completed the coding in o.a.t.u.http.mapper.Mapper to implement wild-card aliases. If a request for a host is made, and that host is not found, the code tests the host and aliases list and looks for wild-cards. So, a host name of www.mydomain.com would match an alias of *.mydomain.com. This additional level of testing is only done if the the presented host name is not found in the standard host list. Once a host is found via wild-card, it is added to the standard host list. Subsequent requests for that host name will find it via the standard search mechanism. As part of the conversion, I re-worked the test harness code and expanded it to be a lot more complete. The output of the new test harness with the unmodified Mapper code matches identically the output of the modified mapper. IOW, I'm 99% confident that the behavior of the Mapper matches the old Mapper. The time differential between the two runs is around 500ms over 1 million iterations. I.E. the original code runs in 8000 ms for 1 million iterations of the testing code, while the new code takes 8500ms. The new code adds approximately 0.05 % to the time for a lookup. I am running the modified mapper code with 5.5.9 on an installation that has 40 hosts configured and it seems to be working correctly. I'd really appreciate it if a committer would get this added to the source tree. The complete modified Mapper.java file can be downloaded from: http://www.mhsoftware.com/~gsexton/Mapper.java If a decision is made to reject this patch, I'd appreciate knowing why. If there's something wrong from a coding or style perspective, I'd be happy to fix things. -1 for lower performance and questionable use case. (I didn't get the patch, but I don't really wish to) 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: Code Submission - Wild Card Aliases
I also thing that the impact is small but the feature is very usefull. A connector option enableAliasWildcardMatching was a good idea. +1 for the patch again. Peter George Sexton schrieb: 0.05% lower is hardly a sufficient reason to reject this. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 8:04 AM To: Tomcat Developers List Subject: Re: Code Submission - Wild Card Aliases George Sexton wrote: I have completed the coding in o.a.t.u.http.mapper.Mapper to implement wild-card aliases. If a request for a host is made, and that host is not found, the code tests the host and aliases list and looks for wild-cards. So, a host name of www.mydomain.com would match an alias of *.mydomain.com. This additional level of testing is only done if the the presented host name is not found in the standard host list. Once a host is found via wild-card, it is added to the standard host list. Subsequent requests for that host name will find it via the standard search mechanism. As part of the conversion, I re-worked the test harness code and expanded it to be a lot more complete. The output of the new test harness with the unmodified Mapper code matches identically the output of the modified mapper. IOW, I'm 99% confident that the behavior of the Mapper matches the old Mapper. The time differential between the two runs is around 500ms over 1 million iterations. I.E. the original code runs in 8000 ms for 1 million iterations of the testing code, while the new code takes 8500ms. The new code adds approximately 0.05 % to the time for a lookup. I am running the modified mapper code with 5.5.9 on an installation that has 40 hosts configured and it seems to be working correctly. I'd really appreciate it if a committer would get this added to the source tree. The complete modified Mapper.java file can be downloaded from: http://www.mhsoftware.com/~gsexton/Mapper.java If a decision is made to reject this patch, I'd appreciate knowing why. If there's something wrong from a coding or style perspective, I'd be happy to fix things. -1 for lower performance and questionable use case. (I didn't get the patch, but I don't really wish to) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Submission - Wild Card Aliases
Hey George,
the Mapper is create inside Connector.
I think we must setup the new Connector option before we start the
MapperListener inside Connector.start()
add connector and Mapper property enableAliasWildcardMatching at Connector
o.a.c.connector.Connector L1076
if( this.domain != null ) {
mapper.setEnableAliasWildcardMatching
(this.enableAliasWildcardMatching );
mapperListener.setDomain( domain );
//mapperListener.setEngine( service.getContainer().getName() );
mapperListener.init();
...
}
Peter
George Sexton schrieb:
OK, if I'm hearing (almost everyone) the issues to address are:
1) Sync getHosts() and getContextNames()
2) Figure out some sort of rate-limiting mechanism to limit DOS -
Perhaps this should be configurable with # 3 below.
3) Make wild card matching a configurable option.
A question for Yoav - At what entity should this mapper option be set ?
Engine? Service?
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-Original Message-
From: Yoav Shapira [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 03, 2005 9:02 AM
To: 'Tomcat Developers List'
Subject: RE: Code Submission - Wild Card Aliases
Hi,
The performance impact is not that big. If it was a
configurable option,
e.g. enableAliasWildcardMatching, turned off by default, I'd
be OK with it.
Yoav
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 03, 2005 10:04 AM
To: Tomcat Developers List
Subject: Re: Code Submission - Wild Card Aliases
George Sexton wrote:
I have completed the coding in o.a.t.u.http.mapper.Mapper
to implement
wild-card aliases.
If a request for a host is made, and that host is not
found, the code
tests
the host and aliases list and looks for wild-cards.
So, a host name of www.mydomain.com would match an alias of
*.mydomain.com.
This additional level of testing is only done if the the
presented host
name
is not found in the standard host list. Once a host is
found via wild-
card,
it is added to the standard host list. Subsequent
requests for that host
name will find it via the standard search mechanism.
As part of the conversion, I re-worked the test harness code and
expanded it
to be a lot more complete. The output of the new test
harness with the
unmodified Mapper code matches identically the output of
the modified
mapper. IOW, I'm 99% confident that the behavior of the
Mapper matches
the
old Mapper.
The time differential between the two runs is around 500ms over 1
million
iterations. I.E. the original code runs in 8000 ms for 1 million
iterations
of the testing code, while the new code takes 8500ms. The
new code adds
approximately 0.05 % to the time for a lookup.
I am running the modified mapper code with 5.5.9 on an
installation that
has
40 hosts configured and it seems to be working correctly.
I'd really appreciate it if a committer would get this
added to the
source
tree.
The complete modified Mapper.java file can be downloaded from:
http://www.mhsoftware.com/~gsexton/Mapper.java
If a decision is made to reject this patch, I'd
appreciate knowing why.
If
there's something wrong from a coding or style
perspective, I'd be happy
to
fix things.
-1 for lower performance and questionable use case.
(I didn't get the patch, but I don't really wish to)
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk configure failover
Hey Glenn, a hot standby is very easy. You confgure your nodes inside a loadbalancer and then disabled some nodes. Very best is, you can configure this with the new lb status worker. Example: IfModule !mod_jk.c LoadModule jk_module modules/mod_jk.so /IfModule JkWorkerProperty worker.list=loadbalancer,jkstatus JkWorkerProperty worker.node01.type=ajp13 JkWorkerProperty worker.node01.port=7201 JkWorkerProperty worker.node01.host=localhost JkWorkerProperty worker.node01.cachesize=150 JkWorkerProperty worker.node01.cache_timeout=600 JkWorkerProperty worker.node02.type=ajp13 JkWorkerProperty worker.node02.port=7202 JkWorkerProperty worker.node02.host=localhost JkWorkerProperty worker.node02.cachesize=150 JkWorkerProperty worker.node02.cache_timeout=600 JkWorkerProperty worker.node02.disabled=false JkWorkerProperty worker.loadbalancer.type=lb JkWorkerProperty worker.loadbalancer.balance_workers=node01,node02 JkWorkerProperty worker.jkstatus.type=status JkLogFile logs/mod_jk.log JkLogLevel info # unix only JkShmMem logs/mod_jk.shm JkMountFile conf/uriworkermap.properties JkMount /jkstatus jkstatus At mod_jk 1.2.11 exists also a stopped flag to setup a cold standby. s. http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html regards Peter Glenn Nielsen schrieb: Now that local worker is gone from mod_jk how can you configure two app servers where you want one to be the primary and the second one to be used for automatic failover only if the primary is in an error state? I tried setting lbfactor=1 on the primary and lbfactor=0 on the failover worker but mod_jk sets lbfactor=1 if you configure a value 1. Thanks, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk configure failover
Hey Glenn,
yes, disabled means, only that no new sessions send to a worker, but
request with
JSESSIONID send to the worker and
stopped means, no more requests send to a worker.
Peter
Glenn Nielsen schrieb:
On Mon, May 02, 2005 at 06:17:50PM +0200, Mladen Turk wrote:
Glenn Nielsen wrote:
Now that local worker is gone from mod_jk how can you configure
two app servers where you want one to be the primary and the
second one to be used for automatic failover only if the primary
is in an error state?
Use 'disabled' flag for standby worker with 'redirect' to that worker.
worker.w1.disabled=False
worker.w1.redirect=w2
worker.w2.disabled=True
You can even redirect to the 'domain' or group of workers.
Thanks.
This seems to be a roundabout way to setup failover on error
and confuses what disabled=true means.
So let me get this straight, please correct me if I am wrong.
As of 1.2.11:
If disabled=true for a worker that worker can still receive
requests if:
a) Another real worker has redirect={disabled worker}
b) A request has a JSESSIONID with the disabled worker jvmroute
If you really want to disable a worker completely you need to use
the new stopped=True property?
Regards,
Glenn
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Code Submission - Wild Card Aliases
Hey Geroge,
I review the mapper patch. Cool!
I think getHosts is a little bit strange:
What you think about this:
public String[] getHosts() {
Host[] hosts ;
synchronized(this) {
hosts=new Host[hmHosts.size()];
hosts=(Host[])hmHosts.values().toArray(hosts);
}
String[] hostNames=new String[hmHosts.size()];
for ( int i = 0; i hosts.length; i++ ) {
hostNames[i] = hosts[i].name;
}
return hostNames ;
}
I thing sync is needed. I miss that also at orginal mapper. The host
values get array you also coded at getContextNames().
Can we change getHost to be protected.
Have you wrote junit testcases for the Mapper ?
Please, extract the testcode. I hate those test code inside
production code :-)
I find you patch very usefull!
Thanks
Peter
George Sexton schrieb:
I have completed the coding in o.a.t.u.http.mapper.Mapper to implement
wild-card aliases.
If a request for a host is made, and that host is not found, the code tests
the host and aliases list and looks for wild-cards.
So, a host name of www.mydomain.com would match an alias of *.mydomain.com.
This additional level of testing is only done if the the presented host name
is not found in the standard host list. Once a host is found via wild-card,
it is added to the standard host list. Subsequent requests for that host
name will find it via the standard search mechanism.
As part of the conversion, I re-worked the test harness code and expanded it
to be a lot more complete. The output of the new test harness with the
unmodified Mapper code matches identically the output of the modified
mapper. IOW, I'm 99% confident that the behavior of the Mapper matches the
old Mapper.
The time differential between the two runs is around 500ms over 1 million
iterations. I.E. the original code runs in 8000 ms for 1 million iterations
of the testing code, while the new code takes 8500ms. The new code adds
approximately 0.05 % to the time for a lookup.
I am running the modified mapper code with 5.5.9 on an installation that has
40 hosts configured and it seems to be working correctly.
I'd really appreciate it if a committer would get this added to the source
tree.
The complete modified Mapper.java file can be downloaded from:
http://www.mhsoftware.com/~gsexton/Mapper.java
If a decision is made to reject this patch, I'd appreciate knowing why. If
there's something wrong from a coding or style perspective, I'd be happy to
fix things.
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] - benchmark on APR stuff
Hey Peter, I have download and install Jmeter 2.0.3 and want load your testplans, but I got this error: 2005/05/03 06:45:43 INFO - jmeter.gui.action.Load: Loading file: D:\peterlintestplan\concurrent_1.jmx 2005/05/03 06:45:43 ERROR - jmeter.save.SaveService: Problem loading part of file org.apache.avalon.framework.configuration.ConfigurationException: No attribute named class is associated with the configuration element testelement at - at org.apache.avalon.framework.configuration.DefaultConfiguration.getAttribute(DefaultConfiguration.java:279) at org.apache.jmeter.save.SaveService.createTestElement(SaveService.java:960) at org.apache.jmeter.save.SaveService.generateNode(SaveService.java:1137) at org.apache.jmeter.save.SaveService.loadSubTree(SaveService.java:933) at org.apache.jmeter.gui.action.Load.doAction(Load.java:97) at org.apache.jmeter.gui.action.ActionRouter.performAction(ActionRouter.java:81) at org.apache.jmeter.gui.action.ActionRouter.access$000(ActionRouter.java:44) at org.apache.jmeter.gui.action.ActionRouter$1.run(ActionRouter.java:62) at java.awt.event.InvocationEvent.dispatch(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) What I made wrong? Peter Peter Lin schrieb: I haven't been able to run the benchmarks so far due to BSOD on my laptop. I suspect SP2, since I just installed it friday and now I get IRQ errors related to the network interface. the test plan is in my apache directory, can someone else run the benchmarks until I figure out how to fix this stupid BSOD nightmare? http://cvs.apache.org/~woolfel/native_testplans.zip peter lin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Hey Mladen, Mladen Turk schrieb: Peter Rossbach wrote: Hey Mladen, I used the tomcat at cluster mode, but your answer is a little bit to easy. Sticky session is the only way for the most applications to be consistens. Session replication is only a secondary feature when failure occured. Why we can't add a flag that deactive a worker or change the semantic of disable? Then all request goes to the other replication members in a cluster domain and restarting is easy without risk and waiting time. Are you sure this is absolute necessity? YES! We monitor the cluster and when one member is not accessiable or throw Out of memory Exception, the node was automaticly restart. Also this mode is fine for minor node or application configuration update. It is not usefull for complete new deployment, when serialized classes changed :-) I agree something like that might be usable on a development server, but on a production server? I'm not sure if your users will be happy with loosing sessions in a middle of a transaction or order. Hmm, but the fallback server (same cluster domain) has the sessions at this moment and the user see nothing from the switch. This suggestion is the result of my last two week pre production tests and customer discussions. Again, disable works as expected. It will preserve exiting sessions until session times out. When all existing sessions are gone, then you can do with that node what ever you wish. If you do not wish to wait, then simply disable and kill that instance. The existing sessions will be failovered to another node with loosing session data. But at cluster the session are replicated, and we must not wait. Please, can we add a flag active=false/true to test my idea. What do you thing I can start a quick experiment and send you the diffs for reviewing? I see no reason whatsoever for introducing another 'immediate disable' flag to the worker. I hope my description help do understand my suggestion better. Regards, Mladeb. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Hey Mladen, I have made successfull a test implementation to deactived a worker. I works very fine for me at windows. Now made a second test under apache 2.0.54 and Linux 9.3 with worker and prefork MPM. I think in two hour I am ready to checkin the change. :-) Peter Peter Rossbach schrieb: Hey Mladen, Mladen Turk schrieb: Peter Rossbach wrote: Hey Mladen, I used the tomcat at cluster mode, but your answer is a little bit to easy. Sticky session is the only way for the most applications to be consistens. Session replication is only a secondary feature when failure occured. Why we can't add a flag that deactive a worker or change the semantic of disable? Then all request goes to the other replication members in a cluster domain and restarting is easy without risk and waiting time. Are you sure this is absolute necessity? YES! We monitor the cluster and when one member is not accessiable or throw Out of memory Exception, the node was automaticly restart. Also this mode is fine for minor node or application configuration update. It is not usefull for complete new deployment, when serialized classes changed :-) I agree something like that might be usable on a development server, but on a production server? I'm not sure if your users will be happy with loosing sessions in a middle of a transaction or order. Hmm, but the fallback server (same cluster domain) has the sessions at this moment and the user see nothing from the switch. This suggestion is the result of my last two week pre production tests and customer discussions. Again, disable works as expected. It will preserve exiting sessions until session times out. When all existing sessions are gone, then you can do with that node what ever you wish. If you do not wish to wait, then simply disable and kill that instance. The existing sessions will be failovered to another node with loosing session data. But at cluster the session are replicated, and we must not wait. Please, can we add a flag active=false/true to test my idea. What do you thing I can start a quick experiment and send you the diffs for reviewing? I see no reason whatsoever for introducing another 'immediate disable' flag to the worker. I hope my description help do understand my suggestion better. Regards, Mladeb. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Mladen Turk schrieb: Peter Rossbach wrote: Are you sure this is absolute necessity? But at cluster the session are replicated, and we must not wait. Please, can we add a flag active=false/true to test my idea. What do you thing I can start a quick experiment and send you the diffs for reviewing? Well I'm -0 on the subject, because I think it's useless. You can of course commit what you think is appropriate, of course if that will not break the existing functionality. Yes, I am on testing this. I hope you can help two test it also. Many thanks! I think that the desired functionality can be achieved with status worker that will put the worker in error and disabled state at once, but of course you can add a new flag for that. OK, I have add a deactived flag. IMO adding that 'active' flag to the workers.properties will only rise the fuzziness regarding to the 'disabled' flag. Once more, all the features you are searching for, can be achieved using the current configuration. Simply use the JMX and pause your node. Hmm, but curently the connection are keepalive. I see that only new connection drop, but the active connection are still alive. At my test the request don't stop. But if you think that is realy needed then rename the 'disable' to be the function of your proposed 'active' and add a new flag 'standby' or 'pause' that will act as current negation of the disabled flag. I name the flag deactived. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Hey Malden, Mladen Turk schrieb: Peter Rossbach wrote: I name the flag deactived. Look, can we prolong that to the next release? I would really appreciate that, because the 1.2.11 should be a bug-fix release. Changing that would break the current configurations, and IMO we could think of something smarter in the future. The change not break the configuration, it extend the configuration. I also see that this flag make the configruation much more compilcate and that was really bad. But I can send you my changes before commit and you can have the descision it include inside 1.2.11 or not. Adding an extra checkbox to the status worker for putting the worker in error and disabled state at once, should do a trick I think. Any other directives should be carefully selected thought. Yes, I have also made the flag configurable, but I find it a little bit strange to set the error flag. But this was my first idea. Please review my changes. Better ideas welcome :-) Currently I have test all worker modes at windows, but now I have a compilation problem at suse 9.3 the compile can't jk_connect.c jk_connect.c: In function 'jk_shutdown_socket' : jk_connect.c:485: error 'SD_SEND' undeclared (first use in this function) jk_connect.c:484: error (Each unde ... How can I find the missing declaration of SD_SEND? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Thanks, stopped is a very good name! Peter Georg v. Zezschwitz schrieb: On Tue, Apr 26, 2005 at 01:10:13PM +0200, Peter Rossbach wrote: I name the flag deactived. Sorry for a lurkers comment from the background (and I am neither a native speaker). But I guess it should be named: deactivated not deactived Also, based on Mladens points, what about a more strict name, like: stopped? Kind regards, Georg v.Zezschwitz - 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]
Can't compile jk nativ connector under Suse 9.3
I have a jk native compilation problem at suse 9.3 with the current CVS HEAD. Can't compile jk_connect.c jk_connect.c: In function 'jk_shutdown_socket' : jk_connect.c:485: error 'SD_SEND' undeclared (first use in this function) jk_connect.c:485: error (Each unde ... How can I find the missing SD_SEND declaration? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't compile jk nativ connector under Suse 9.3
... (cached) yes appending configuration tag F77 to libtool checking for test... /usr/bin/test checking for rm... /bin/rm checking for grep... /usr/bin/grep checking for echo... /bin/echo checking for sed... /usr/bin/sed checking for cp... /bin/cp checking for mkdir... /bin/mkdir checking for snprintf... yes checking for vsnprintf... yes checking for flock... yes checking whether to use SO_RCVTIMEO with setsockopt()... no checking whether to use SO_SNDTIMEO with setsockopt()... no need to check for Perl first, apxs depends on it... checking for perl... /usr/bin/perl building connector for apache-2.0 checking for target platform... unix no apache given configure: creating ./config.status config.status: creating Makefile config.status: creating apache-1.3/Makefile config.status: creating apache-1.3/Makefile.apxs config.status: creating apache-2.0/Makefile config.status: creating apache-2.0/Makefile.apxs config.status: creating common/Makefile config.status: creating common/list.mk config.status: creating jni/Makefile config.status: creating common/portable.h config.status: common/portable.h is unchanged config.status: executing depfiles commands [EMAIL PROTECTED]:~/develop/tomcat/jakarta-tomcat-connectors/jk/native make Making all in common make[1]: Entering directory `/home/peter/develop/tomcat/jakarta-tomcat-connectors/jk/native/common' /bin/sh /home/peter/server/apache2/build/libtool --silent --mode=compile gcc -I/home/peter/server/apache2/include -g -O2 -g -O2 -pthread -DHAVE_APR -I/home/peter/server/httpd-2.0.54/srclib/apr/include -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /usr/java/jdk1.5.0_02/include -I /usr/java/jdk1.5.0_02/include/ -c jk_connect.c jk_connect.c: In function `jk_shutdown_socket': jk_connect.c:485: error: `SD_SEND' undeclared (first use in this function) jk_connect.c:485: error: (Each undeclared identifier is reported only once jk_connect.c:485: error: for each function it appears in.) make[1]: *** [jk_connect.lo] Fehler 1 make[1]: Leaving directory `/home/peter/develop/tomcat/jakarta-tomcat-connectors/jk/native/common' make: *** [all-recursive] Fehler 1 Peter William A. Rowe, Jr. schrieb: grep -r SD_SEND /usr/include/* grep -r SD_SEND /usr/local/include/* ? Tell us where it's hidden and it's more likely we can come up with an appropriate patch. Any ./configure output would also be helpful. At 01:01 PM 4/26/2005, Peter Rossbach wrote: I have a jk native compilation problem at suse 9.3 with the current CVS HEAD. Can't compile jk_connect.c jk_connect.c: In function 'jk_shutdown_socket' : jk_connect.c:485: error 'SD_SEND' undeclared (first use in this function) jk_connect.c:485: error (Each unde ... How can I find the missing SD_SEND declaration? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK Releasing 1.2.11/1.2.12
Hey Mladen, that is a very shot time period for testing. I can start some test not before monday next week, but I setup a new server today a start with testing with jk cvs head. Thanks for write documentation of the status worker :-) Sorry, but the current cluster implementation changes and testing consume a lot of my time. Peter Mladen Turk schrieb: Hi, There has been some major bug fixes against JK1.2.10. Critical: 34357 and 34423. Not so critical: 34358, 33843, 34558, 34577, and some not reported. See: http://jakarta.apache.org/tomcat/connectors-doc/changelog.html for details. My plan is to release the 1.2.11 tomorrow as dev version, and then after 3 days if no bugs found, make a 1.2.12 release, and vote as stable. Any objections? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk problem with domain clustering and restart node or application
One of my problems with clustering are: Szenario: - three domains of cluster with two or three tomcat nodes - have more then one application at this cluster - all nodes server the same application set - sticky session on Goal - restart an application at single node Probleme - How can configure that lb stop traffic for a spezial worker/node and for an single application? my idea: config via uriworkermap.properties -/myapps/*=node1 or -/myapps/*=loadbalancer.node1 /myapps/*=loadbalancer - Disable worker stop only the traffic for new session requests, but not for all requests. new worker config worker.node1.active=false ( The semantic of disable is a little bit strange for Sticky Session mode) Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Hello Mladen , yes Remy, we have currently no chance inside tomcat. :-( My szenario is really important when automatic alive monitoring detect that inside an application or node is something wrong (Out Of Memory Exception, all thread hang, detect a deadlock or other nice application relevant bugs/feature) What I want is, that we can stop request sending from mod_jk side at a single node. Why we can't stop all requests for a worker, when we set a flag worker.node1.active=false ? Ok, then no application on this node get request, but we can control the tomcat restart. Peter Remy Maucherat schrieb: Mladen Turk wrote: I think that this is the Tomcat responsibility. If inside redeployment, it should hold the request until finished. For mod_jk you can set the socket_timeout that will cause the failover to another worker (if redeployment takes more then 60 seconds). There is no way to hold a particular request. 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: JK Releasing 1.2.11/1.2.12
OK, I read the changes and I also want a next release :-) Peter PS: Start testing with the current code base at windows xp and suse 9.3 Mladen Turk schrieb: Peter Rossbach wrote: that is a very shot time period for testing. Well, some of the things are really critical, so that's the reason. I can start some test not before monday next week, but I setup a new server today a start with testing with jk cvs head. Well, It will be not be advertised as stable until enough votes are collected. This of course does not prevent users from using the new version that fixes the present bugs. We can always release a version and if not voted as stable, just bump to another one. The current head contains some significant bug fixes, and if some others get found during the testing period (this week basically), we can easily go to the next version. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Hmm, that disabling feature not work at my configuration. I have made a test with current Tomcat head and mod_jk 1.2.10. === worker.list=lb,status worker.node1.port=9012 worker.node1.host=127.0.0.1 worker.node1.type=ajp13 worker.node1.cachesize=200 worker.node1.cache_timeout=60 worker.node1.disabled=false worker.node1.domain=A worker.node2.port=9022 worker.node2.host=127.0.0.1 worker.node2.type=ajp13 worker.node2.cachesize=200 worker.node2.cache_timeout=60 worker.node2.disabled=false worker.node2.domain=A worker.lb.balance_workers=node1,node2 worker.lb.type=lb worker.status.type=status === Setup to tomcat behind Apache 2.0.53 ( Windows XP) When I open browser send a request that open a session. Verify that next request goes to the same tomcat. disable tomcat/worker from which node request coming. Request again the same request and see that request goes to the same worker. Next test with remove the domain feature, and also test it with a fresh compile cvs head, but also it not working. What is wrong at my mod_jk configuration? Peter Mladen Turk schrieb: Peter Rossbach wrote: Hello Mladen , What I want is, that we can stop request sending from mod_jk side at a single node. Why we can't stop all requests for a worker, when we set a flag worker.node1.active=false ? Ok, then no application on this node get request, but we can control the tomcat restart. You have woker.node1.disabled=True directive. It will disable the worker in case it's member of load balancer, and no furher requests will took place on it unless referenced by some other worker with 'redirect' and not in error state. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk problem with domain clustering and restart node or application
Hey Mladen, I used the tomcat at cluster mode, but your answer is a little bit to easy. Sticky session is the only way for the most applications to be consistens. Session replication is only a secondary feature when failure occured. Why we can't add a flag that deactive a worker or change the semantic of disable? Then all request goes to the other replication members in a cluster domain and restarting is easy without risk and waiting time. Peter Mladen Turk schrieb: Mladen Turk wrote: Peter Rossbach wrote: Hmm, that disabling feature not work at my configuration. worker.node2.domain=A You don't need a domain unless you have a session replication Or you can just set jvmRoute=A on each tomcat instance, make session replication, and then your config will work instantly when you disable one of the workers. 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: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hey Mark, I roll it back. Thanks Peter Mark Thomas schrieb: Peter, One of your related changes (http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/modules/cluster/build.xml?r1=1.14r2=1.15diff_format=h) has broken the 5.5 build on 1.4 JDKs :( Can you roll it back or commit an alternative please? Cheers, Mark [EMAIL PROTECTED] wrote: pero2005/04/22 13:38:38 Modified:webapps/docs changelog.xml Log: redesign DeltaManager restart under load Revision ChangesPath 1.291 +3 -1 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.290 retrieving revision 1.291 diff -u -r1.290 -r1.291 --- changelog.xml15 Apr 2005 20:15:17 -1.290 +++ changelog.xml22 Apr 2005 20:38:38 -1.291 @@ -146,7 +146,9 @@ update Refactor DeltaManager: - createSession call now ManagerBase super class method - - extract some long methods (pero)+ - extract some long methods + - send GET_ALL_SESSION with session blocks + - don't sync sessions map when send all sessions (pero) /update update Add developer actions at to-do.txt (Proposal of changes) (pero) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session ManagerBase.java
I also thing, made this check is better, as thing the generator work as aspected !! vote +1 to add the session duplication check again. Peter Bill Barker schrieb: Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: pero2005/04/15 13:15:45 Modified:catalina/src/share/org/apache/catalina Cluster.java catalina/src/share/org/apache/catalina/session ManagerBase.java Log: Refactoring and redesign cluster +// FIXME WHy we need no duplication check? Because it would mean id generation is extremely insecure, so we would have more urgent problems ;) I agree with Remy. Before we had the duplication check, we *did* get reports of duplicate ids. I'm -1 for the ManagerBase patch. 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: Tomcat and APR
At last week I use very successfull the httperf load tool to simulate sessions request. With httperf you can generate high load and it is easy to configure. You can configure think time between requests. But with session handling on, we see some corrupted requests. http://www.hpl.hp.com/personal/David_Mosberger/httperf.html Peter Mladen Turk schrieb: Peter Lin wrote: yeah, I can do that. ... I assume if i grab the nightly for 5.5.x and APR1.1.x I should be ready to go. In the event I need some assistance, you going to be around Mladen :) ? Well, not at the midnight like your post was, but I'm sure it wasn't a midnight at your time zone :). I've done testing on SLES9/64 with JDK5 and current apr release from apache (apr-1.1.1). The performance is equal or APR is slightly faster, but what's more important is the scalability for keep-alive connections. Now you can have hundreds of keep-alive connections without going over the thread limit. Not sure how to test that, but I suppose that test for standard installation should include much higher maxThreads value then for APR implementation. One other thing. Use some unix for Tomcat, or you will need to patch the APR for windows. The reason is that the APR uses standard windows FD_SETSIZE that is 64. I did recompile the apr with setting the FD_SETSIZE to 16384 before including winsock2.h, so we don't have that limit. I did that because I thought that unixes has unlimited FD_SETSIZE, but it seems that the common value is 1024, so that is probably our limit for now. Think that we'll need multiple Poller threads if higher number is required. Anyhow don't test more then 1024 concurrent users at the moment, or 64 if using vanilla APR on windows. More about testing: Right now the code waits for 50ms (configurable or will be) after the request for another keep-alive request, and then goes to the poller if the client didn't provide the request. So that would be valuable to test actually. Let's say that client sends each request with keep-alive in a 100+ ms rate. Not sure if JMeter can make a pause between the requests, but ab can not, and that is what we need to measure basically, since it's more close to the real-world then simply hitting the Tomcat in a loop. 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: Cluster fixes - Need Coordination of work
but please queue all messages for us. We also queue all message from local node. = resume: Send all nodes that the now can send the queue and we start also the sending. Hmm: The async senders can handle it Currently the async Socket Sender stop the thread when you call disconnect, when you call connect a new thread starts and all queued message are send. - PooledSocketSender - extend JMX stats - pause/resume sockets DeltaManager - expire sessions The processExpire send for every session one message All 60 Sec the cluster send a lot of those messsages. = Better calc all sessions an send on big expire message package. - Restarting node szenario is flacky You wait for GETALLMessage and other node send Sessions Events. (BAD) You can get a Session Delta before Session exists = I thing before State is not transfer we mus Queue those messages from other cluster nodes. - Send All Session to more then one messages 1000 Sessions per message After the complete active sessions transfer send a spezial State Transfer message. documentation Wrote a new How to and add sample config = I have implement a very fine cluster template and checkin it in this weekend. Your ClusterSessionListener server.xml change is not needed. At cluster starts a ClusterSessionListener was created, when no other listener is configured. Peter Filip Peter Rossbach wrote: Yes, I have change a lot and it is time to test and stabilze the code. s. to-do.txt for more The current cluster code with 5.5.9 fix pack work very well I testet the fix under very high load last week Peter - Great that you also start to look inside the code. Filip Hanik - Dev Lists schrieb: I am going through the cluster code right now and will be adding fixes along the way. I think the development of this code has focused more on features than stability, so I would like to ask that for the next period, lets focus on the stability and get this beast back in shape again. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cluster fixes
Yes, I have change a lot and it is time to test and stabilze the code. s. to-do.txt for more :-) The current cluster code with 5.5.9 fix pack work very well I testet the fix under very high load last week Peter - Great that you also start to look inside the code. Filip Hanik - Dev Lists schrieb: I am going through the cluster code right now and will be adding fixes along the way. I think the development of this code has focused more on features than stability, so I would like to ask that for the next period, lets focus on the stability and get this beast back in shape again. Filip - 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session ManagerBase.java
Yes, this was the only different between DeltaManager and ManagerBase. What we do? remove the comment or detect so strange things? Peter Remy Maucherat schrieb: [EMAIL PROTECTED] wrote: pero2005/04/15 13:15:45 Modified:catalina/src/share/org/apache/catalina Cluster.java catalina/src/share/org/apache/catalina/session ManagerBase.java Log: Refactoring and redesign cluster +// FIXME WHy we need no duplication check? Because it would mean id generation is extremely insecure, so we would have more urgent problems ;) 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: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Yes your arguments are correct, but this method is very usefull to test the cluster implemention, a very important use case. :-) Thanks Peter Jason Brittain schrieb: subsection name=Cluster changelog add +DeltaManager has now JMX expireAllLocalSessions and processExipre operation +for better cluster node shutdown handling (pero) + /add Why would we want to invalidate all sessions active on one node of the cluster when bringing it down, as opposed to replicating the session data out to one or more other available nodes in the cluster and letting the other machine(s) handle them? Or, did you add these operations/methods for cases where the cluster is configured to keep any given session on exactly one node? (I wouldn't think so, since in that case what would the session clustering really be useful for?) Just curious.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.9 Stability
Hi, I have add my 5.5.9 clustering fix pack to the following bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=34389 Vote for stable 5.5.9 [X] All clustering user can extract the fix pack and all is working well. :-) Peter Yoav Shapira schrieb: Hi, Ok, this give me and Filip time for real stability testing and review the 5.5.10 codebase. I also package my fixes to the 5.5.9 codebase for some test user as bug report.. I'll let Yoav decide what he wants to do with all these builds before he gets married (congratulations ;)). I'm very happy to not be the release manager and have to make the tough decisions :) Go Yoav ! Peter, when you have a Bugzilla item and a cluster fix/test package attached to that item, please let us know. At that time I'll send out the vote results, calling 5.5.9 beta and nothing that this issue (and I'll provide a link to bugzilla) is the only thing preventing 5.5.9 from being stable, and that users not needing/using clustering should consider 5.5.9 stable. Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA [EMAIL PROTECTED] / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.9 Stability
Thanks, and I hope Filip has time to review and test it. Peter. PS: I am now start to port the fix to my changed 5.5.10 code. Remy Maucherat schrieb: Peter Rossbach wrote: I have add my 5.5.9 clustering fix pack to the following bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=34389 Wow, it's great you could come up with a patch for 5.5.9 so quickly :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.9 Stability
Hey, the problem is arround the keep a live handling code and the auto reconnect at SimpleTcpCluster. One thread can say: I drop the connection and open new one, then start transfer message and wait for ack. Other thread comes and see ups. the connection is not there. ( Arrg missing sychronized). I open a new socket and close the old current use socket. Under Suse Linux 9.1, the first thread wait for keepAlive timeout (60 sec). BAD!!! = Asnyc mode the queue grow very fast. Sometimes all other nodes have the same problem and the complete cluster standing still. Nothing todo wait for ACK I am made very limited testing the effects at sync,pooled mode. I preferred the async modes. I have merge my fix at the 5.5.10 CVS Head Basis. Currently my customer start a weekend load test. I also merge the changes at 5.5.9 Basis. Both version needs testing and documentation, but my time and ressource are limited. Need help, setup clusters and start loading tests. I start to open a bug report for better community discussion and add my fix pack for testing. build-src bin pack I must review my changes and document my szenario. Than Filip can start to review the changes and testing the clustering. Thanks for you help. :-) My customers needs the new 5.5.9 Release. The best thing is, we package a separate patch-cluster-fix and mark 5.5.9 as beta. Peter Filip Hanik - Dev Lists schrieb: Hi Peter, what's up with the cluster code? I will have some time to load test and debug any problems you might have, also, do you have problems on the synced-pooled setting, or on all connectors? Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.9 Stability
Congratulation, too! Peter Yoav Shapira schrieb: Hi, The problem is that clustering only patches in HEAD may pick up incompatible changes, like the Session.getId patch. We also shouldn't do a new 5.5.10 tag based on HEAD, as it would pick up the risky stuff. Maybe one solution would be to do a new 5.5.9 build, and reverting clustering (aka, everything in the cluster folder) to the 5.5.8 tag. Would that work out well enough ? I think that's the best approach. We can call it 5.5.9-beta when released, and have a stability vote right afterwards. I'll be incommunicado from the 14th through the 20th or so: I'm getting married on the 17th ;) Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA [EMAIL PROTECTED] / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.9 Stability
I thing the instability is also included at 5.5.7 clustering. Are you certain reverting to 5.5.8 clustering is not possible (meaning that it contains the same problems - or worse - as 5.5.9) ? If so, I think we need to forget about clustering stability for now, and mention that it is experimental in this build. Ok, this give me and Filip time for real stability testing and review the 5.5.10 codebase. I also package my fixes to the 5.5.9 codebase for some test user as bug report.. Peter Remy Maucherat schrieb: Peter Rossbach wrote: My customers needs the new 5.5.9 Release. The best thing is, we package a separate patch-cluster-fix and mark 5.5.9 as beta. Given the state of HEAD, and given some the 5.5.7 issues, I would like 5.5.9 to be stable. This means we would need a way to fix 5.5.9 without new major patches (which may work well for your customer, but this is still very limited testing) ;) Are you certain reverting to 5.5.8 clustering is not possible (meaning that it contains the same problems - or worse - as 5.5.9) ? If so, I think we need to forget about clustering stability for now, and mention that it is experimental in this build. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.5.9 Stability
Hey, [X] Stable -- good build (Normal Tomcat) [X] unstable and buggy cluster code, Argg! The normal Tomcat features are very stable on my tests. But my cluster code refactorings has drop the clustering. I have test the cluster under load this week and find some very bad bugs :-( - Complete cluster hang sometimes - In some situation the async mode can't dequeue I have build some quick fixes and can build a patch for some 5.5.9 cluster classes (Monday evening). Vote for a server classes fix pack or package the catalina-cluster.jar again. Sorry, Peter Yoav Shapira schrieb: Hi, Tomcat v5.5.9 has been out for more than a week now, so hopefully we have had time to test/use it. We're still waiting for the TCK results, but let's hear your opinion: [ ] Stable -- good build [ ] Beta -- minor bad stuff: what is it? [ ] Alpha -- something serious is wrong: what is it? The vote will run for about 72 hours as usual. Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA [EMAIL PROTECTED] / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 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]
Syntax from JkEnvVar is changed
Hey, I want transfer a static version number with every request SetEnv config.version 1.0 JkEnvVar config.version but I got this apache startup failure Syntax error on line 25 of D:/tomcat//mod_jk/mod_jk.conf: JkEnvVar takes two arguments, Adds a name of environment variable that should be sent to servlet-engine Env: Windows XP (SP2) Apache 2.0.53, mod_jk 1.2.10, Tomcat 5.5 HEAD After I change it to SetEnv config.version 1.0 JkEnvVar config.version none config is working. Other issue is, that only a request.getAttribute(config.version) give me access to the env attribute. The request.getAttributeNames() get only real container attribute names back. Why mod_jk not transfer only those env var that really exists? How transfer a env var without value? We must update the jk doc or change the semantic. Peter - 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
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
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
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: [VOTE] PMC Chair
Hello Henri, here ist my vote ([EMAIL PROTECTED]) The initial Tomcat PMC chair should be: [X ] Remy Maucherat [ ] Yoav Shapira regards Peter Henri Yandell schrieb: Just as an update, I've recorded 11 public/private votes from: Keith Wannamaker (keith) Mark Thomas (markt) Larry Isaacs (larryi) Filip Hanak (fhanak) Tim Funk (funkman) Kin-man Chung (kinman) Henri Gomez (hgomez) Mladen Turk (mturk) Costin Manolache (costin) Jim Jagielski (jim) Bill Barker (billbarker) There are 70 committers, and it's a holiday weekend (4 day weekend in some places, so not back til Tuesday) so I suspect it's best to keep the vote open for some more time. The above, plus Remy and Yoav, would represent the proposed PMC list, and I'll report on additional votes on Tuesday night. Hen - 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: JK 1.2.9 Release
Hello Mladen, Sounds good, some of my customers wait for a new stable release :-) Can we change the xml status format to attribute semantic? jk:status xmlns:jk=http://jakarta.apache.org; jk:server name=127.0.0.1 port=80 software=Apache/2.0.53 (Win32) DAV/2 mod_jk/1.2.9-beta-1 version=1.2.9/ jk:balancers jk:balancer id=0 name=lb type=lb sticky=true stickyforce=false retries=3 recover=60 jk:member id=0 name=node1 type=ajp13 host=localhost port=9012 address=127.0.0.1:9012 ... / jk:map type=Context uri=/ClusterTest/* context=/ClusterTest/ / /jk:balancer jk:balancers jk:status currently the format is: - jk:status jk:server name=127.0.0.1 port=80 software=Apache/2.0.53 (Win32) DAV/2 mod_jk/1.2.9-beta-1 version=1.2.9/ - jk:balancers - jk:balancer jk:id0/jk:id jk:namelb/jk:name jk:typelb/jk:type jk:stickyTrue/jk:sticky jk:stickyforceFalse/jk:stickyforce jk:retries3/jk:retries jk:recover60/jk:recover - jk:member jk:id0/jk:id jk:namenode1/jk:name jk:typeajp13/jk:type jk:hostlocalhost/jk:host jk:port9012/jk:port jk:address127.0.0.1:9012/jk:address . The attribute format is much eaisier to parse with diegster! I want implement a Jk Proxy Mbean for easy report the status with mc4j. Regards Peter Mladen Turk schrieb: Hi, There has been some commits since 1.2.9 was released as beta. Since they are non-critical, because they do not change the operation, but rather the return error messages, I would still like to tag the release as 1.2.9. I'll give couple of days and propose a vote for official announcement. If passed, then we'll just declare it as stable. If some critical errors gets discovered, I'll just drop the release and go for 1.2.10. How that sounds? 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: JK 1.2.9 Release
OK, I look inside the code and made the changes. peter Mladen Turk schrieb: Peter Rossbach wrote: Hello Mladen, Can we change the xml status format to attribute semantic? Feel free to commit the changes :) This is also syntactic sugar, so if it's valid xml se no reason why not. 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: Time for TLP?
Yoav Shapira schrieb: I think we're ready to move Tomcat to a TLP. There's a lot of support for it in the general Jakarta and ASF ranks. Before we write and vote on a proposal, I wanted to see informally what the opinions are within our own group about this potential move. I'm obviously +1. +1, I think the tomcat community is big ... :-) Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JK] Releasing 1.2.9
Great, i have fix the JkStatusUpdateTask and hope I can implement a JkStatusListTask to parse the new xml output format. Only thing that I missing is that we can add a css style sheet to html output and xsl style sheet to xml output. worker.status.type=status worker.status.css=jkstatus.css or worker.status.css=http://host//jkstatus.css worker.status.xsl=jkstatus.xsl worker.status.xsl= http://host//jkstatus.xsl How the status worker parameter parsing work? Peter Mladen Turk schrieb: Hi, I wish to release the 1.2.9 as beta when Peter updates the jkstatus ant task for manager :). I think that the amount of work done last couple of months since 1.2.8 was released, deserves that. What's left is updating documentation, that I wish to finish during the beta release. Comments? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant JKStatusUpdateTask.java catalina.tasks
Hello Mladen, I have not implement multi output mode. I have made a very straigth forward implementation to JkStatusUpdateTask. The current implementation can't read the current Apache jk config The following statements are used loadbalancer update http://localhost/status?cmd=textupdatew=lblf=falsels=true lr is int = 1 lt is int = 59 worker update http://localhost/status?cmd=textupdatew=node1l=lbwf=1wd=false here I used for the parameter l for the name of the loadbalancer! I not need it for textupdate command I also thing that next stepfor jk_status is a multi channel output mode! :-) All worker names are URLEncoded and you can setup the charset at the ant task. I wan't deal directly with the worker names at my script and not with the internal id's. Peter Mladen Turk schrieb: Hey this is cool :). [EMAIL PROTECTED] wrote: Log: add JkStausUpdate task for mod:jk status worker (greater mod_jk 1.2.9 only) I thought it was meant to be an XML, to pick up the config from apache. Also, can you keep the cmd=update and add something like: mime=html|xml|txt ? Further more 'lr' and 'lb' params are using integer values (worker id's) so you will need to use integers or change the code to accept strings. The reason why I choose the integers or id's was because in that case there is no need to url encode worker names. Of course we can what documentation says accept only alnums for worker names, but that will break backward compatibility in some cases. I would like for this version to add ERROR message in the log if worker name is non-url safe, but still allow it for now. IMO ant task should pick up default values from apache directly by parsing xml output. 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant JKStatusUpdateTask.java catalina.tasks
Hello Mladen, OK, I made a try to extract the jk status information from html. I hope I can do that in the next week Peter Mladen Turk schrieb: Peter Rossbach wrote: I have not implement multi output mode. I have made a very straigth forward implementation to JkStatusUpdateTask. The current implementation can't read the current Apache jk config Any chance to enable reading jkstatus, so that manager can display mod_jk config. I was thinking that we would build that in such a way. I know it's a lot of work, but ... 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant JKStatusUpdateTask.java catalina.tasks
Cool, after you intergrate that xml mode I wrote the Ant task Great :-) peter Mladen Turk schrieb: Peter Rossbach wrote: Hello Mladen, OK, I made a try to extract the jk status information from html. I hope I can do that in the next week There is no need to do that. I'll make a complete xml dump for jkstatus. We already have xml mode for mod_proxy so in that case this will be reusable. Html should be used only in standalone mode. 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: Release status ?
Hey Remy, I also think we can plan next week a 5.5.9 release and I test the new logging feature later today. Other question: I have wrote a JKStatusUpdateTask ant task for the new jk 1.2.9 status worker and use the o.a.c.ant.AbstractCatalinaTask as super class. I am not sure that o.a.c.ant is really the correct package for those connector ant task What are the planed feature for the new host manager tool? Have you see the Centaurus-Platform (http://centaurus.sf.net) Management Console from Thorsten Kamann?. OK, all docs are in german, but install it and look at http://localhost:8280/management the very great admin tool. Dowload it at http://prdownloads.sourceforge.net/centaurus/centaurus-platform-1.0beta6-full-gui-installer.jar?download Peter Remy Maucherat schrieb: Hi, This week, I will work on adding the host manager tool that I promised long ago. As 5.5.8 is in limbo, I think we should plan for a 5.5.9 instead. Or is there still some interest in that build ? Last, did anyone test the new logging defaults ? Thanks :) 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: JK Removing local_worker and local_worker_only directives
Morning Mladen, I have build with newest patch and the redirect working well. Thanks :-) But the same szenario with domains don't work workers.properties: worker.list=lb,status worker.node1.port=9012 worker.node1.host=localhost worker.node1.type=ajp13 worker.node1.disabled=true worker.node1.domain=A #worker.node1.redirect=node2 worker.node2.port=9022 worker.node2.host=localhost worker.node2.type=ajp13 worker.node2.disabled=false worker.node2.domain=A #worker.node2.redirect=node1 worker.node3.port=9032 worker.node3.host=localhost worker.node3.type=ajp13 worker.node3.disabled=false worker.node3.domain=A worker.lb.balance_workers=node1,node2,node3 worker.lb.type=lb worker.status.type=status szenarios: node1 is disabled node2 is active node3 is active start only node1 start firefox Request failed with Internal Error szenario 2 node1 is disabled node2 is active start node1, node2 request successfull stop node2 request failed Start a new Browser (mozilla) request failed again with Internat Error Peter Mladen Turk schrieb: Peter Rossbach wrote: Well, It works only for old requests, but new request get an Internal Server Error! Yes, seems that my test case was broken. It should work now. Can you check? 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: JK Removing local_worker and local_worker_only directives
Hello Mladen, no, the redirect domain feature don't work for me. Here my configuration: worker.list=lb,status worker.node1.port=9012 worker.node1.host=localhost worker.node1.type=ajp13 worker.node1.disabled=true worker.node1.domain=B worker.node2.port=9022 worker.node2.host=localhost worker.node2.type=ajp13 worker.node2.disabled=false worker.node2.domain=A worker.node2.redirect=B worker.node3.port=9032 worker.node3.host=localhost worker.node3.type=ajp13 worker.node3.disabled=false worker.node3.domain=A worker.node3.redirect=B worker.lb.balance_workers=node1,node2,node3 worker.lb.type=lb worker.status.type=status Both described szenarios (last email) don't work with the domain redirect config. Peter Mladen Turk schrieb: Peter Rossbach wrote: Morning Mladen, I have build with newest patch and the redirect working well. Thanks :-) Great. But the same szenario with domains don't work You will still need the redirect for hot-standby to work. It's just like for workers, except that instead worker name the domain is used, so you can have multiple failover boxes. worker.node1.domain=A worker.node1.redirect=B worker.node2.domain=A worker.node2.redirect=B worker.node3.domain=B Tell me if it's work. 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: JK Removing local_worker and local_worker_only directives
Hello Mladen, Great, now my cluster hot standby works as aspected. Thanks for your quick help! Current support of redirect is enough for me. http://dict.leo.org/se?lp=endep=/Mn4k.search=enoughThe domain redirect use case to startup very save a next software generation is working with the existing domain concept. You have two tomcat cluster domains. Two Apaches and three tomcat instances at every cluster domain. worker.nodeA01.domain=A0 worker.nodeA02.domain=A0 worker.nodeA03.domain=A0 worker.nodeB01.domain=B0 worker.nodeB02.domain=B0 worker.nodeB03.domain=B0 worker.list=lb,status worker.lb.balance_workers=nodeA01,nodeA02,nodeA03,nodeB01,nodeB02,nodeB03 worker.lb.type=lb worker.status.type=status Now you want start a new software generation under high load Start the new Instance A1x, B1x change the workers.properties at apache A and B gracefull restart the apaches. worker.nodeA01.domain=A0 worker.nodeA01.disabled=True worker.nodeA02.domain=A0 worker.nodeA02.disabled=True worker.nodeA03.domain=A0 worker.nodeA03.disabled=True worker.nodeB01.domain=B0 worker.nodeB01.disabled=True worker.nodeB02.domain=B0 worker.nodeB02.disabled=True worker.nodeB03.domain=B0 worker.nodeB03.disabled=True worker.nodeA11.domain=A1 worker.nodeA12.domain=A1 worker.nodeA13.domain=A1 worker.nodeB11.domain=B1 worker.nodeB12.domain=B1 worker.nodeB13.domain=B1 worker.list=lb,status worker.lb.balance_workers=nodeA11,nodeA12,nodeA13,nodeB11,nodeB12,nodeB13,nodeA01,nodeA02,nodeA03,nodeB01,nodeB02,nodeB03 worker.lb.type=lb worker.status.type=status Old Session A0x, B0x working very well for old existing session and replicated backup. All new sessions goes to A1x,B1x nodes After a some times, the admin can drop the old nodes (A0x, B0x) with zero sessions active and than remove the A0x and B0x workers. How can I force a autoreloading with update the workers.properties, without gracefull restart the apache? Thanks very much, Peter Mladen Turk schrieb: Mladen Turk wrote: You will still need the redirect for hot-standby to work. It's just like for workers, except that instead worker name the domain is used, so you can have multiple failover boxes. Sorry, It won't failover to domain, so: worker.node1.domain=A worker.node1.redirect=node3 worker.node2.domain=A worker.node2.redirect=node3 worker.node3.domain=A worker.node3.disabled=True I'll see if and how a failover redirection for hot standby can be made to a group of workers. Not sure if this will have any real world usage, but it can be made. Convince me why would someone need 5 boxes not doing anything just in case. I mean, a single one should be enough ;). 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: JK Removing local_worker and local_worker_only directives
Hello Mladen,
after a very long thinking I have missing a hot Standby feature, when we
remove local_work flag.
Example
two tomcat instance with local_worker=true and domain=A
one tomcat instance with local_worker=false and domain=B
New session only generate to domain A tomcat instance
After complete disable all domain A instance, the new sessions fork to
tomcat instances at domain B ( hot standby)
After complete domain A instances failure all requests forward to domain
B instances.
How I can configure this without local_work flag?
I thing we can rename the flag to preferred_worker.
Peter
Mladen Turk schrieb:
Hi,
I would like to deprecate the local_worker and local_worker_only
directives.
The reason is that we have now shared memory, and thus more powerful
ways to accomplish it's use.
Now, we two new directives 'redirect' and 'domain' that are more
powerful then exiting ones.
Here is how it works:
1. If there is a session the request is routed to the worker.
2. If there is no session and the worker is disabled, meaning not
accepting new connections then the request is redirected to
the 'redirect' router if present or 'domain' if not.
3. If there is a session and the worker is in error state and
the 'sticky_session_force' is not set then the 'redirect'
and 'domain' are checked.
4. If there is a session and the worker is in error state and
the 'sticky_session_force' is set the 500 is returned.
Here is the simple state table:
('x' means don't care, '-' means not set)
| worker | session | route | domain | force | err | dis | result |
| w1 | w1 | x | x| x | 0 | x | w1 |
| w1 | w1 | x | x| 1 | 1 | x | 500|
| w1 | w1 | w2 | x| 0 | 1 | x | w2 |
| w1 | w1 | - | grp | 0 | 1 | x | grp|
| w1 | - | - | -| x | 0 | 0 | any|
| w1 | - | - | grp | x | 0 | 0 | grp|
| w1 | - | - | -| x | 0 | 1 | !w1|
So, basically the local_worker_only will become 'sticky_session_force',
that is more descriptive meaning of the actual usage.
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: JK Removing local_worker and local_worker_only directives
Hello Mladen, hmm, with your example I got a Internal Server Error after I disable or drop active node2 and start a new session request! :-( All request with active node2 session work properly when node2 shutdown! What I want is that after a failure, the node1 got all requests. This szenario work very well with old local_worker mode. Here my test confguration: worker.list=lb,status worker.node1.port=9012 worker.node1.host=localhost worker.node1.type=ajp13 worker.node1.disabled=true worker.node2.port=9022 worker.node2.host=localhost worker.node2.type=ajp13 worker.node2.disabled=false worker.node2.redirect=node1 worker.lb.balance_workers=node1,node2 worker.lb.type=lb worker.status.type=status Peter Mladen Turk schrieb: Peter Rossbach wrote: Hello Mladen, after a very long thinking I have missing a hot Standby feature, when we remove local_work flag. How I can configure this without local_work flag? I thing we can rename the flag to preferred_worker. OK. Worker B used as hot standby: worker.A.redirect=B worker.B.disabled=True worker.LB.sticky_session=True worker.LB.balance_workers=A,B If you wish to have a hot-standby tomcat cluster group, then use domains. For single workers use worker names. So worker B is initially disabled. Worker A has redirect of 'failover' to B. Worker B will not receive any requests unless worker A gets in error state or disabled. If worker A gets disabled existing sessions will be still served, new one will go to B. Later you can use jkstatus, and switch their roles. 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: JK Removing local_worker and local_worker_only directives
Well, but at my test following is not the case: Other thing is if Node2 breaks, then Node1 will take old and new requests. It works only for old requests, but new request get an Internal Server Error! Test with Apache 2.053, Windows XP, mod_jk CVS Head, Tomcat 5.5.8, JDK 1.5.0 Peter Mladen Turk schrieb: Peter Rossbach wrote: Hello Mladen, hmm, with your example I got a Internal Server Error after I disable or drop active node2 and start a new session request! :-( All request with active node2 session work properly when node2 shutdown! What I want is that after a failure, the node1 got all requests. Sorry, but this works well and as expected. 1. Node2:in_error - redirect to node1 2. Node2:disabled - exiting sessions to node2 if Node1 disabled too - 500 3. Enable Node1 - new sessions to Node1 So you will need to enable node1 then disable node2 if you are doing maintenance. Other thing is if Node2 breaks, then Node1 will take old and new requests. Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Propose Jim Jagielski and William A. Rowe as JakartaTomcatConnectors commiters
++1 welcome on board, we need help Thanks Peter Mladen Turk schrieb: I'd like to nominate Jim Jagielski ([EMAIL PROTECTED]) and William A. Rowe ([EMAIL PROTECTED]) as commiters for the JTC connectors. Both of them are long time ASF members. Jim is even a director of Apache Software Foundation. They both are core apache httpd designers and developers for years now, and IMHO we should be proud tho have them on board :). I'm sure they will help us with the better apache httpd integration. So... [x] Yes, Jim is really a cool guy. [ ] No way. and.. [x] Sure, wellcome Bill. [ ] I think I know httpd better then him. The both have my ++1. 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]
Some Compiler Error with mod_jk Windows
Morning Mladen, I checkout the news Tomcat 5.5 head and can't compile mod_jk today. Yesterday morning it works great Use Windows XP MSDEV 6.0 Apache 2.0.49 regards Peter D:\tomcat\jakarta-tomcat-connectors\jk\native\apache-2.0MSDE V mod_jk.dsp /MAKE ALL Konfiguration: apache - Win32 Debug Kompilierung läuft... jk_ajp12_worker.c jk_ajp13_worker.c jk_ajp14_worker.c D:\tomcat\jakarta-tomcat-connectors\jk\native\common\jk_ajp14 _worker.c(105) : warning C4013: 'apr_snprintf' undefiniert; Annahme: extern mit Rueckgabetyp int jk_jni_worker.c jk_lb_worker.c jk_status.c D:\tomcat\jakarta-tomcat-connectors\jk\native\common\jk_statu s.c(138) : warning C4013: 'apr_vsnprintf' undefiniert; Annahme: extern mit Rueck gabetyp int jk_worker.c Generieren von Code... Linker-Vorgang läuft... Bibliothek Debug/mod_jk.lib und Objekt Debug/mod_jk.exp wird erstellt jk_status.obj : error LNK2001: Nichtaufgeloestes externes Symbol _apr_vsnprintf jk_util.obj : error LNK2001: Nichtaufgeloestes externes Symbol _apr_vsnprintf Debug/mod_jk.so : fatal error LNK1120: 1 unaufgeloeste externe Verweise Fehler beim Ausführen von link.exe. mod_jk.so - 3 Fehler, 2 Warnung(en) Konfiguration: apache - Win32 Release Kompilierung läuft... jk_ajp12_worker.c jk_ajp13_worker.c jk_ajp14_worker.c D:\tomcat\jakarta-tomcat-connectors\jk\native\common\jk_ajp14 _worker.c(105) : warning C4013: 'apr_snprintf' undefiniert; Annahme: extern mit Rueckgabetyp int jk_jni_worker.c jk_lb_worker.c jk_status.c D:\tomcat\\jakarta-tomcat-connectors\jk\native\common\jk_statu s.c(138) : warning C4013: 'apr_vsnprintf' undefiniert; Annahme: extern mit Rueck gabetyp int jk_worker.c Generieren von Code... Linker-Vorgang läuft... Bibliothek Release/mod_jk.lib und Objekt Release/mod_jk.exp wird erstellt jk_status.obj : error LNK2001: Nichtaufgeloestes externes Symbol _apr_vsnprintf jk_util.obj : error LNK2001: Nichtaufgeloestes externes Symbol _apr_vsnprintf Release/mod_jk.so : fatal error LNK1120: 1 unaufgeloeste externe Verweise Fehler beim Ausführen von link.exe. mod_jk.so - 3 Fehler, 2 Warnung(en) D:\tomcat\jakarta-tomcat-connectors\jk\native\apache-2.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some Compiler Error with mod_jk Windows
Hello Mladen, now I have update to Apache 5.0.53, but the failure changed a little bit : D:\tomcat\jakarta-tomcat-connectors\jk\native\apache-2.0MSDE V mod_jk.dsp /MAKE ALL Konfiguration: apache - Win32 Debug Kompilierung läuft... jk_ajp12_worker.c jk_ajp13.c jk_ajp13_worker.c jk_ajp14.c jk_ajp14_worker.c jk_ajp_common.c D:\tomcat\akarta-tomcat-connectors\jk\native\common\jk_ajp_c ommon.c(756) : warning C4018: '==' : Konflikt zwischen signed und unsigned D:\tomcat\jakarta-tomcat-connectors\jk\native\common\jk_ajp_c ommon.c(757) : warning C4018: '==' : Konflikt zwischen signed und unsigned jk_connect.c jk_context.c jk_jni_worker.c jk_lb_worker.c jk_map.c jk_md5.c jk_msg_buff.c jk_pool.c jk_shm.c jk_sockbuf.c jk_status.c jk_uri_worker_map.c jk_util.c jk_worker.c Generieren von Code... Kompilieren... mod_jk.c Generieren von Code... Linker-Vorgang läuft... Bibliothek Debug/mod_jk.lib und Objekt Debug/mod_jk.exp wird erstellt Regards Peter Mladen Turk schrieb: Peter Rossbach wrote: Morning Mladen, I checkout the news Tomcat 5.5 head and can't compile mod_jk today. Yesterday morning it works great Use Windows XP MSDEV 6.0 Apache 2.0.49 Fixed, thanks. Also I would suggest that you use more recent apaches for Windows. Pre 2.0.52 have bugs with transmitfile if you have third party winsock, like firewalls etc. 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]
First look at new mod_jk status page
Hello Mladen, new status page work fine. Really cool ;-) Only the type of a workers was currently not correct displayed. I got unknown as value. opps! Is it planned that we can save the worker configuration as seperate workers.properties? How we can transfer the information to an Tomcat MBeanServer? Can I help to fix the old Java AJP jk2 handler or start with a new implementaion? Can we get the status information as XML document? Not really important but easier to integrate in some monitoring products. What are your next steps? Here my working configuration: workers.properties worker.list=lb,status worker.node1.port=9012 worker.node1.host=localhost worker.node1.type=ajp13 worker.node2.port=9022 worker.node2.host=localhost worker.node2.type=ajp13 worker.node3.port=9032 worker.node3.host=localhost worker.node3.type=ajp13 worker.lb.balanced_workers=node1,node2,node3 worker.lb.type=lb worker.status.type=status And at httpd.conf JkMount /status/* status Many Thanx Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Proposed API change to the Manager interface
Hmm, I think that Remy's patch is working correct. But I think we must controll the jvmRoute from those client sessions id's (ManagerBase include this at a comment :-)). I must check my cluster failover szenarios. I can to that tomorrow. Peter Rainer Jung schrieb: Both Cluster Managers (Delta and SimpleTcpReplication) extend ManagerBase but override createSession(). Maybe Filip or Peter can check how to make them long-time compatible with your proposal? Managers extending ManagerBase should work and compile as before with no changes unless they override the createSession method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 5.5.7 Stability
Yoav Shapira schrieb: Hi, Tomcat 5.5.7 was released a week ago, and now it's time for a stability vote ;) I have yet to see TCK results, but this has been a crazy month for everyone it seems... [ ] Alpha: leave it as-is, numerous bugs, etc. [ ] Beta: good quality release, at least one issue preventing stable vote [X] Stable: solid, no major issues (minor issues possible) Stable :-) Peter Thanks for voting, Yoav - 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: Sorry, no time to cut release
Hey , I have test it and it works for me, but you are right, I have also two mx4j-2.1.0 directories The old MX4j.2.0.1 has no main directory inside the zip, the new one has one. :-) Regards Peter Dominik Drzewiecki schrieb: Remy Maucherat [EMAIL PROTECTED] wrote: I updated the dependencies to current builds. FYI. mx4j-2.1.0 seems to bee unpacked to wrong directory (one mx4j-2.1.0 too far), so that the next build pass doesn't find libraries and downloads mx4j-2.1.0 again. /dd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hello Remy, Thanx for your help and I hope we have now a better server.xml saving support. The new features are: - Clustering support - new 5.5 Connector attribute mapping support (with correct https saving) - backup the context.xml also as default mode - Internally you can save Server/Service/Host/Context at PrintWriter - configurable and extendable I hope we have fun with the new modul :-) Peter s.u Remy Maucherat schrieb: Remy Maucherat wrote: I've thought about this more. Actually, maybe it's better to leave an indirection (and keep the compatibility as a bonus). Otherwise, we start to have to hardcode (or make configurable = more complexity) an ObjectName. So I think you probably have made the right choice. Now that I have looked at it, I have some comments: - nearly all of the logging is done as log.error(e), which isn't cool, because it logs e.toString() rather than a stack trace Yes, this is a ToDO and I spent time for this. - I think some special cases are needed for Context handling (but it's not very high priority, the current stuff does the job): * avoid saving information which is in the default context configuration (I think MBeans should be added for exposing the context defaults) Yes, the Context handling is very spezial. Currently the only chance is parse context defaults at a fresh new Context and strip down the real Context. Bad,Bad and no easy :-( I hope we have at future a DefaultContext MBean and use this at HostConfig and StoreConfig. * don't save path except in server.xml I thing that can I fix! * don't save docBase if the webapp is in the host appBase OK! It seems to work as well as the old code, so it's great :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.7 ?
Yes, I thing the first step to better saving server.xml is done! +1 Vote for Release 5.5.7 Peter Remy Maucherat schrieb: I think the initial work on the new config save is now done, and it appears to be working at least as well as the old one. Yoav, would it be ok to do a new build picking up all the changes and fixes ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.7 ?
Well, that really OK! Peter Yoav Shapira schrieb: Hi, It's certainly OK for you to do one ;) If you want me to do it, that's also OK, but it will have to wait until this weekend. Either way is fine with me. I haven't looked at (much less written) any code recently, as I expected for this January boot camp at school... Yoav -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, January 13, 2005 8:00 AM To: Tomcat Developers List Subject: 5.5.7 ? I think the initial work on the new config save is now done, and it appears to be working at least as well as the old one. Yoav, would it be ok to do a new build picking up all the changes and fixes ? 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] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release?
OK, I can do that at monday. Thanx Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hey Remy, yes, but I thing we need some test. Than I can made the complete integration. I vote in favor of doing the complete integration right now. Worst case it's as bad as the current code, which isn't exactly well tested in the 5.5 branch ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New committer: Jean-Jacques Clar
Günter Knauf schrieb: I'd like to nominate Jean-Jacques Clar [EMAIL PROTECTED] as committer for the JTC connectors. Jean-Jacques works for Novell where I met him already; he's there working with the Apache and Tomcat stuff, and since Mike left the company there's now no other commiter from Novell anymore with karma for the Tomcat stuff. Jean-Jacques is already commiter of httpd, and I think now also of apr, so I believe he's a good candidate. Guenter. +1 More people, More fun :-) Great. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next release?
Hey Remy, I have ready my first storeconfig module to better save server.xml and context.xml. At the first step I add the implementation as new module. I have wrote a StoreConfigLifecycleListener to register a new Mbean . Server .. Listener className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/ /Server Please read the short readme at jakarta-tomcat-catalina/modules/storeconfig/docs after my checkin. Regards Peter Remy Maucherat schrieb: Yoav Shapira wrote: Hi, Happy new year everyone ;) I just got back from vacation and don't have time to read all the archives. What's the feeling as to a good time for the next 5.5 release? I did some more bugfixing. Hopefully the hot deployer will be fully functional in this build :) Is it ok to do a 5.5.7 tag ? 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: Next release?
Hey Remy, yes, but I thing we need some test. Than I can made the complete integration. Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hey Remy, I have ready my first storeconfig module to better save server.xml and context.xml. At the first step I add the implementation as new module. I have wrote a StoreConfigLifecycleListener to register a new Mbean . Server .. Listener className=org.apache.catalina.storeconfig.StoreConfigLifecycleListener/ /Server Please read the short readme at jakarta-tomcat-catalina/modules/storeconfig/docs after my checkin. So I say we delay 5.5.7 so that it is integrated well (I would assume the main thing to do is to remove the old code). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.0.29 and request.getScheme
Hey,, please use secure=true Connector secure=true acceptCount=100 address=127.0.0.1 connectionTimeout=2 disableUploadTimeout=true port=9080 proxyName=myhost proxyPort=443 redirectPort=9443 scheme=https /Connector Don't forget to create the Server keystore. Please read the Connector docs: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/ssl-howto.html http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/http.html Regards Peter Luis Fernando Pardo schrieb: Hello, I have just upgraded my tomcat version from 5.0.16 to 5.0.29 and I have found a problem with the request.getScheme method. I have set apache server to listen on 443 port (SSL) and proxypass to Tomcat on local address (127.0.0.1) and port 9080. This is the connector configuration in Tomcat: Connector acceptCount=100 address=127.0.0.1 connectionTimeout=2 disableUploadTimeout=true port=9080 proxyName=myhost proxyPort=443 redirectPort=9443 scheme=https /Connector With this configuration in Tomcat 5.0.16, when I call to getScheme method, it returns https value, but in the new version 5.0.29 I always get http. Does anyone know if connector configuration in 5.0.29 has changed from 5.0.16? or may I have doing something wrong? Thanks in advance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing JK1.2.7
Hey Mladen, please do it, I am ready for testing the new staff :-).. Peter Mladen Turk schrieb: Hi, There has been lots of changes in the JK, and I'd like to tag and release 1.2.7-beta tomorrow. Any objections? Also, This release will be marked as beta, and thus not production ready. If it passes user's testing, in a week or two I plan to release 1.2.8 stable. The reason for that are couple of new things added like extensive logging, socket timeouts, new load balancer algorithm, etc... that needs 'real-world' testing. Any comments? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website updates
Good idea that people can read the jk doc without internet access. regards, Peter Remy Maucherat schrieb: I propose the following changes to the main website: - in the Documentation section, add JK 1.2 - add the new JK documentation to the website - in the Documentation section, add mod_proxy, linking to the Apache 2.1 documentation - when the next Tomcat 5.5 stable is released, update the Tomcat Versions chart with 5.5, and move the Tomcat 5.0 documentation link to the archives 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 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]
Question about new mod_jk jk_lb_worker.c
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... See also Rainers Jung mail b) I have play around with the mod_jk2 lb algo and find the level feature (hot-standby) very usefull. With this feature I have setup to apache with two separate clusters. Apache 1 Worker T1.1 level 0 Worker T1.2 level 0 Worker T1.3level 0 Worker T2.1 level 1 Worker T2.2 level 1 Worker T2.3level 1 Apache 2 Worker T1.1 level 1 Worker T1.2 level 1 Worker T1.3level 1 Worker T2.1 level 0 Worker T2.2 level 0 Worker T2.3level 0 T1.1-T1.3 Cluster 1 T2.1-T2.3 Cluster 2 With this configuration every Apache has a preferred cluster. Ok small patch are needed: After a crashed node the algo find prefered worker at same level. I thing the domain concept from Rainer Jung in combination with preferred worker from mod_jk2 can be very usefull for clustered env. Regards Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StoreBase.java mbeans-descriptors.xml
Hoho,
I reformat a little but I work with Eclipse and format the code again
and replace tab to space.
thanks
Peter
Bill Barker schrieb:
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 02, 2004 11:07 AM
Subject: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session
JDBCStore.java PersistentManagerBase.java StoreBase.java
mbeans-descriptors.xml
pero2004/11/02 11:07:51
if (preparedKeysSql == null) {
+ String keysSql =
+ SELECT + sessionIdCol + FROM + sessionTable +
+ WHERE + sessionAppCol + = ?;
preparedKeysSql =
_conn.prepareStatement(keysSql);
}
I can hear the sirens from the dreaded tab-police :).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.4 tomorrow (Friday) instead of Saturday?
Great Yoav, do it on friday is very good Peter Shapira, Yoav schrieb: Hi, Would everyone be OK with cutting the 5.5.4 release tomorrow (Friday, October 29th) instead of Saturday (October 30th) as we originally agreed? It'd be more convenient for me, that's the only reason. If it can't be done on Friday, it'll likely have to be Monday afternoon instead, but Saturday I can't do. As for the release time of day, it'll be the same whether Friday or Monday: 1900h GMT which is 1400h my time (US Eastern time zone). Yoav Shapira http://www.yoavshapira.com 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: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hmm, I also so think that the managedResource attribute is a hack. What we need is a better JMX API. My wish is that we open some of the MBeans to add more operations. Example realm: We have only init/start/stop/destroy jmx operations but what I need is authenticateXXX hasRole Than I can easy used every realm for my JMX http adaptor (MX4J 2.0.1). Peter Bill Barker schrieb: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 04, 2004 4:23 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml Bill Barker wrote: It was on Peter's wish-list to add managedResource to the Realms. This was taken from (I think :) StandardHost, where the code was so broken that it was impossible that anybody was using it, so waiting for managedResource to be added to the mbean-descriptor was reasonable. I tested with removing the relevant blocks in the containers: it's not really used. It would be only used by some custom JMX-embedding (and, like I said, it never worked :). The JMX-embedding method that does work is to invoke init on the Realm, which will then add itself to whichever Container it was registered for. Except that managedResource is an internal-implementation artifact of c-m. There really isn't any point in getting rid of it before Remy's project to make c-m an optional component. Really, I'm supposed to do that ? ;) It's your todo list ;). I don't think managedResource needs anything special: it's just a standard attribute (and is a hack) that is declared in the mbean-descriptors. Its name makes it sound like it's somehow magically provided by the model MBean implementation, but it's not (it would be very insecure to do so). I would be happier if we tried removing the managedResource, actually. It will make Peter unhappy, but it wouldn't be hard. Probably the hardest one to do would be Connector (since you can't add a Connector to an Engine :). The Realm stuff that started this could probably just invoke init on the Realm instead. Rémy - 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] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://www.webapp.de/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hey Remy, I have made a complete rebuild and a test. It works fine for me.. Ok, what you thing is a better name for ContextBase or you mean the refactoring is useless ? I need this refactoring for eaiser identifiy the ContextXXX classes for my new xml saving code. Peter Remy Maucherat schrieb: [EMAIL PROTECTED] wrote: pero2004/10/04 23:57:20 Modified:catalina/src/share/org/apache/catalina/deploy ContextEjb.java ContextLocalEjb.java ContextResource.java ContextResourceEnvRef.java ContextResourceLink.java webapps/docs changelog.xml Log: refactor o.a.c.deploy.ContextXXX classes to use new super class ContextBase. - I think the ContextBase name for this class is quite bad. - Please make sure you don't break the build. This means checking when adding files that they are indeed added (and same when removing). 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: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
Hey Remy, sorry, to my checkin fault... I am change the name to ResourceBase and add it to the cvs. Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hey Remy, I have made a complete rebuild and a test. It works fine for me.. Apparently, you didn't cvs add the new ContextBase class. I think I can figure out what it contains, of course ;) Ok, what you thing is a better name for ContextBase or you mean the refactoring is useless ? No, the classname just sounds this is a superclass of StandardContext. So the classname is bad. I need this refactoring for eaiser identifiy the ContextXXX classes for my new xml saving code. 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]
Need help with mod_ajp
Hello, I have two simple question to the new mod_ajp: Can we add a small documentation how people can compile and configure the new mod_ajp? The mailing list are tell us a lot informations, but please can someone desicribe the current state? Thanks Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need help with mod_ajp
Cool, that mean I checkout httpd 2.1 and all is working? How I can find some mod_ajp configuration documentation? All new elements and option and a example for loadbalancing Can you please, add some documentation ( jk/xdocs) that let people find the new module and configuration ? Thanks Peter jean-frederic clere schrieb: Remy Maucherat wrote: jean-frederic clere wrote: Peter Rossbach wrote: Hello, I have two simple question to the new mod_ajp: Can we add a small documentation how people can compile and configure the new mod_ajp? The mailing list are tell us a lot informations, but please can someone desicribe the current state? The developement of the proxy ajp has been moved to httpd-2.1. To make sure I got everything right: so all the code and dev is done there now ? Yes. BTW, who's a committer on httpd ? I and Mladen ([EMAIL PROTECTED]). Cheers Jean-Frederic Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
