Re: [JK] Status -- was [VOTE] JK 1.2.15
Sorry for late response, but I start testing and hope finish the test at next two days First testresults at Suse 9.3, Windows XP looks very well Peter Mladen Turk schrieb: William A. Rowe, Jr. wrote: Do you guys find something that would prevent 1.2.15 to be declared as stable that I'm missing? I'll try to find cycles to test myself, next week. I know I'm having alot of trouble with the apache 1.3 build on odd architectures, probably because the clash of a libtool-based mod_jk.so.1.2 v.s. non-libtool based httpd 1.3. I'm working on cleaner autoconf against httpd-2.0 already for building mod_ftp, which will probably apply very cleanly here as well. Fine :) Anyhow, what should I do, since I've volunteer for a RM? I mean, I don't expect to see the 1.3 branch for couple of months from now, and the 1.2.14 is unusable on Solaris, so we need some action. The 1.2.15 (bugfix) release is the only thing that is implementable right now, thought. Since there was no reactions to the VOTE either pro or contra for more then a mont, seems to me we are in a serious problem, because the developers/commiter interest is blocking the release. The final solution is either to bring that to the tomcat pmc, and if there is really zero interest on maintaining mod_jk, among the current commiters, it should be either shut down, or proposed as a new project with a different set of maintainers. 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: Status/Authority of AJP/1.5
Here my wishes list: a) Clearer/better Loadbalancing Algo - better understanding of domain/partition based strategy ( I have detect some problemes here) - busy strategy - http://issues.apache.org/bugzilla/show_bug.cgi?id=36138 - real load strategy ( ask tomcats before balance the load) - good documentation of all use cases and the protocol, before implementation ;-) - make extensions possible b) auto reconfig was very nice but this feature is very difficult to implement. Currently graceful restart works good for me! c) disable/enable mapping for some worker inside the same loadbalancer Then it is possible to reload/redeploy a single application at some cluster nodes d) AJP client java implementation and integrate this inside a tomcat proxy module. e) Refactor/Redesign the current AJP server implementation Regards Peter Henri Gomez schrieb: AJP 1.5 should support automatic discovery of tomcat backend, new systems and new webapps. That's the current need for many of us when adding tomcats / webapp behind Apache 2 webservers. In such case we need to restart them and it's sad. How could it be accomplished, may be via a master tomcat who will give the tomcat farm topology to Apache HTTP2. What do you think ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bea give us a Admin Console?
Has everyone more information about this bea admin console project: http://www.bea.com/framework.jsp?CNT=pr01542.htm&FP=/content/news_events/press_releases/2005 Regards Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cluster startContext() SimpleTcpCluster
Hey, a) current tomcat 5.5.12 cluster implementation is a message infrastructure. b) The Context can used this message infrastructure to implement remote session replication c) When a Context start the DeltaManager sync with other nodes. That means that all sessions are transfered form an other node. All lost messages before are dropped and not really important. d) With tomcat 5.5.12 I implemented a message buffering for all messages that received, when ALL_SESSION are transfered This message are replayed after nodes is in sync. Why you implemented your own session replication? It's very hard way :-) Regards Peter local-underground schrieb: Hello, I am very curious why a Cluster does not make sure the context it is defined in is actually started before listening? This is proving to be a serious bug for me. I am implementing session replication where nested objects are defined via JNDI in my context. But when a new cluster member is added, it immediately receives a session and attempts to deserialize the sessions before loading my context.. which is causing errors due to classes not being found. I see a startContext() defined in SimpleTcpCluser but it appears to be depracted and is blank. I do realize I can make a global Resource and reference this JNDI within my context, but I dont wanna move a huge chunk of my web application in global scope just to have these references visible when the cluster starts. Can some one explain the logic of why the Context is not loaded before the cluster starts? Can some one advise me on a quick fix to achieve this? thanks in advance chris __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: FarmWarDeployer
Hey!
At development with Tomcat 5.5.9 and 5.5.12 I have successful used
FarmWarDeployer, but
- you lost your complete session information at your cluster
- Use it without waitForAck or with a great ackTimeout ( >
deployment time)
- only one config can have watchEnabled="true"
- directories must be writeable ( tempDir, deploydir, watchDir)
className="org.apache.catalina.cluster.deploy.FarmWarDeployer"
tempDir="${catalina.base}/cluster/temp"
deployDir="${catalina.base}/webapps"
watchDir="${catalina.base}/cluster/watch"
watchEnabled="@node.watchEnabled@"
processDeployFrequency="2"/>
At production sites I shutdown all tomcat nodes, copy the new war files
and start all nodes again.
Don't start next node before other node is complete up.
regards
Peter
Brian O'Rourke schrieb:
Trying the dev list...
-- Forwarded message --
From: Brian O'Rourke <[EMAIL PROTECTED]>
Date: Oct 26, 2005 1:37 PM
Subject: FarmWarDeployer
To: users@tomcat.apache.org
Hello,
Is FarmWarDeployer ready for use? I have played around with it a little but
have been unsuccessful so far. Is there any documentation of this that I
have missed? I haven't been able to figure out how context configuration is
done for this deployer, but I noticed some oddities - e.g. that the context
name is determined by the name of the war file. Is there a working set of
functionality that FarmWarDeployer handles now, or should I just stay away
from it altogether?
Thanks,
Brian O'Rourke
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cluster startContext() SimpleTcpCluster
Hey, manager is started after some other things are active. s. Standardcontext.start() L.4079 WebApp Listener and Filters starts after manager. The NamingContextListener (JNDI) starts before Manager is started. Ok, what can we do? Peter local-underground schrieb: Peter, Thanks for response. I did not implement my own replication, I only looked at the code to see if my Context was started before the Cluster performed replication. Let me try and clarify by asking this question: Does the Context start (meaning my servlet is started) before the Delta manager syncs with other nodes? It appears the Context is not started before the Sessions are received. If this is true, this is why I am having issues. This is because when Sessions are received, they are deserialized before the web application is loaded. Inside my sessions, I have factory objects loaded via JNDI. These JNDI references are not found. This only occurs when Clustering my sessions. I hope that makes sense. --- Peter Rossbach <[EMAIL PROTECTED]> wrote: Hey, a) current tomcat 5.5.12 cluster implementation is a message infrastructure. b) The Context can used this message infrastructure to implement remote session replication c) When a Context start the DeltaManager sync with other nodes. That means that all sessions are transfered form an other node. All lost messages before are dropped and not really important. d) With tomcat 5.5.12 I implemented a message buffering for all messages that received, when ALL_SESSION are transfered This message are replayed after nodes is in sync. Why you implemented your own session replication? It's very hard way :-) Regards Peter local-underground schrieb: Hello, I am very curious why a Cluster does not make sure the context it is defined in is actually started before listening? This is proving to be a serious bug for me. I am implementing session replication where nested objects are defined via JNDI in my context. But when a new cluster member is added, it immediately receives a session and attempts to deserialize the sessions before loading my context.. which is causing errors due to classes not being found. I see a startContext() defined in SimpleTcpCluser but it appears to be depracted and is blank. I do realize I can make a global Resource and reference this JNDI within my context, but I dont wanna move a huge chunk of my web application in global scope just to have these references visible when the cluster starts. Can some one explain the logic of why the Context is not loaded before the cluster starts? Can some one advise me on a quick fix to achieve this? thanks in advance chris __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r329853 - /tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java
Hey, means the package import "sun.security.krb5.**" that we can't use ByteChunk at other JVm's like jrockit? I don't see the usage? :-) Peter http://svn.apache.org/viewcvs/tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java?rev=329853&r1=329852&r2=329853&view=diff == --- tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java (original) +++ tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java Mon Oct 31 08:39:42 2005 @@ -18,6 +18,10 @@ import java.io.IOException; import java.io.Serializable; +import java.nio.ByteBuffer; + +import sun.security.krb5.internal.crypto.b; +import sun.security.krb5.internal.crypto.t; --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat source / eclipse project
Hey Mark, I think we must correct the absolut Lib Paths inside all .classpath. Set a Eclipse Variable to the base.path repository and use this jars instead. >>> + + I am not sure that all jar versions are correspond to the build/build.properties.defaults. Example I use Ant 1.6.5. Thanks Peter Mark Thomas schrieb: Done. Mark Ian Darwin wrote: Mark Thomas wrote: I have something like this for TC5 & TC4. I do keep the files up to date because I use them every time I look at Tomcat code. I need to migrate my development areas from the old CVS structure to the SVN set-up. Once I have updated my eclipse files, I'll add them to the repo. Anyone object to them being added directly under tomcat/container/tc5.5.x, tomcat/jasper/tc5.5.x etc? They pretty well have to be there to work, right? So, please put them there. I presume there's just a .project and a .classpath for each of a few top-level projects, right? These will be harmless to non-Eclipse users, and invisible on platforms that support *NIX filename semantics, so I'd say +1 for them. Thanks Ian - 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: svn commit: r332766 - in /tomcat: connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11BaseProtocol.java connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11Protocol.java co
When we want use different Handler it was easier we
don't create the ConnectionHandler inside constructor.
Can we use a init() method instead?
protected Http11ConnectionHandler createConnectionHandler() {
...
}
public void init() throws Exception {
cHandler = createConnectionHander() ;
ep.setConnectionHandler( cHandler );
Can you please test my last checkin?
Peter
Costin Manolache schrieb:
On 11/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: pero
Date: Sat Nov 12 04:29:58 2005
New Revision: 332766
URL: http://svn.apache.org/viewcvs?rev=332766&view=rev
Log:
Fix that the RequestProcessor registered at JMX.
It was nice to see this information back inside manager app :-)
tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11BaseProtocol.java
Sat Nov 12 04:29:58 2005
@@ -54,11 +54,6 @@
public class Http11BaseProtocol implements ProtocolHandler
{
public Http11BaseProtocol() {
-cHandler = new Http11ConnectionHandler( this );
-setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
-setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
-setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
-setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
}
/**
public class Http11Protocol extends Http11BaseProtocol implements
MBeanRegistration
{
public Http11Protocol() {
-super();
+cHandler = new JmxHttp11ConnectionHandler( this );
+setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
+setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
+setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
+setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
}
Can we have the setSoLinger, etc in the base as well ? After this
change, the base is probably broken - I'm using it as non-jmx,
standalone http connector.
Maybe in an init function - overriden ?
Costin
-
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: svn commit: r332801 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Hey Remy, I have problems with your last ClassLoader changed. When I used following code: protected static final String info = "org.objektpark.catalina.session.LogSessionListener/1.1"; I got following StackTrace when I shutdown the server: INFO | jvm 1| 2005/11/17 11:57:08 | 17.11.2005 11:57:08 org.apache.catalin a.loader.WebappClassLoader clearReferences INFO | jvm 1| 2005/11/17 11:57:08 | INFO: Could not set field info to null in class org.objektpark.catalina.session.LogSessionListener INFO | jvm 1| 2005/11/17 11:57:08 | java.lang.IllegalAccessException: Fiel d is final INFO | jvm 1| 2005/11/17 11:57:08 | at sun.reflect.UnsafeQualifiedSt aticObjectFieldAccessorImpl.set(UnsafeQualifiedStaticObjectFieldAccessorImpl.jav a:59) INFO | jvm 1| 2005/11/17 11:57:08 | at java.lang.reflect.Field.set(F ield.java:656) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.loader.We bappClassLoader.clearReferences(WebappClassLoader.java:1587) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.loader.We bappClassLoader.stop(WebappClassLoader.java:1480) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.loader.We bappLoader.stop(WebappLoader.java:706) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.core.Stan dardContext.stop(StandardContext.java:4325) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.core.Cont ainerBase.removeChild(ContainerBase.java:892) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.startup.H ostConfig.undeployApps(HostConfig.java:1159) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.startup.H ostConfig.stop(HostConfig.java:1131) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.startup.H ostConfig.lifecycleEvent(HostConfig.java:312) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.util.Life cycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.core.Cont ainerBase.stop(ContainerBase.java:1053) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.core.Cont ainerBase.stop(ContainerBase.java:1065) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.core.Stan dardEngine.stop(StandardEngine.java:447) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.core.Stan dardService.stop(StandardService.java:512) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.core.Stan dardServer.stop(StandardServer.java:734) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.startup.C atalina.stop(Catalina.java:601) INFO | jvm 1| 2005/11/17 11:57:08 | at sun.reflect.NativeMethodAcces sorImpl.invoke0(Native Method) INFO | jvm 1| 2005/11/17 11:57:08 | at sun.reflect.NativeMethodAcces sorImpl.invoke(NativeMethodAccessorImpl.java:39) INFO | jvm 1| 2005/11/17 11:57:08 | at sun.reflect.DelegatingMethodA ccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) INFO | jvm 1| 2005/11/17 11:57:08 | at java.lang.reflect.Method.invo ke(Method.java:585) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.startup.B ootstrap.stop(Bootstrap.java:287) INFO | jvm 1| 2005/11/17 11:57:08 | at org.apache.catalina.startup.B ootstrap.main(Bootstrap.java:409) INFO | jvm 1| 2005/11/17 11:57:08 | at sun.reflect.NativeMethodAcces sorImpl.invoke0(Native Method) INFO | jvm 1| 2005/11/17 11:57:08 | at sun.reflect.NativeMethodAcces sorImpl.invoke(NativeMethodAccessorImpl.java:39) INFO | jvm 1| 2005/11/17 11:57:08 | at sun.reflect.DelegatingMethodA ccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) INFO | jvm 1| 2005/11/17 11:57:08 | at java.lang.reflect.Method.invo ke(Method.java:585) INFO | jvm 1| 2005/11/17 11:57:08 | at org.tanukisoftware.wrapper.Wr apperStartStopApp.stop(WrapperStartStopApp.java:282) INFO | jvm 1| 2005/11/17 11:57:08 | at org.tanukisoftware.wrapper.Wr apperManager.stopInner(WrapperManager.java:1982) INFO | jvm 1| 2005/11/17 11:57:08 | at org.tanukisoftware.wrapper.Wr apperManager.handleSocket(WrapperManager.java:2391) INFO | jvm 1| 2005/11/17 11:57:08 | at org.tanukisoftware.wrapper.Wr apperManager.run(WrapperManager.java:2696) INFO | jvm 1| 2005/11/17 11:57:08 | at java.lang.Thread.run(Thread.j ava:595) INFO | jvm 1| 2005/11/17 11:57:08 | 17.11.2005 11:57:08 org.apache.catalin a.cluster.session.DeltaManager stop [EMAIL PROTECTED] schrieb: Author: remm Date: Sat Nov 12 09:48:54 2005 New Revision: 332801 URL: http://svn.apache.org/viewcvs?rev=332801&view=rev Log: - Add additional experimental measures against apparent garbage collection bugs by setting to null
Re: svn commit: r332801 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Hey Remy, thanks for work at this issue, currently I have comment out the static field handling for my tests. Wait and see ;-) Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hey Remy, I have problems with your last ClassLoader changed. When I used following code: protected static final String info = "org.objektpark.catalina.session.LogSessionListener/1.1"; Yes, I know, I have more changes (which may include commenting out the thing). Sorry for the trouble. Unfortunately, I am having problems getting testing done :( 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: svn commit: r345233 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Thanks for the fix and it works for my case. Peter [EMAIL PROTECTED] schrieb: Author: remm Date: Thu Nov 17 04:10:48 2005 New Revision: 345233 URL: http://svn.apache.org/viewcvs?rev=345233&view=rev Log: - Fix NPE and exception problems with setting fields to null. Modified: tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java Modified: tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java URL: http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java?rev=345233&r1=345232&r2=345233&view=diff == --- tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java (original) +++ tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java Thu Nov 17 04:10:48 2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat Crash with apr when RequestProcessor accessed
Hey, A customer report today a very strange tomcat crash to me and I can simulate this bugs with following releases and OS's: Tested with Suse 9.3, Tomcat 5.5.12 /Apr 1.2.2 / openssl 0.9.8, jdk 1.5.0_03 Also tested with current SVN Head and fresh build tcnative from head and Tomcat 5.5.12 / Maldens tcnative 1.1.0 dll / Windows XP Start Tomcat with APR Http Connector and JSR 160 JMX Adaptor request some pages via http Connector start jconsole / open Mbeans tab Open RequestProcessor tree Open one off the RequestInfo MBeans Result: -- jvm crashed -- Tomcat 5.5.12 --- INFO | jvm 1| 2005/11/23 13:08:28 | INFO: Server startup in 1430 ms INFO | jvm 1| 2005/11/23 13:09:08 | 23.11.2005 13:09:08 org.objektpark.catalina.session.LogSessionListener sessionCreated INFO | jvm 1| 2005/11/23 13:09:08 | INFO: sessionCreated: EC3D6BA963E5EB26F1EA68EED9098A9A.node01 INFO | jvm 1| 2005/11/23 13:09:16 | # INFO | jvm 1| 2005/11/23 13:09:16 | # An unexpected error has been detected by HotSpot Virtual Machine: INFO | jvm 1| 2005/11/23 13:09:16 | # INFO | jvm 1| 2005/11/23 13:09:16 | # SIGSEGV (0xb) at pc=0x4678fc63, pid=8355, tid=1189579696 INFO | jvm 1| 2005/11/23 13:09:16 | # INFO | jvm 1| 2005/11/23 13:09:16 | # Java VM: Java HotSpot(TM) Client VM (1.5.0_03-b07 mixed mode, sharing) INFO | jvm 1| 2005/11/23 13:09:16 | # Problematic frame: INFO | jvm 1| 2005/11/23 13:09:16 | # C [libapr-1.so.0+0x16c63] apr_socket_addr_get+0x93 INFO | jvm 1| 2005/11/23 13:09:16 | # INFO | jvm 1| 2005/11/23 13:09:16 | # An error report file with more information is saved as hs_err_pid8355.log INFO | jvm 1| 2005/11/23 13:09:16 | # INFO | jvm 1| 2005/11/23 13:09:16 | # If you would like to submit a bug report, please visit: INFO | jvm 1| 2005/11/23 13:09:16 | # http://java.sun.com/webapps/bugreport/crash.jsp INFO | jvm 1| 2005/11/23 13:09:16 | # ERROR | wrapper | 2005/11/23 13:09:16 | JVM exited unexpectedly. STATUS | wrapper | 2005/11/23 13:09:30 | Launching a JVM... = crurrent Tomcat svn head with fresh build tcnative INFO | jvm 1| 2005/11/23 15:51:32 | INFO: sessionCreated: 4ABBA4F2ABCBD8E2DF5857CC375FD8CC.node01 INFO | jvm 1| 2005/11/23 15:52:16 | # INFO | jvm 1| 2005/11/23 15:52:16 | # An unexpected error has been detected by HotSpot Virtual Machine: INFO | jvm 1| 2005/11/23 15:52:16 | # INFO | jvm 1| 2005/11/23 15:52:16 | # SIGSEGV (0xb) at pc=0x46799c63, pid=12382, tid=1190149040 INFO | jvm 1| 2005/11/23 15:52:16 | # INFO | jvm 1| 2005/11/23 15:52:16 | # Java VM: Java HotSpot(TM) Client VM (1.5.0_03-b07 mixed mode, sharing) INFO | jvm 1| 2005/11/23 15:52:16 | # Problematic frame: INFO | jvm 1| 2005/11/23 15:52:16 | # C [libapr-1.so.0+0x16c63] apr_socket_addr_get+0x93 INFO | jvm 1| 2005/11/23 15:52:16 | # INFO | jvm 1| 2005/11/23 15:52:16 | # An error report file with more information is saved as hs_err_pid12382.log INFO | jvm 1| 2005/11/23 15:52:16 | # INFO | jvm 1| 2005/11/23 15:52:16 | # If you would like to submit a bug report, please visit: INFO | jvm 1| 2005/11/23 15:52:16 | # http://java.sun.com/webapps/bugreport/crash.jsp INFO | jvm 1| 2005/11/23 15:52:16 | # ERROR | wrapper | 2005/11/23 15:52:16 | JVM exited unexpectedly. STATUS | wrapper | 2005/11/23 15:52:30 | Launching a JVM... Here a part of the core dump # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x4678fc63, pid=8355, tid=1189579696 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_03-b07 mixed mode, sharing) # Problematic frame: # C [libapr-1.so.0+0x16c63] apr_socket_addr_get+0x93 # --- T H R E A D --- Current thread (0x08070c68): JavaThread "RMI TCP Connection(3)-127.0.0.2" daemon [_thread_in_native, id=8389] siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x0028 Registers: EAX=0x, EBX=0x467991e0, ECX=0x0001, EDX=0x ESP=0x46e77214, EBP=0x46e7722c, ESI=0x, EDI=0x46e77244 EIP=0x4678fc63, CR2=0x0028, EFLAGS=0x00010246 Top of Stack: (sp=0x46e77214) 0x46e77214: 46e77304 082e0b94 082e0b94 4676516c 0x46e77224: 69cb9728 08070c68 46e7724c 466a21ad 0x46e77234: 46e77244 0001 466a2180 0x46e77244: 69cb9730 46e77284 438bf42b 0x46e77254: 08070d24 46e7728c 0001 086501f8 0x46e77264: 46e77268 69cb9728 46e7729c 0x46e77274: 69cb99d8 69cb9730 46e77294 0x46e77284: 46e772bc 438b99fa 69cb9980 438bd589 Instructions: (pc=0x4678fc63) 0x4678fc53: c0 8d 65 f4 5b 5e 5f 5d c3 8d 74 26 00 48 75 5a 0x4678fc63: 8b 4e 28 85 c9 75 06 8b 46 14 eb e1 90 8b 46 14 Stack: [0x46df8000,0x46e79000), sp=0x46e77214, free space=508k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libapr-1.so.0+0x16c63] apr_socket_addr_get+0x93 C [libtc
Re: Tomcat Crash with apr when RequestProcessor accessed
Hey Remy, I have tested your patch (suse 9.3) and it fix the jvm crash problem. Currently I have only tested with http apr connector. Many thanks Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hey, A customer report today a very strange tomcat crash to me and I can simulate this bugs with following releases and OS's: Tested with Suse 9.3, Tomcat 5.5.12 /Apr 1.2.2 / openssl 0.9.8, jdk 1.5.0_03 Also tested with current SVN Head and fresh build tcnative from head and Tomcat 5.5.12 / Maldens tcnative 1.1.0 dll / Windows XP Start Tomcat with APR Http Connector and JSR 160 JMX Adaptor request some pages via http Connector start jconsole / open Mbeans tab Open RequestProcessor tree Open one off the RequestInfo MBeans Let me know if my change fixes the problem, as I didn't even try to reproduce the problem (and during the time I was using it with the APR connector, neither the status servlet nor the JMX proxy crashed on me). I did add guard code like there was in the HTTP connector, which critical here as these are pointers. 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]
Feature Request: set maxSpareThreads and minSpareThreads and see a next strange APR Connector behaviour
Why we can set maxSpareThreads and minSpareThreads at APR Http and APR
AJP threadpools?
I have seen another strange behaviour:
After a small load 10 requests and two hour no request the
AJP and HTTP Server sockets are closed and threadspools are not running
anymore (running jmx attribute say false).
When signal the process a shutdown. I see following message inside the log:
INFO | jvm 2| 2005/11/23 22:00:01 | 23.11.2005 22:00:01
org.apache.coyote.ajp.AjpAprProtocol pause
INFO | jvm 2| 2005/11/23 22:00:01 | INFO: Pausing Coyote AJP/1.3
on ajp-20012
INFO | jvm 2| 2005/11/23 22:00:02 | 23.11.2005 22:00:02
org.apache.catalina.core.StandardService stop
INFO | jvm 2| 2005/11/23 22:00:02 | INFO: Stopping service Catalina
INFO | jvm 2| 2005/11/23 22:00:02 | 23.11.2005 22:00:02
org.apache.catalina.connector.MapperListener destroy
INFO | jvm 2| 2005/11/23 22:00:02 | WARNUNG: Error unregistering
MBeanServerDelegate
INFO | jvm 2| 2005/11/23 22:00:02 | java.lang.NullPointerException
INFO | jvm 2| 2005/11/23 22:00:02 | at
org.apache.catalina.connector.MapperListener.destroy(MapperListener.java:161)
INFO | jvm 2| 2005/11/23 22:00:02 | at
org.apache.catalina.connector.Connector.stop(Connector.java:1132)
INFO | jvm 2| 2005/11/23 22:00:02 | at
org.apache.catalina.core.StandardService.stop(StandardService.java:521)
INFO | jvm 2| 2005/11/23 22:00:02 | at
org.apache.catalina.core.StandardServer.stop(StandardServer.java:734)
INFO | jvm 2| 2005/11/23 22:00:02 | at
org.apache.catalina.startup.Catalina.stop(Catalina.java:601)
INFO | jvm 2| 2005/11/23 22:00:02 | at
org.apache.catalina.startup.Catalina.start(Catalina.java:576)
INFO | jvm 2| 2005/11/23 22:00:02 | at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO | jvm 2| 2005/11/23 22:00:02 | at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
INFO | jvm 2| 2005/11/23 22:00:02 | at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
INFO | jvm 2| 2005/11/23 22:00:02 | at
java.lang.reflect.Method.invoke(Method.java:585)
INFO | jvm 2| 2005/11/23 22:00:02 | at
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)
INFO | jvm 2| 2005/11/23 22:00:02 | at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
INFO | jvm 2| 2005/11/23 22:00:02 | at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO | jvm 2| 2005/11/23 22:00:02 | at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
INFO | jvm 2| 2005/11/23 22:00:02 | at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
INFO | jvm 2| 2005/11/23 22:00:02 | at
java.lang.reflect.Method.invoke(Method.java:585)
INFO | jvm 2| 2005/11/23 22:00:02 | at
org.tanukisoftware.wrapper.WrapperStartStopApp.run(WrapperStartStopApp.java:159)
INFO | jvm 2| 2005/11/23 22:00:02 | at
java.lang.Thread.run(Thread.java:595)
INFO | jvm 2| 2005/11/23 22:00:02 | 23.11.2005 22:00:02
org.apache.coyote.http11.Http11AprProtocol destroy
INFO | jvm 2| 2005/11/23 22:00:02 | INFO: Stopping Coyote HTTP/1.1
on http-20011
INFO | jvm 2| 2005/11/23 22:00:02 | 23.11.2005 22:00:02
org.apache.catalina.connector.Connector stop
INFO | jvm 2| 2005/11/23 22:00:02 | SCHWERWIEGEND: Coyote
connector has not been started
---
I have looked inside MapperListener Code
public void destroy() {
try {
ObjectName objectName = new ObjectName(
"JMImplementation:type=MBeanServerDelegate");
mBeanServer.removeNotificationListener(objectName, this);
} catch (Exception e) {
log.warn("Error unregistering MBeanServerDelegate", e);
}
}
But the only chance to get a NPE is that MapperListener was not
initialized!!
Very strange,
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross-Context Session Replication
Hey, I am highly interessed to support cross-context for cluster session replication. The session.endAccess is a neat place for support this. Please, let us discuss how we can use it. Any idea Peter Remy Maucherat schrieb: John Lewis wrote: As was discussed here over the summer, there is a need in the JSR-168 Portlet community to use cross-context access so that a portal webapp can communicate with various portlet webapps. Unfortunately, session replication in a Tomcat cluster does not occur when one webapp accesses another webapp's context and changes occur in the session of the target webapp. Unicon now has several clients that are extremely eager to see cross-context session replication support built into Tomcat. Given that this work would be difficult for someone not already familiar with the Tomcat code, are there any experienced Tomcat developers out there who would be interested in doing this work for pay? Of course we are eager to have this change incorporated into the main Tomcat code, so having an existing Tomcat committer do this would be ideal. If anyone qualified is interested, please contact me directly. We will undertake the effort ourselves if necessary, but obviously we would prefer to find a community-oriented solution to the problem. I proposed to use the session.endAccess method to do that, but nobody seemed interested in actually implementing it. 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: Cross-Context Session Replication
Yes, I implement this idea inside the ReplicationValve or a new one. I thing we support cross context session replication inside 5.5.14. Thanx Peter Remy Maucherat schrieb: Peter Rossbach wrote: Hey, I am highly interessed to support cross-context for cluster session replication. The session.endAccess is a neat place for support this. Please, let us discuss how we can use it. In your ClusteredSession, you can override endAccess (don't forget to call the superclass) and populate a thread local structure of some sort, or something like that. Then the valve looks at the structure and replicates all the sessions that need to be replicated. 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] Tomcat v5.5.14 Stability
5.5.14 [X] Beta - At least one significant issue preventing stability (please elaborate) I have found production critical bug inside cluster and fix the bug 37808 Currently I check other strange issues 37896 and implement the support for cross context session replication. Peter Yoav Shapira schrieb: Hi, Tomcat v5.5.14-beta has been out for about a week now. If you have tested it, please vote on its stability below using our usual guidelines. (And if you haven't tested it yet, please give it a whack ;)) Tomcat 5.5.14 is: [ ] Stable [ ] Beta - At least one significant issue preventing stability (please elaborate) [ ] Alpha - Multiple significant issues (please elaborate) As a reminder, only committer votes are binding. Everyone's opinion is welcome, of course. -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat v5.5.14 Stability
Hey! I have changed the cluster message header format long time ago 5.5.10. In some situations TCP Stack split the message, then the receiver byte array interpretation start to early. Arrggh, after first exception the receiver socket is hanging and replication transfer stops. Wait a little bit and tomcat crash with OutOfMemory or hanging. Peter Remy Maucherat schrieb: Yoav Shapira wrote: Hi, Tomcat v5.5.14-beta has been out for about a week now. If you have tested it, please vote on its stability below using our usual guidelines. (And if you haven't tested it yet, please give it a whack ;)) Tomcat 5.5.14 is: [ ] Stable [ ] Beta - At least one significant issue preventing stability (please elaborate) [ ] Alpha - Multiple significant issues (please elaborate) As a reminder, only committer votes are binding. Everyone's opinion is welcome, of course. There's that clustering bug that Peter said was critical :( So how critical is it ? Fix Bug 37808 -- 'java.lang.ArrayIndexOutOfBoundsException inside XByteBuffer.java. Very production critical bug, arrgh! 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] Tomcat v5.5.14 Stability
Hey Filip, it was a new one and is only inside >5.5.10 source. After I have change the message header format the bug is comes in. Now it is fixed. Every help is welcome. Peter Filip Hanik - Dev Lists schrieb: out of curiosity, I haven't yet been too much on the 5.5 platform, is this a new bug introduced, cause we have never seen it on 5.0 Filip Peter Rossbach wrote: Hey! I have changed the cluster message header format long time ago 5.5.10. In some situations TCP Stack split the message, then the receiver byte array interpretation start to early. Arrggh, after first exception the receiver socket is hanging and replication transfer stops. Wait a little bit and tomcat crash with OutOfMemory or hanging. Peter Remy Maucherat schrieb: Yoav Shapira wrote: Hi, Tomcat v5.5.14-beta has been out for about a week now. If you have tested it, please vote on its stability below using our usual guidelines. (And if you haven't tested it yet, please give it a whack ;)) Tomcat 5.5.14 is: [ ] Stable [ ] Beta - At least one significant issue preventing stability (please elaborate) [ ] Alpha - Multiple significant issues (please elaborate) As a reminder, only committer votes are binding. Everyone's opinion is welcome, of course. There's that clustering bug that Peter said was critical :( So how critical is it ? Fix Bug 37808 -- 'java.lang.ArrayIndexOutOfBoundsException inside XByteBuffer.java. Very production critical bug, arrgh! Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat v5.5.14 Stability
Compression is optional for cluster messages. Very big message can be set a flag that need compression. This flag is the header extension. Peter Filip Hanik - Dev Lists schrieb: interesting, why did the protocol header need to change? that is so old proven code. didn't know there was anything wrong with it. Filip Peter Rossbach wrote: Hey Filip, it was a new one and is only inside >5.5.10 source. After I have change the message header format the bug is comes in. Now it is fixed. Every help is welcome. Peter Filip Hanik - Dev Lists schrieb: out of curiosity, I haven't yet been too much on the 5.5 platform, is this a new bug introduced, cause we have never seen it on 5.0 Filip Peter Rossbach wrote: Hey! I have changed the cluster message header format long time ago 5.5.10. In some situations TCP Stack split the message, then the receiver byte array interpretation start to early. Arrggh, after first exception the receiver socket is hanging and replication transfer stops. Wait a little bit and tomcat crash with OutOfMemory or hanging. Peter Remy Maucherat schrieb: Yoav Shapira wrote: Hi, Tomcat v5.5.14-beta has been out for about a week now. If you have tested it, please vote on its stability below using our usual guidelines. (And if you haven't tested it yet, please give it a whack ;)) Tomcat 5.5.14 is: [ ] Stable [ ] Beta - At least one significant issue preventing stability (please elaborate) [ ] Alpha - Multiple significant issues (please elaborate) As a reminder, only committer votes are binding. Everyone's opinion is welcome, of course. There's that clustering bug that Peter said was critical :( So how critical is it ? Fix Bug 37808 -- 'java.lang.ArrayIndexOutOfBoundsException inside XByteBuffer.java. Very production critical bug, arrgh! 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] - 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 5.5.15?
+1 Thanks Peter Am 23.12.2005 um 20:28 schrieb Yoav Shapira: Hi, Are people ready for a 5.5.15 release? I'd specifically like to know that the showstoppers in 5.5.13 and 5.5.14, e.g. the clustering issue just mentioned by Filip in his other message, are resolved. If so, I'm ready to do a 5.5.15 release this weekend. -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Clustering broken 5.5.10-5.5.14
Many thanks for your helpful mail... I hope you have next year more time to work together and test the cluster implementation. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cutting Tomcat 5.5.15 tomorrow (Tuesday)
Hey, all my clustering fixes are committed. Fine, than I can start to finish the cross context session replication feature. Thanks Peter Am 03.01.2006 um 14:41 schrieb Yoav Shapira: I think so, based on Filip and Peter's +1 to me asking if a release was OK last weekend, and then I never cut that release... On 1/3/06, Remy Maucherat <[EMAIL PROTECTED]> wrote: Yoav Shapira wrote: Happy new year everyone ;) Unless I hear a -1 in response to this message, I will tag and cut Tomcat 5.5.15 tomorrow (Tuesday, 3 Jan 2006) at 10am my time (EST), which is 1500h GMT. Are you sure all the needed clustering fixes are in ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat v5.5.15 Stability
[x ] Stable - no major issues +1 to release 5.5.15 Peter Am 14.01.2006 um 16:37 schrieb Yoav Shapira: Hi, Tomcat v5.5.15-beta was released last week, and hopefully people have had time to test it a bit. If you have, please vote on its stability below. If you haven't, you still can test it a bit and let us know what you think ;) As a reminder, only Tomcat committer votes are binding, but everyone else is welcome to voice their opinion. [ ] Stable - no major issues [ ] Beta - at least one significant issue (what is it?) [ ] Alpha - multiple significant issues, not recommended for use (why?) -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: truncated server.xml got when storing config on condition that more than one vitual host with same application base directory "webapps" were defined.
Hey, see you any exception inside your log? Regards peter Am 16.01.2006 um 09:29 schrieb Yong Gou: The version of Tomcat server is 5.5.12 -Original Message- From: Yong Gou Sent: 2006年1月16日 16:24 To: dev@tomcat.apache.org Subject: truncated server.xml got when storing config on condition that more than one vitual host with same application base directory "webapps" were defined. Hi, I am not sure if the following is an issue of Tomcat JMX server or an improper usage? Is there anyone who has experienced the same? In addition to the virtual host localhost which is predefined by Tomcat server as the default on a Tomcat server, I created another virtual host testvh on the server with its attribute appBase being specified as webapps and other attributes having their default values via Tomcat admin console webapp, and then clicked the "commit changes" button to save all configurations to the server's server.xml file. The operations resulted in the following server.xml. NOTE that the Host, Engine, Service and Server elements are not closed. This is an incomplete server.xml. However if I specified another value other than webapps for its attribute appBase when the virtual host testvh was created, the issue would disappear and I could get a correct server.xml. You can try to define more virtual hosts with the same appBase webapps if two cannot reproduce the issue. className="org.apache.catalina.core.AprLifecycleListener"/> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener "/ className="org.apache.catalina.storeconfig.StoreConfigLifecycleListene r" /> d:\javadev\apache\tomcat2\conf\context.xmlWatchedReso urce> gy d:\javadev\apache\tomcat2\conf\context.xmlWatchedReso urce> Thanks, Eric - 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: truncated server.xml got when storing config on condition that more than one vitual host with same application base directory "webapps" were defined.
It storeconfig server.xml saving after add a new host works for me! I have tested with current svn head. create host with fixed MBean descriptor from MBeanFactory (Thanks for this) and store server.xml with mbean StoreConfig.storeConfig(). Regards Peter My saved server.xml looks like this: className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/ > className="org.apache.catalina.storeconfig.StoreConfigLifecycleListener" /> className="org.apache.catalina.mbeans.ServerLifecycleListener"/> Am 16.01.2006 um 11:03 schrieb Yong Gou: Hi Peter, There were just some info, no severe exception was thrown. You can try it in your environment. Thanks, Eric -Original Message- From: Peter Rossbach [mailto:[EMAIL PROTECTED] Sent: 2006年1月16日 17:39 To: Tomcat Developers List Subject: Re: truncated server.xml got when storing config on condition that more than one vitual host with same application base directory "webapps" were defined. Hey, see you any exception inside your log? Regards peter Am 16.01.2006 um 09:29 schrieb Yong Gou: The version of Tomcat server is 5.5.12 -Original Message- From: Yong Gou Sent: 2006年1月16日 16:24 To: dev@tomcat.apache.org Subject: truncated server.xml got when storing config on condition that more than one vitual host with same application base directory "webapps" were defined. Hi, I am not sure if the following is an issue of Tomcat JMX server or an improper usage? Is there anyone who has experienced the same? In addition to the virtual host localhost which is predefined by Tomcat server as the default on a Tomcat server, I created another virtual host testvh on the server with its attribute appBase being specified as webapps and other attributes having their default values via Tomcat admin console webapp, and then clicked the "commit changes" button to save all configurations to the server's server.xml file. The operations resulted in the following server.xml. NOTE that the Host, Engine, Service and Server elements are not closed. This is an incomplete server.xml. However if I specified another value other than webapps for its attribute appBase when the virtual host testvh was created, the issue would disappear and I could get a correct server.xml. You can try to define more virtual hosts with the same appBase webapps if two cannot reproduce the issue. className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListene r "/ className="org.apache.catalina.storeconfig.StoreConfigLifecycleListen e r" /> className="org.apache.catalina.realm.UserDatabaseRealm"/> d:\javadev\apache\tomcat2\conf\context.xml gy d:\javadev\apache\tomcat2\conf\context.xml Thanks, Eric - 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: Extending PersistentValve ?
Am 16.01.2006 um 20:12 schrieb Gary Blomquist: I would like to be able to use round robin loading balancing with a JDBCStore. However, it appears that using the PersistentManager with JDBC store could cause the sessions to be stale when a session migrates between workers due to the asyncronous behavior of the PersistentManager. (I realize their is a SimpleTcpCluster available as a clusterering solution but I can not use because it relies on multicast.) Wrote you own Membership tcp based service and use the real cluster implementation :-) At my feeling the old PersistentManager is only a deprecated prototyp and not a real cluster solution. Viewing the source it appears that the PersistentValve with the PersistentManager and JDBCStore could be a solution. It appears that it would load a session from the store at the begging of each request and save it back to the store at the end of the request. I would like to modify the behavior to only load/save when the session is dirty based on the last_access timestamps. Any comments on the solution? ( I realize their is some performance penalty due to object serialization and writing blobs to the database; however, in our case I think this would not be prohibitive esp. if there is a small amount of data in the session.) Also, when I attempt to run Tomcat with the PersistentValve I get the following exception: SEVERE: An exception or error occurred in the container during the request processing java.lang.ClassCastException: org.apache.catalina.core.StandardEngine at org.apache.catalina.valves.PersistentValve.invoke (PersistentValve.java:9 9) at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:1 48) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:744) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java: 674) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt (ChannelSocket. java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool .java:684) at java.lang.Thread.run(Thread.java:595) Note: (I have not yet made mods to the PersistentValue) Thanks for your assistance, Gary Blomquist - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: truncated server.xml got when storing config on condition that more than one vitual host with same application base directory "webapps" were defined.
Strange, but it work for me! I have also testet with the admin app and all is going as aspected. regards Peter Am 18.01.2006 um 04:46 schrieb Yong Gou: Hi Peter, I downloaded the 5.5.15 beta from Apache Tomcat downloads page and installed it on my desktop. But I found the same issue was still there with this version when I used its admin console webapp to add a new host and store config to the server.xml. The following is the resultant server.xml. className="org.apache.catalina.core.AprLifecycleListener"/> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener "/> className="org.apache.catalina.storeconfig.StoreConfigLifecycleListene r"/> className="org.apache.catalina.mbeans.ServerLifecycleListener"/> Thanks, Eric -Original Message- From: Peter Rossbach [mailto:[EMAIL PROTECTED] Sent: 2006年1月16日 18:30 To: Tomcat Developers List Subject: Re: truncated server.xml got when storing config on condition that more than one vitual host with same application base directory "webapps" were defined. It storeconfig server.xml saving after add a new host works for me! I have tested with current svn head. create host with fixed MBean descriptor from MBeanFactory (Thanks for this) and store server.xml with mbean StoreConfig.storeConfig(). Regards Peter My saved server.xml looks like this: className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener "/ className="org.apache.catalina.storeconfig.StoreConfigLifecycleListene r" /> Am 16.01.2006 um 11:03 schrieb Yong Gou: Hi Peter, There were just some info, no severe exception was thrown. You can try it in your environment. Thanks, Eric -Original Message- From: Peter Rossbach [mailto:[EMAIL PROTECTED] Sent: 2006年1月16日 17:39 To: Tomcat Developers List Subject: Re: truncated server.xml got when storing config on condition that more than one vitual host with same application base directory "webapps" were defined. Hey, see you any exception inside your log? Regards peter Am 16.01.2006 um 09:29 schrieb Yong Gou: The version of Tomcat server is 5.5.12 -Original Message- From: Yong Gou Sent: 2006年1月16日 16:24 To: dev@tomcat.apache.org Subject: truncated server.xml got when storing config on condition that more than one vitual host with same application base directory "webapps" were defined. Hi, I am not sure if the following is an issue of Tomcat JMX server or an improper usage? Is there anyone who has experienced the same? In addition to the virtual host localhost which is predefined by Tomcat server as the default on a Tomcat server, I created another virtual host testvh on the server with its attribute appBase being specified as webapps and other attributes having their default values via Tomcat admin console webapp, and then clicked the "commit changes" button to save all configurations to the server's server.xml file. The operations resulted in the following server.xml. NOTE that the Host, Engine, Service and Server elements are not closed. This is an incomplete server.xml. However if I specified another value other than webapps for its attribute appBase when the virtual host testvh was created, the issue would disappear and I could get a correct server.xml. You can try to define more virtual hosts with the same appBase webapps if two cannot reproduce the issue. className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListen e r "/ className="org.apache.catalina.storeconfig.StoreConfigLifecycleListe n e r" /> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"/> d:\javadev\apache\tomcat2\conf\context.xml gy d:\javadev\apache\tomcat2\conf\context.xml Thanks, Eric - 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] - To unsubscribe, e-mail: [EMAI
Re: Source for org.apache.coyote.tomcat5.CoyoteConnector
You can find the tomcat 5.5 connector source at org.apache.catalina.connector.Connector at the catalina/src/share dir. Peter Am 18.01.2006 um 14:30 schrieb Tri Le: Where can I find the source for org.apache.coyote.tomcat5.CoyoteConnector ? I dowloaded the source for Tomcat 5.5.12 but only saworg.apache.coyote.tomcat4.CoyoteConnector. Thanks for any help. - Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source for org.apache.coyote.tomcat5.CoyoteConnector
This class only exist at tomcat 5.0.x releases http://svn.apache.org/repos/asf/tomcat/container/branches/tc5.0.x/ catalina/src/share/org/apache/coyote/tomcat5/CoyoteConnector.java Peter Am 18.01.2006 um 15:54 schrieb Tri Le: Thanks Peter, but I'm looking for org.apache.coyote.tomcat5.CoyoteConnector, not org.apache.catalina.connector.Connector, which I have. Peter Rossbach <[EMAIL PROTECTED]> wrote: You can find the tomcat 5.5 connector source at org.apache.catalina.connector.Connector at the catalina/src/share dir. Peter Am 18.01.2006 um 14:30 schrieb Tri Le: Where can I find the source for org.apache.coyote.tomcat5.CoyoteConnector ? I dowloaded the source for Tomcat 5.5.12 but only saworg.apache.coyote.tomcat4.CoyoteConnector. Thanks for any help. - Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nightly builds broken
+1 to have nightly builds! Regards Peter Am 24.01.2006 um 16:52 schrieb Jeanfrancois Arcand: Hi Yoav, Yoav Shapira wrote: Hi, A user pointed out to me that our nightly builds appear to be broken. First I assumed it was due Gump unhappiness and I thought Mark T and Bill B fixed it over the past few days. But last night's builds still look whacky: http://cvs.apache.org/builds/jakarta-tomcat-5/ nightly/. The binaries are 45 bytes in size and invalid, the sources are about 200MB in size (Tomcat 5.5.15 correct source distros are a little less than 6MB). Also as an aside, all the Gump files still call it jakarta-tomcat-* rather than apache-tomcat-* or just tomcat-*. I'm not a Gump expert, but I believe the Gump project file we want to update is (at least) http://svn.apache.org/repos/asf/gump/metadata/project/jakarta- tomcat-catalina.xml. I've posted here a long time ago asking if we still want to have nightly or not, and got no response, So I stopped the script since it was still using CVS. Do we want nightly build? If yes, then I will fix the script and re-add it to the cron job. -- Jeanfrancois Thoughts? -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: eclipse compiler bug?
I fix this issue for 5.5.16.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38389
Regards
Peter
Am 27.01.2006 um 14:06 schrieb Yoav Shapira:
Hi,
Forwarding a message from the solr-dev list, one of my new hangouts,
that is relevant to Tomcat.
Yoav
-- Forwarded message --
From: Yonik Seeley <[EMAIL PROTECTED]>
Date: Jan 26, 2006 4:48 PM
Subject: eclipse compiler bug?
To: solr-dev@lucene.apache.org
Yoav, you might be interested in this one...
I had to comment out some generics stuff to get the JSP to work on
Tomcat 5.5.12. I didn't have time to look into it but my guess is
that the eclipse compiler got the signature incorrect for the generic
comparator. So if there is a newer version of the compiler, you might
want to upgrade.
Here is the modification I made to get it to work:
/***
// This generics version works fine with Resin, but fails with
Tomcat 5.5
// with java.lang.AbstractMethodError
//at java.util.Arrays.mergeSort(Arrays.java:1284)
//at java.util.Arrays.sort(Arrays.java:1223)
Arrays.sort(arr, new Comparator>() {
public int compare(List toks, List toks1) {
return toks.get(0).pos - toks1.get(0).pos;
}
}
***/
Arrays.sort(arr, new Comparator() {
public int compare(Object a, Object b) {
List toks = (List)a;
List toks1 = (List)b;
return toks.get(0).pos - toks1.get(0).pos;
}
}
);
https://svn.apache.org/repos/asf/incubator/solr/trunk/src/webapp/
resources/admin/analysis.jsp
search down for Tomcat
-Yonik
--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: IllegalState during invalidate a (Delta)Session.
Hey,
a) DeltaSession and StandardSession has the exact same behaviour.
b) SingleSignOn valve can't detect invalidation with call isValid()
expiring flag is true at the exipre call. It set to false after
SessionDestroy event is called. But before the event is fired, the
isValid flag is set to false.
--- DeltaSession and StandardSession
public boolean isValid() {
if (this.expiring) {
return true;
}
if (!this.isValid ) {
return false;
}
Only chance seams change lastAccessedTime condition
public long getLastAccessedTime() {
if (!expiring && !isValid) {
throw new IllegalStateException(sm
.getString
("standardSession.getLastAccessedTime.ise"));
}
return (this.lastAccessedTime);
}
or we must handle the ISE exception at SingleSignOn valve.
A testcase is very welcomed
Peter
Am 27.01.2006 um 17:00 schrieb Filip Hanik - Dev Lists:
I can't implement the change you suggest as it could result in a
circular loop,
expire - fire event - last access -> isValid() -> expire -> fire
event -> last access
I have added in the missing message for this event, if you are not
happy with that solution, please provide a simple test case for me
and I will make the adjustments
Filip
[EMAIL PROTECTED] wrote:
Hi there,
I've a little cluster with 4 Tomcats 5.5.12 running.
During tests I have found that exception while I
logged out a user on this cluster.
I hope this is the right Maillist for that problem...
java.lang.IllegalStateException: Cannot find message associated
with key standardSession.getLastAccessedTime
at
org.apache.catalina.cluster.session.DeltaSession.getLastAccessedTime(
DeltaSession.java:437)
at
org.apache.catalina.authenticator.SingleSignOn.sessionEvent
(SingleSignOn.java:298)
at
org.apache.catalina.cluster.session.DeltaSession.fireSessionEvent
(DeltaSession.java:1553)
at org.apache.catalina.cluster.session.DeltaSession.expire
(DeltaSession.java:735)
at org.apache.catalina.cluster.session.DeltaSession.expire
(DeltaSession.java:674)
at org.apache.catalina.cluster.session.DeltaSession.expire
(DeltaSession.java:662)
at
org.apache.catalina.cluster.session.DeltaSession.invalidate
(DeltaSession.java:1068)
at
org.apache.catalina.cluster.session.DeltaSessionFacade.invalidate
(DeltaSessionFacade.java:150)
I've searched the source-tree and changed the corresponding method
from :
---
public long getLastAccessedTime() {
if (!isValid) {
throw new IllegalStateException(sm
.getString
("standardSession.getLastAccessedTime"));
}
return (this.lastAccessedTime);
}
to (now it will call the isValid()-method instead of the isValid
field)
public long getLastAccessedTime() {
if (!isValid()) {
throw new IllegalStateException(sm
.getString
("standardSession.getLastAccessedTime"));
} return (this.lastAccessedTime);
}
---
This fixed my logout process immediately.
The same problem was with Tomcat 5.5.15.
Is that a known bug? Has anyone fixed this problem in an offical
patch?
--
regards,
Tom Neumann / tone
"Der Heitere ist der Meister seiner Seele."
William Shakespeare (1564 - 1616)
-
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]
Cluster - Extra Bytes at Message transfer?
Hey Flilp, == Question at cluster todo - Average message size For my test application, the average message size has increased from 526 bytes per message to over 750 bytes per message from version 5.0.28 to 5.5.15. Need to investigate why this is the case and where the 200+ extra bytes are coming from. == set the compress flag at cluster config. The default is false. This default save extra cpu and memory overhead for small messages. For big message like ALL_SESSION the default is manualy overwrite and transfer always with compression. regards Peter
Re: Cluster - questions
It implements aTCP/IP Socket receiver without NIO. This classes very useful for async mode at some linux platforms. Please, don't remove them, they are very important for some user. I think also we must discuss the next steps to change the cluster code. Regards Peter Am 09.02.2006 um 00:40 schrieb Filip Hanik - Dev Lists: What are the SocketReplicationListener and the SocketReplicationThread classes? seems like we are duplicating functionality. I'm planning on breaking out the membership and replication logic into a component so that we don't mix group messaging logic with session replication logic as they are two different classes. Looks like these classes are only referenced from the SimpleTcpCluster and it looks like they are an attempt to do what we already do. Question: Do we need them? Can I remove them? 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: svn commit: r377486 - /tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/mcast/McastService.java
Is that correct that you use now at McastService the same constant?
Before it was start(1) and start(2)
Peter
[EMAIL PROTECTED]
Am 13.02.2006 um 22:04 schrieb [EMAIL PROTECTED]:
Author: fhanik
Date: Mon Feb 13 13:04:20 2006
New Revision: 377486
URL: http://svn.apache.org/viewcvs?rev=377486&view=rev
Log:
Use constants instead of hard coding values
Modified:
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/
catalina/cluster/mcast/McastService.java
Modified: tomcat/container/tc5.5.x/modules/cluster/src/share/org/
apache/catalina/cluster/mcast/McastService.java
URL: http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/
cluster/src/share/org/apache/catalina/cluster/mcast/
McastService.java?rev=377486&r1=377485&r2=377486&view=diff
==
--- tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/
catalina/cluster/mcast/McastService.java (original)
+++ tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/
catalina/cluster/mcast/McastService.java Mon Feb 13 13:04:20 2006
@@ -257,8 +257,8 @@
* @throws java.lang.Exception if a IO error occurs
*/
public void start() throws java.lang.Exception {
-start(1);
-start(2);
+start(MembershipService.MBR_RX);
+start(MembershipService.MBR_RX);
registerMBean();
}
-
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: svn commit: r377486 - /tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/mcast/McastService.java
Ohh,
I see you have later correct this past bug. Thanks!
Are your current big changes not a very high risk to break the
cluster functionaliy again?
Why we not going inside a branch or a cluster2 module? Currently a
lot of user work very successfully with the tomcat 5.5.15 cluster. It
was my fault last year to changes to quick a lot.
Regards
Peter
[EMAIL PROTECTED]
Am 14.02.2006 um 07:37 schrieb Peter Rossbach:
Is that correct that you use now at McastService the same constant?
Before it was start(1) and start(2)
Peter
[EMAIL PROTECTED]
Am 13.02.2006 um 22:04 schrieb [EMAIL PROTECTED]:
Author: fhanik
Date: Mon Feb 13 13:04:20 2006
New Revision: 377486
URL: http://svn.apache.org/viewcvs?rev=377486&view=rev
Log:
Use constants instead of hard coding values
Modified:
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/
catalina/cluster/mcast/McastService.java
Modified: tomcat/container/tc5.5.x/modules/cluster/src/share/org/
apache/catalina/cluster/mcast/McastService.java
URL: http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/
modules/cluster/src/share/org/apache/catalina/cluster/mcast/
McastService.java?rev=377486&r1=377485&r2=377486&view=diff
=
=
--- tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/
catalina/cluster/mcast/McastService.java (original)
+++ tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/
catalina/cluster/mcast/McastService.java Mon Feb 13 13:04:20 2006
@@ -257,8 +257,8 @@
* @throws java.lang.Exception if a IO error occurs
*/
public void start() throws java.lang.Exception {
-start(1);
-start(2);
+start(MembershipService.MBR_RX);
+start(MembershipService.MBR_RX);
registerMBean();
}
-
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]
Unused code at Http11AprProcessor and Http11Processor
I have seen at Http11AprProcessor and Http11AprProcessor following
method that nobody used?
private boolean inStringArray(String sArray[], String value) {...
Can I remove this ?
Regards
Peter Roßbach
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cluster - questions
All java version support NIO, but we have some trouble with NIO at suse 9.3, jdk 1.5.0_01 and jdk 1.4.x when we stop some cluster members. Then I implement the simple SocketReplicationListener that is really stable for async mode. At async mode we not need a lots of parallell threads. Peter Am 15.02.2006 um 15:51 schrieb Filip Hanik - Dev Lists: Question, what Linux distributions that run Java 1.4 or higher (required for 5.5) do not support NIO? Filip Peter Rossbach wrote: It implements aTCP/IP Socket receiver without NIO. This classes very useful for async mode at some linux platforms. Please, don't remove them, they are very important for some user. I think also we must discuss the next steps to change the cluster code. Regards Peter Am 09.02.2006 um 00:40 schrieb Filip Hanik - Dev Lists: What are the SocketReplicationListener and the SocketReplicationThread classes? seems like we are duplicating functionality. I'm planning on breaking out the membership and replication logic into a component so that we don't mix group messaging logic with session replication logic as they are two different classes. Looks like these classes are only referenced from the SimpleTcpCluster and it looks like they are an attempt to do what we already do. Question: Do we need them? Can I remove them? 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r378050 - in /tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster: ./ deploy/ group/ session/ tcp/
Fine, but then we move ClusterListener from o.a.c.cluster.session. to default package o.a.c.cluster An independent message bus is very helpful and I like your changes. Great, Peter Am 15.02.2006 um 19:30 schrieb [EMAIL PROTECTED]: Author: fhanik Date: Wed Feb 15 10:30:02 2006 New Revision: 378050 URL: http://svn.apache.org/viewcvs?rev=378050&view=rev Log: Refactor: ClusterListener is not the same as MessageListener The ClusterListener is a listener that is added to the Cluster element. A MessageListener is solely a listener for messages on a replication channel
Re: AW: Tomcat Connector 1.2.15 - JkOption "FlushPackets"-Bug
I thing you mus set JkOptions +FlushPackets regards Peter Am 20.02.2006 um 09:28 schrieb Pelikan Stephan: JkOptions FlushPackets
Re: svn commit: r379463 - /tomcat/container/tc5.5.x/webapps/docs/changelog.xml
Am 21.02.2006 um 15:41 schrieb [EMAIL PROTECTED]: + +HttpSession.getId will no longer throw an ISE when the session is invalid (remm) + Can we reflect the change also to getLastAccessedTime() ? I thing the DeltaSession need the same change. Peter
Re: svn commit: r379938 - /tomcat/container/tc5.5.x/modules/cluster/to-do.txt
Hey Filip. I have add the compress flag inside the protocol. It is usefull to send message with an without compression. For short messages it is not usefull to compress, it is an overhead. Before 5.5.15 you made a vote that we carefull with protocol changes, Why you now change so much inside one minor tomcat release ? -1 for this change. regards Peter Am 22.02.2006 um 23:02 schrieb [EMAIL PROTECTED]: Author: fhanik Date: Wed Feb 22 14:02:20 2006 New Revision: 379938 URL: http://svn.apache.org/viewcvs?rev=379938&view=rev Log: minor change to the todo, compression will get removed from the protocol. This is the feature that caused a major headache when the protocol changed. well, its gonna change again, back to what it was. compression should not be done at that level since it leaves no pluggability for compression protocol to use. Modified: tomcat/container/tc5.5.x/modules/cluster/to-do.txt Modified: tomcat/container/tc5.5.x/modules/cluster/to-do.txt URL: http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/ cluster/to-do.txt?rev=379938&r1=379937&r2=379938&view=diff == --- tomcat/container/tc5.5.x/modules/cluster/to-do.txt (original) +++ tomcat/container/tc5.5.x/modules/cluster/to-do.txt Wed Feb 22 14:02:20 2006 @@ -108,7 +108,7 @@ Need help (pero) - implement fragmentation of large replication objects (note this will be done in the Group object, see top.) - Compress at message level + Compress at message level - this will go away! instead there will be a GZip interceptor Splitting Messages ala FarmDeployer war handling - add a message type to the message header. - filtering at receiver that drop message before build Object - 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]
tomcat 5.5 Cluster and JMX
Hey Filip
Why do you think we must move the cluster JMX MBean code?
OK, then we can use the cluster components without JMX, but is this
really usefull?
A lot of my customers have add there own monitoring to the current
cluster MBeans.
This is really important to see trends and analyse bad szenarios at
production level.
The most tomcat components have no separate MBean classes. When we
move to separate classes we get
a lot of classes with redundant get/setter attributes and operation
signatures.
Here the only chance to guarantee consistens is generation of the
associated MBeans.
The reasons
behind I added the JMX code direclty into the cluser component
implementation are:
- The clustet component controls the JMX
capabilities
- When we move the mbean code out, we need a factory to create
cluster components
and the associate MBeans.
- Start the cluster without JMX should be not an option
- The dynamic lifecycle of cluster senders is not easy to manage
- Digester class creation is another point.
- Easy to implement and to hold consistent with other tomcat components
OK, I also do not love the "backed" JMX code , but before moving we
should discuss this point!!!
regards
Peter
Am 22.02.2006 um 23:57 schrieb [EMAIL PROTECTED]:
Author: fhanik
Date: Wed Feb 22 14:57:35 2006
New Revision: 379956
URL: http://svn.apache.org/viewcvs?rev=379956&view=rev
Log:
supressing JMX errors for now, since the code will be moved to JMX
monitor beans
Modified:
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/
catalina/cluster/tcp/ReplicationTransmitter.java
Modified: tomcat/container/tc5.5.x/modules/cluster/src/share/org/
apache/catalina/cluster/tcp/ReplicationTransmitter.java
URL: http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/
cluster/src/share/org/apache/catalina/cluster/tcp/
ReplicationTransmitter.java?rev=379956&r1=379955&r2=379956&view=diff
==
--- tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/
catalina/cluster/tcp/ReplicationTransmitter.java (original)
+++ tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/
catalina/cluster/tcp/ReplicationTransmitter.java Wed Feb 22
14:57:35 2006
@@ -714,7 +714,7 @@
mserver.unregisterMBean(getSenderObjectName(sender));
}
} catch (Exception e) {
-log.warn(e);
+if ( log.isDebugEnabled() ) log.debug
("'ReplicationTransmitter' Unable to to deregister IDataSender",e);
}
}
@@ -738,7 +738,7 @@
mserver.registerMBean(cluster.getManagedBean(sender),
senderName);
} catch (Exception e) {
-log.warn(e);
+if ( log.isDebugEnabled() ) log.debug
("'ReplicationTransmitter' Unable to register sender bean",e);
}
}
}
@@ -764,7 +764,7 @@
+ sender.getAddress().getHostAddress() +
",senderPort="
+ sender.getPort());
} catch (Exception e) {
-log.warn(e);
+if ( log.isDebugEnabled() ) log.debug
("'ReplicationTransmitter' Unable to retrieve sender name",e);
}
return senderName;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.5 Cluster and JMX Re: svn commit: r379938 - /tomcat/container/tc5.5.x/modules/cluster/to-do.txt
Hey Filip, what I see is you want make an innovative step. Great, I m very motivated to help that we implement a next generation. But, why do we this implementation not inside a sandbox, branch or separate module? Last year I learned that big changes are great, but it is easy to make failures at very little details, like the compress flag bug. To design a new implementation is risky. A lot of projects and people now use very succesfull the current tomcat 5.5.15 cluster. Some people are waiting that we release the cross context replication to support portal development. Please, I do not want to stop the innovation, but why do we not start the new cluster design at a separate module and set the current code base at maintaince mode? Peter Roßbach Am 23.02.2006 um 12:59 schrieb Filip Hanik - Dev Lists: Peter Rossbach wrote: >I have add the compress flag inside the protocol. >It is usefull to send message with an without compression. >For short messages it is not usefull to compress, it is an overhead. There is no question whether compression is useful or not. The compression flag should have never been added in the protocol in the first place, Compression can and should be done on a higher level, and the algorithm should be pluggable. Adding it to the protocol is like adding a compression flag to a TCP frame, and its a hack, And it caused 4 stable releases of tomcat to be broken. The flag should have been a flag in the payload, configurable by the component requesting to send the data as that component is suitable for making that decision compression will still be configurable on a per message basis, but with a different design. >Before 5.5.15 you made a vote that we carefull with protocol changes, I didn't make a vote, I advised against it, as if you don't understand the code as it is pretty detailed and complex, then you shouldn't be changing it without a full set of regression tests. 4 broken releases should testify to that. >Why you now change so much inside one minor tomcat release ? Cause it is long needed and long awaited. The way the code got cluttered in 5.5 with JMX,core replication, io and session replication all mixed together, means that I cant extend nor can I implement any useful features. For example, if I wanted to implement a ComplexTcpCluster class, I have to rewrite all JMX code again, I have to rewrite all statistics code again, I have to basically rewrite session replication again. This was never the intention of this module. The module should provide for much flexibility. >Why do you think we must move the cluster JMX MBean code? For the exact reasons above. I could have written the entire module in one single class, JMX, IO, session logic, member logic. But there was a reason I didn't. Flexibility. Hardcoding JMX against code is not flexible. Instead the right way is to build the MBeans against an interface, cause I can change the underlying component without having to rewrite the JMX code. The way it is now is doesn't allow for this. >The most tomcat components have no separate MBean classes and this is a good thing? probably not, but and the rest of the components do, does not set a precedence. Otherwise, if we had one bad class, then all others should follow? >When we move to separate classes we get >a lot of classes with redundant get/setter attributes and operation signatures. not at all, if you move it to a separate MBean class, I can have 50 different cluster implementations The way it is now, I would have 50 different MBeans, now that is redundancy. The way I am suggesting, you will have one at all times. >The reasons >behind I added the JMX code direclty into the cluser component implementation are: JMX has been added to several component, not just the cluster class. for reasons mentioned above, this is not suitable. >-1 for this change. I would be careful putting -1 out there, it causes a lot of friction, especially when they have no justification. I am working on a improved design, a design that was intended from the beginning but I got sidetracked with another job not giving me the time to complete the full circle. I now have that opportunity and intend to see it through. If you want to be a part of it, I suggest you come with constructive ideas to move the project forward and not just veto changes with no justifications. If we didn't want this project to improve we would still be using Tomcat 3, but the world of hi-tech changes everyday. All of those changes have the intention for improvements, not all of them succeed. But that is nature of the industry we are in. I hope this answers all your concerns and makes you redraw your veto or justify it with a better suggestion. best regards, Filip - To
Re: tomcat 5.5 Cluster and JMX Re: svn commit: r379938 - /tomcat/container/tc5.5.x/modules/cluster/to-do.txt
Hey Filip can you tell us more about the your change plans, and how I can help? I thing the current cluster changes are a high risk and it was better to start those changes for TC 6. When next cluster generation is stable, then we make a backport to TC 5.5 One of me ideas is, that we build a cluster regession test suite. I start a ant base cluster config generation project and hope I finished this work at middle of next month. Peter Roßbach Q: Break your ReplicationListener/ClusterReceiverBase change the cluster default mode ? Q: Have you test your changes with the other ClusterReceiver class SocketReplicationListener ? see other comments Am 23.02.2006 um 14:07 schrieb Filip Hanik - Dev Lists: new features and new development has historically always been done against the head revision. If you want to put something into maintenance, then that becomes a branch for example VERSION | ---> HEAD REV ---> NEW DEVELOPMENT | | ---> BRANCH ---> MAINTENANCE MODULE in our case 5.5.15 | ---> HEAD REV ---> NEW CLUSTER DEVELOPMENT | | ---> OLD CLUSTER COMPONENT BRANCH ---> MAINTENANCE MODULE FOR THE WAY IT IS TODAY To calm your nerves a little bit, I don't plan to pull out the JMX, nor to make major server.xml conf changes for 5.5.x, but it is on the horizon for TC6. For 5.5.x the server.xml will remain similar to what it is today, ie, almost backwards compatible (minus the changes I already made). TC 6 will have a completely new conf. Please, can you post a example or an proposal for that change! TC 5.5.x will have a TC6 style new conf enabled added for the users that want to take advantage of plugging in their own message interceptors and to do primary/secondary backup replication which I intend to have complete by 5.5.16/17 depending on when those releases get cut. This timing is one of my problems. The compression flag will get taken out of the protocol, replaced with a default compression interceptor is compress="true". so functionality will not change for the users either. OK, What design change you plan? All message pass a interceptor chain? Filip Peter Rossbach wrote: Hey Filip, what I see is you want make an innovative step. Great, I m very motivated to help that we implement a next generation. But, why do we this implementation not inside a sandbox, branch or separate module? Last year I learned that big changes are great, but it is easy to make failures at very little details, like the compress flag bug. To design a new implementation is risky. A lot of projects and people now use very succesfull the current tomcat 5.5.15 cluster. Some people are waiting that we release the cross context replication to support portal development. Please, I do not want to stop the innovation, but why do we not start the new cluster design at a separate module and set the current code base at maintaince mode? Peter Roßbach Am 23.02.2006 um 12:59 schrieb Filip Hanik - Dev Lists: Peter Rossbach wrote: >I have add the compress flag inside the protocol. >It is usefull to send message with an without compression. >For short messages it is not usefull to compress, it is an overhead. There is no question whether compression is useful or not. The compression flag should have never been added in the protocol in the first place, Compression can and should be done on a higher level, and the algorithm should be pluggable. Adding it to the protocol is like adding a compression flag to a TCP frame, and its a hack, And it caused 4 stable releases of tomcat to be broken. The flag should have been a flag in the payload, configurable by the component requesting to send the data as that component is suitable for making that decision compression will still be configurable on a per message basis, but with a different design. >Before 5.5.15 you made a vote that we carefull with protocol changes, I didn't make a vote, I advised against it, as if you don't understand the code as it is pretty detailed and complex, then you shouldn't be changing it without a full set of regression tests. 4 broken releases should testify to that. >Why you now change so much inside one minor tomcat release ? Cause it is long needed and long awaited. The way the code got cluttered in 5.5 with JMX,core replication, io and session replication all mixed together, means that I cant extend nor can I implement any useful features. For example, if I wanted to implement a ComplexTcpCluster class, I have to rewrite all JMX code again, I have to rewrite all statistics code again, I have to basically rewrite session replication again. This was never the intention of this module. The module should provide for much flexibility. >Why do you think we must move the cluster JMX MBean code? For the exact reasons above. I could have written the entire
Re: tomcat 5.5 Cluster and JMX Re: svn commit: r379938 - /tomcat/container/tc5.5.x/modules/cluster/to-do.txt
Am 23.02.2006 um 15:05 schrieb Filip Hanik - Dev Lists: >Peter Rossbach wrote: as you might understand, it will take me longer time to explain the design to you than to just do it, and you can learn it from the code itself. you'll catch on it it eventually. That is a way, but I thing like Rainer, better we do those changes for TC6 code base first. >Q: Break your ReplicationListener/ClusterReceiverBase change the cluster default mode ? I don't understand the question. The current tomcat 5.5.15 has a simple cluster configuration option. see HowTo className="org.apache.catalina.cluster.tcp.SimpleTcpCluster"/> Setup with SocketReplicationListener and fastasyncqueue mode. I use this mode at my training courses. People see that first cluster setup is simple. Later all the special cluster configuration option comes, but start is simple and powerful. >One of me ideas is, that we build a cluster regession test suite. >I start a ant base cluster config generation project and hope I finished >this work at middle of next month. excellent, I have a home grown test suite for replication accuracy in synchronized mode, I can donate that to you. Great, mail the suite me. Thanks! >Q: Have you test your changes with the other ClusterReceiver class SocketReplicationListener ? Not yet, its on the agenda. Then simple cluster setup currently not working. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cluster maintenance and improvement
Many thanks! I thing the best way is to move the new cluster implementation at a new cluster2 module. With the current cluster build system it is easy to generate and copy the calalina-cluster.jar to tomcat local build directory. The only problem currently is ClusterRuleSet must be move from catalina core to the cluster module. Peter Am 23.02.2006 um 16:50 schrieb Remy Maucherat: Filip Hanik - Dev Lists wrote: Rainer, all are very good thoughts. Here is why I opt we still move forward 1. If we don't primary/secondary will not be available until TC.6 2. TC 6 doesn't have a skeleton nor a date yet. It could have that tomorrow. Great! 3. Many people are opting out of clustering today because of lack of primary/sec. all-to-all is too inefficient for the general public JBoss clustering doesn't have primary/sec, and many people are still using it. It would be a useful feature for sure, but not having it doesn't mean people aren't going to use clustering. I also have a lot of customer that work very succesful without primary/sec. 4. Many of the needed features needed for a more complete clustering solution are not possible today due to the tight coupling between components. 5. The instability caused in 5.5.10-5.5.14 could have easily been detected and should have not lasted for four releases. I doubt we should see that again. Personally, I've had the impression that virtually all builds had issues of some sort, although 5.5.9 might have been fine. 6. I'm ready and have the time and commitment to support any changes I make. I am happy to have a 5.5.15-cluster branch for bug fixes This way when 5.5.16 comes out, the users can choose which one to use. But I would be stretching myself thin trying to maintain two code bases. This maintenance branch is easy to create, just branch the entire cluster module plus ClusterRuleSet.java, and it is complete. The main reason being that I don't think I would want to wait for TC6 to provide primary/secondary replication. I also don't think that users wanting more features should suffer because of previous lack of testing. To delay this out of plain "fear of breaking" doesn't seem reasonable to me, if the code base is so messed up that we are too afraid to "touch" it, then it needs to be fixed sooner than later. I have no problem putting this up for a vote, but so far, the only justifications are concerns, when I believe I can offer more features and an easier codebase to maintain. I agree with Peter: it's obvious no one should be doing major refactoring of existing components in 5.5.x. You could create a separate "cluster2" module if you still want to do the work in Tomcat 5.5.x, however. +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: Cluster maintenance and improvement
Hey Rainer, Filip and Remy, Am 23.02.2006 um 17:20 schrieb Rainer Jung: Hi Remy, 1. If we don't primary/secondary will not be available until TC.6 2. TC 6 doesn't have a skeleton nor a date yet. It could have that tomorrow. ... I agree with Peter: it's obvious no one should be doing major refactoring of existing components in 5.5.x. You could create a separate "cluster2" module if you still want to do the work in Tomcat 5.5.x, however. So in general we have three options: A) maintenance branch inside 5.5.15 B) cluster2 module +1 and revert the changes at the current tomcat cluster head I think Revision 366257 5.1.2006 or a little bit later. Then we can make a separate jar download for cluster2 and when is stable, we change the default at the tomcat 55 distribution. C) making changes in TC 6 Whichever way we choose, I think we need two lines of development: a) one which tries to stick closely to the 5.5.15 code and only picks up security fixes and changes needed to keep compatibility with 5.5.x. I think we integrate the cross context replication and some of the fixes from Filip inside the TC 5.5.15 cluster module code. b) another one which gets all the refactoring, new features and improvements. We have to make decisions: - maintenance for a): If we let die a) for TC 6, we should document that decision, so would deprecate a) now. This sounds a little harsh, but that's in fact what we then do. It would be nice to support a) at least 12 months after announcement of deprecation. - release bundles: I think a) and b) should be available for download when a new 5.5 release is done. I don't really care about having seperate download file or not. I thing it is easy to have seperate download files +1 - default configuration entries in server.xml +1, from current cluster module and later from new cluster2 state. Concerning A), B) or C): Remy: what do you think, about how long dows it take to make a first alpha releaseof TC 6. I didn't follow closely the state of Specs and implementations. I expect that to still need 2 to 3 months. If I'm right, that means C) will not work out for Filip, because then he lacks the necessary amount of users playing around with the new code. Decision between B) and C) depends more on the kind of message one needs to send to the user base. My impression is, that at the end the cluster code will have huge differences to it's state today and it would be more correct to have cluster2. But I could live with all parallel options, as long as we keep the old code compatible with 5.5.x and we document the plan for the future (maintenance/ deprecation) for the user base. I like to have a new cluster2 module inside Tomcat 5.5. After we finish and have a stable cluster2 we move it also to tc6. I can maintain the current 5.5.15 implementation stage. Rainer - 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 maintenance and improvement
Am 23.02.2006 um 16:51 schrieb Rainer Jung: Hi Filip, thanks for taking it seriously! 1. If we don't primary/secondary will not be available until TC.6 > 3. Many people are opting out of clustering today because of lack of > primary/sec. all-to-all is too inefficient for the general public I understand your primary motivation. It#s true, primary/secondary would be a major improvement. There is one feature that exists now and was not available in 2004, that relaxes some of the all-to-all problems. We donated enhancements to mod_jk which were taken up by Mladen Turk: the domain attribute for a worker. So what is already possible today, is a static grouping of cluster nodes into domains. From the tomcat perspective that means, you configure multiple disjoint clusters. From the mod_jk perspective this means, that you sessions will always be routed to a node inside the same tomcat cluster (domain in mod_jk notation), and only if all nodes in the domain are in error state, the requests are routed to some node who does not have the session. In some way it is a very basic static promary/secondary feature and it only works in conjunction with mod_jk. This is very bare bone, but I know several people who build their 4 to 9 cluster nodes on top of that construction. In fact, susually they had their nodes segmented in network terms in smaller groups anyhow, so breaking up the cluster into domains fitted their needs well. My greatest cluster have 5 domains with 20 tomcat instance up and runnnig, but we must change the mod_jk code a little bit. The site has a lot of traffic and is very stable. Of course, having a dynamic and more transparent primary/secondary construction is much more useful. I just want to indicate, why I know serveral users, who could work successfully with "all-to-all", restricted to domains. I also :-) 2. TC 6 doesn't have a skeleton nor a date yet. 5. The instability caused in 5.5.10-5.5.14 could have easily been detected and should have not lasted for four releases. I doubt we should see that again. > 6. I'm ready and have the time and commitment to support any changes I > make. I am happy to have a 5.5.15-cluster branch for bug fixes > This way when 5.5.16 comes out, the users can choose which one to use. > > To delay this out of plain "fear of breaking" doesn't seem reasonable to > me, if the code base is so messed up that we are too afraid to "touch" > it, then it needs to be fixed sooner than later. > I'm very happy about your commitment - really! We really need to push the clustering forward and it's fantastic to have you back! Yes, it was very nice that you have time and back on board. I like to work together an build another tomcat cluster innovation. But we must very careful with the existing users. I like your idea of a 5.5.15 maintenance branch. But I'm not sure, if we share the same idea, how that will be maintained. For me it would be OK to freeze the actual cluster code in the 5.5.15 maintenance branch. The only changes to this branch would be - bug fixes for important bugs without work-arounds which will only need changes in small parts of the code (low complexity) - security fixes - bug fixes needed for compatibility with TC core 5.5, e.g. adoption of changes to Manager or Session. +1 So I would like to keep that branch stable, but compatible with 5.5. Would that be OK for you? 4. Many of the needed features needed for a more complete clustering solution are not possible today due to the tight coupling between components. But I would be stretching myself thin trying to maintain two code bases. This maintenance branch is easy to create, just branch the entire cluster module plus ClusterRuleSet.java, and it is complete. I agree, so do we have the same idea of the amount of maintenance for the maintenance branch? I'm pretty sure, Peter will be happy keeping that branch in shape (I think he leaves for holidays now, but he will be back next week). Yes, and now I start I have no problem putting this up for a vote, but so far, the only justifications are concerns, when I believe I can offer more features and an easier codebase to maintain. Voting is good, exchange of arguments as well. I think some of our concerns are not just theoretically. Major changes are needed and major changes usually break things for some time. So we are just trying to find out how to combine the grown user base and the needed improvements. I think your idea of a maintenance branch is just right. I think to create a new cluster2 module is the right way. Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,
Re: New clustering module proposal - WAS: Long rants
Sounds very great +1 many thanks and now I can start very relaxed to my short journey :-) Peter Am 23.02.2006 um 18:25 schrieb Filip Hanik - Dev Lists: Sounds like there is a consensus amongst folks. So to summarize everyones thoughts, let me know if this sounds like a solution agreeable to everyone. 1. Keep 5.5.x as a maintenance module as it was of 5.5.15 + cross context 2. Break out cluster config from catalina.jar to catalina- cluster.jar that way we can enable more than one config In Catalina.java have a ClusterRuleSetFactory.getClusterRuleSet() that will load the rule set run time. 3. Create two new modules (to use for TC6 and as an optional library for TC 5.5.x) a) Name:groupcom Lib : catalina-groups.jar Purpose: Group messaging component b) Name: ha Lib : catalina-cluster.jar Purpose: session replication logic, context attribute replication and other new features Lets gather one round of feedback and then vote so that I can move on with new dev. 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: TomCat monitoring
Look here http://tomcat.apache.org/tomcat-5.5-doc/monitoring.html Peter Am 24.02.2006 um 19:22 schrieb Michael Gesundheit: Hi, I'm looking for any information concerning TomCat runtime monitoring. Resources status, Memory consumption etc. I could not find any material about this issue on the official web site. Any clue? Thanks, -Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 source organisation
We can have maven2 dependency management without use maven2 complete. see. http://maven.apache.org/ant-tasks.html I thing maven is good for standard prepare/compile/test, but is heavy to use with spezial things like the current tomcat release build. I have heard that some "go back to ant" discussion start at the jetspeed project. Peter Am 28.02.2006 um 17:50 schrieb Keith Wannamaker: +1 for consolidating into a single module/src folder. maven has matured since I last looked. It seems the biggest advantages for us would be dependency management and a common build layout. I don't have a feel for how much work it would take to convert, but it doesn't seem like we would loose much if that approach were taken. Keith Remy Maucherat wrote: Hi, I think it is time to decide how the source repository is going to be organized, with the questions being: - how many source folders do we need (Costin wanted one, while others like Jacob seem to want "modules") ? - do we continue to use Ant ? - etc Any ideas ? 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 build ?
I also check at weekend the current cluster base again my test case. Peter Am 28.02.2006 um 18:30 schrieb Yoav Shapira: OK, then, how does the weekend look for a Tomcat release? That'll give everyone a few days to maybe close out some other Bugzilla issue... Yoav On 2/28/06, Remy Maucherat <[EMAIL PROTECTED]> wrote: Yoav Shapira wrote: Are all the fixes for JIRA in? Yes, it seems so. Getting production testing for AJP APR and the other new components has been good. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [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: Tomcat 6 source organisation
Yes! I also thing we don't use maven2. +1 to use ant Peter Am 28.02.2006 um 19:49 schrieb Bill Barker: -Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 28, 2006 10:24 AM To: Tomcat Developers List Subject: Re: Tomcat 6 source organisation On 2/28/06, Peter Rossbach <[EMAIL PROTECTED]> wrote: We can have maven2 dependency management without use maven2 complete. see. http://maven.apache.org/ant-tasks.html We've had some problems with the tasks over in Gump-land. I have no problem with using maven or similar tasks for downloading the deps, if they can provide the same functionality with our build hacks, or at least use them for the simple cases. I'm not sure that Maven could handle the current tomcat-dbcp task well, and I don't really see a use-case for a mixed dependency management system myself. I'm just -1 on using a framework that forces a particular way to do things ( nothing personal with maven, same -1 for any other framework :-). I know people have religious ideas about right and wrong, and frameworks is an expression of this - I just hope I won't see this in tomcat... Also my personal opinion. Also, Gump doesn't currently support Maven2, so we'd loose Gump by going to Maven2 (which, some people might think is a-good-thing :). It may be good to look at what other options exists for download and pick one that is easy to use and fits well - maven might be the best or not, that's one benefit of picking components and tools instead of 'they know better' frameworks. Costin I thing maven is good for standard prepare/compile/test, but is heavy to use with spezial things like the current tomcat release build. I have heard that some "go back to ant" discussion start at the jetspeed project. Peter Am 28.02.2006 um 17:50 schrieb Keith Wannamaker: +1 for consolidating into a single module/src folder. maven has matured since I last looked. It seems the biggest advantages for us would be dependency management and a common build layout. I don't have a feel for how much work it would take to convert, but it doesn't seem like we would loose much if that approach were taken. Keith Remy Maucherat wrote: Hi, I think it is time to decide how the source repository is going to be organized, with the questions being: - how many source folders do we need (Costin wanted one, while others like Jacob seem to want "modules") ? - do we continue to use Ant ? - etc Any ideas ? 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] 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r382141 - in /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp: AsyncSocketSender.java DataSenders.properties
Hey Filip, can we also remove SocketSender? I think PooledSender with queue size 1 is good alternative. Then we must only support one async and sync sender. :-) Peter Am 01.03.2006 um 21:02 schrieb [EMAIL PROTECTED]: Author: fhanik Date: Wed Mar 1 12:02:14 2006 New Revision: 382141 URL: http://svn.apache.org/viewcvs?rev=382141&view=rev Log: Removed the async socket sender, this is obsolete. We are keeping the FastAsync for java.io support on platforms where NIO is troublesome Removed: tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/ catalina/tribes/tcp/AsyncSocketSender.java Modified: tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/ catalina/tribes/tcp/DataSenders.properties Modified: tomcat/container/tc5.5.x/modules/groupcom/src/share/org/ apache/catalina/tribes/tcp/DataSenders.properties URL: http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/ groupcom/src/share/org/apache/catalina/tribes/tcp/ DataSenders.properties?rev=382141&r1=382140&r2=382141&view=diff == --- tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/ catalina/tribes/tcp/DataSenders.properties (original) +++ tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/ catalina/tribes/tcp/DataSenders.properties Wed Mar 1 12:02:14 2006 @@ -1,4 +1,3 @@ fastasyncqueue=org.apache.catalina.tribes.tcp.FastAsyncSocketSender -asynchronous=org.apache.catalina.tribes.tcp.AsyncSocketSender synchronous=org.apache.catalina.tribes.tcp.SocketSender pooled=org.apache.catalina.tribes.tcp.PooledSocketSender - 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: svn commit: r383120 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/StandardSession.java
Oops... Am 04.03.2006 um 16:54 schrieb Remy Maucherat: [EMAIL PROTECTED] wrote: Author: pero Date: Sat Mar 4 06:45:50 2006 New Revision: 383120 URL: http://svn.apache.org/viewcvs?rev=383120&view=rev Log: remove also ISE from getLastAccessTime to support SingleSignOn. Although this is blatantly not spec compliant (so, -1 for your change), I undertsand this specification violation :) You should have reported it earlier, and I would have mentioned it to the Servlet expert group along with the getId issue. The reason for my -1 is that this behavior has been like this forever, so there's no reason to change our minds all of a sudden without at least a way to revert the specification compliant mechanism. I may remove my -1 after hearing other's opinion, and adding such a mechanism. For stuff which could be tested by TCK assertions, but which do not make sense in production for whatever reason, and could not be changed through the JCP (because of no expert group consensus, or just spec lifecycle issues), I propose adding a new system property like (javax.servlet.strict=true/false, with the default being false), and a matching static final field in Globals. This change to getLastAccessTime should most likely use the field. +1 for that... But currently the SSO not work and also we must revert the patch at DeltaSession. Other idea is we can move expiring flag after removeAttribuiteInternal() StandardSession -- expire(boolean) // Unbind any objects associated with this session String keys[] = keys(); for (int i = 0; i < keys.length; i++) removeAttributeInternal(keys[i], notify, false); // We have completed expire of this session expiring = false; Sorry, but some people ask me that SSO not work anymore. Peter 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] Apache Tomcat v5.5.16 Stability
Yes, I have fix it but 5.5.16 is very stable. The release fix some very critcal APR AJP bugs! Peter Am 12.03.2006 um 19:16 schrieb Filip Hanik - Dev Lists: wasn't there an issue with SSO and clustering? Peter? Filip Yoav Shapira wrote: Hi, Apache 5.5.16 (tentatively rated at beta stability pending further testing) has been available for about a week now. If you've had time to test it, please vote below. If you haven't, please take a bit of time and test it using your favorite tool or application, then vote below: this vote will run for about 72 hours. As usual, committer votes are binding, but everyone's input is welcome. Thank you. Apache Tomcat v5.5.16 is: [ ] Stable (no major issues) [ ] Beta (at least one major issue: please provide details) [ ] Alpha (multiple significant issues: please provide details) Yoav -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Apache Tomcat v5.5.16 Stability
Apache Tomcat v5.5.16 is: [x ] Stable (no major issues) minor issue that SSO not work! [ ] Beta (at least one major issue: please provide details) [ ] Alpha (multiple significant issues: please provide details) Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why we need at Http11AprProtocol a synchronization?
At a small review I find this inside:
o.a.coyote.http11.Http11AprProtocol
..
public boolean process(long socket) {
...
L: 619
if (proto.getDomain() != null) {
synchronized (this) {
try {
RequestInfo rp = processor.getRequest
().getRequestProcessor();
...
==
Why the RequestInfo MbeanServer registration need a synchronization?
regards
peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r386120 - /tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java
Thanks, :-)
Peter
Am 15.03.2006 um 18:29 schrieb [EMAIL PROTECTED]:
Author: remm
Date: Wed Mar 15 09:29:02 2006
New Revision: 386120
URL: http://svn.apache.org/viewcvs?rev=386120&view=rev
Log:
- As suggested by Peter, move getWorkerThread inside the try (an
OOM could occur). This isn't going
to help the server much, though.
Modified:
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/
AprEndpoint.java
Modified: tomcat/connectors/trunk/util/java/org/apache/tomcat/util/
net/AprEndpoint.java
URL: http://svn.apache.org/viewcvs/tomcat/connectors/trunk/util/
java/org/apache/tomcat/util/net/AprEndpoint.java?
rev=386120&r1=386119&r2=386120&view=diff
==
--- tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/
AprEndpoint.java (original)
+++ tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/
AprEndpoint.java Wed Mar 15 09:29:02 2006
@@ -900,11 +900,10 @@
}
}
-// Allocate a new worker thread
-Worker workerThread = getWorkerThread();
-
-// Accept the next incoming connection from the
server socket
try {
+// Allocate a new worker thread
+Worker workerThread = getWorkerThread();
+// Accept the next incoming connection from
the server socket
long socket = Socket.accept(serverSock);
// Hand this socket off to an appropriate
processor
if (setSocketOptions(socket)) {
-
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: svn commit: r386148 - in /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes: group/ tcp/ tcp/bio/ tcp/nio/
Hey Filip,
I thing you must also sync the first get statement :-)
public static SenderState getSenderState(Member member) {
+SenderState state = (SenderState)memberStates.get(member);
+if ( state == null ) {
+synchronized ( memberStates ) {
+state = (SenderState)memberStates.get(member);
+
The internal hashmap state can be corrupted when other thread add or
remove elements inside the first get call!
Peter
Am 15.03.2006 um 20:32 schrieb [EMAIL PROTECTED]:
public static SenderState getSenderState(Member member) {
+SenderState state = (SenderState)memberStates.get(member);
+if ( state == null ) {
+synchronized ( memberStates ) {
+state = (SenderState)memberStates.get(member);
+
Re: [VOTE][RESULT] Tomcat v5.5.16 Stability
I also can't find apr static link command for MAC OS X. At MAC OS X the tcnative library´suffix must be jnilib instead dylib. How I can change this? peter Am 16.03.2006 um 15:15 schrieb Henri Gomez: 2006/3/16, Mladen Turk <[EMAIL PROTECTED]>: Henri Gomez wrote: We could comment how to build an APR 1.2.2 ready for static inclusion (easy). But the configure/makefile of tcnative should be adapted You have the commit rights, so what's the problem :) One problems : - How to get the correct link command from apr-config when APR want to be used statically. I've got it for Linux but what about AIX / HPUX / Solaris. Send questions on apr-dev but still not response. - 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: http://issues.apache.org/bugzilla/show_bug.cgi?id=38984
The current os.c patch works well at mac os x. and currently the IS_UNIX flag is enough. But my research for more mac os x system info is hard. Help is needed... Thanks peter Am 17.03.2006 um 11:10 schrieb Mladen Turk: Jim Jagielski wrote: I'm thinking... the behavior we want is that non-Windows OSs want the APR_SO_REUSEADDR before the bind; Windows wants it after. So checking for (OS.IS_UNIX) at one point (for the former) and then (OS.IS_WIN32 || OS.IS_WIN64) (for the later) is misleading, and doesn't match what we do elsewhere. So why not make the former test !(OS.IS_WIN32 || OS.IS_WIN64) instead? This should also fix the MacOS bug as well. Now that flags are correctly initialized, there is no need for that. MacOS will be reported as 'IS_UNIX'. Of course we can add IS_MACOS once when Peter finishes MacOS system info, but it will still be reported as IS_UNIX beside IS_MACOS, just like IS_LINUX or IS_SOLARIS. We can change the later test for (OS.IS_WIN32 || OS.IS_WIN64) to !OS.IS_UNIX but it wouldn't change anything functional. 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 [STATUS]
+1 for that, I can made my tests at weekend. Regards Peter Am 17.03.2006 um 12:37 schrieb Mladen Turk: Hi all, There is quite large list of fixed bugs for mod_jk from the 1.2.15: #37469: Fix shared memory close for forked childs. #37332: Fix potential misuse of buffer length with snprintf. #38859: Protect mod_jk against buggy or malicious AJP servers. #38889: Use worker map sorting depending on the path elements. #36138: Added Busyness lb method. #none: Fix loadbalancer for burst load. #38806: Reclycle worker even if it is disabled. #37167: Allow building with BSD-ish like make. #none: Fix ISAPI plugin log. Is this worth tagging and releasing 1.2.16? 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 [STATUS]
Hey Malden, I have found one compile error: /bin/sh /Users/peter/server/apache2.0.55w/build/libtool --silent -- mode=compile gcc -I/Users/peter/server/apache2.0.55w/include -g -O2 - g -O2 -DHAVE_APR -I/Users/peter/develop/apache/httpd-2.0.55/srclib/ apr/include -I/Users/peter/develop/apache/httpd-2.0.55/srclib/apr- util/include -g -O2 -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp- precomp -I /System/Library/Frameworks/JavaVM.framework/Versions/1.5/ Home/include -I /System/Library/Frameworks/JavaVM.framework/Versions/ 1.5/Home/include/ -c jk_shm.c -o jk_shm.lo jk_shm.c: In function 'jk_shm_close': jk_shm.c:367: error: request for member 'attached' in something not a structure or union jk_shm.c:369: error: request for member 'attached' in something not a structure or union make[1]: *** [jk_shm.lo] Error 1 make: *** [all-recursive] Error 1 Can be that we must use jk_shmem.attached instead jk_shmem.hdr.attached ? other thing is that gcc 4.0.1 report this warning /JavaVM.framework/Versions/1.5/Home/include/ -c jk_ajp12_worker.c -o jk_ajp12_worker.lo /bin/sh /Users/peter/server/apache2.0.55w/build/libtool --silent -- mode=compile gcc -I/Users/peter/server/apache2.0.55w/include -g -O2 - g -O2 -DHAVE_APR -I/Users/peter/develop/apache/httpd-2.0.55/srclib/ apr/include -I/Users/peter/develop/apache/httpd-2.0.55/srclib/apr- util/include -g -O2 -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp- precomp -I /System/Library/Frameworks/JavaVM.framework/Versions/1.5/ Home/include -I /System/Library/Frameworks/JavaVM.framework/Versions/ 1.5/Home/include/ -c jk_connect.c -o jk_connect.lo jk_connect.c: In function 'nb_connect': jk_connect.c:198: warning: pointer targets in passing argument 5 of 'getsockopt' differ in signedness Can I set rclen to unsigned ? L181 jk_connect.c unsigned int rclen = sizeof(rc); regards Peter Am 17.03.2006 um 12:37 schrieb Mladen Turk: Hi all, There is quite large list of fixed bugs for mod_jk from the 1.2.15: #37469: Fix shared memory close for forked childs. #37332: Fix potential misuse of buffer length with snprintf. #38859: Protect mod_jk against buggy or malicious AJP servers. #38889: Use worker map sorting depending on the path elements. #36138: Added Busyness lb method. #none: Fix loadbalancer for burst load. #38806: Reclycle worker even if it is disabled. #37167: Allow building with BSD-ish like make. #none: Fix ISAPI plugin log. Is this worth tagging and releasing 1.2.16? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r386629 - /tomcat/connectors/trunk/jk/native/common/jk_connect.c
Hi, I wait for second MacBook generation and then Cool design, and a very hot computer... Some people have make last days the first Windows XP up and running and Suse linux works nicely... ;-) Peter Am 17.03.2006 um 13:43 schrieb Mladen Turk: [EMAIL PROTECTED] wrote: Fix gcc 4.0.1 compiler warning at mac os x! Man, your are really serious with macosx. Now, since it runs on Intel, I should try one for myself :) Cheers, 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 [STATUS]
+1 Can you please create a windows binaries? I start testing at weekend and I hope Rainer can also do testing at solaris. Thanks peter Am 17.03.2006 um 14:27 schrieb Mladen Turk: Remy Maucherat wrote: +1, but make sure you test it (I see lots of last minute fixes). Well, I hope I won't be the only one doing testing. I'll create a private .tar.gz so everyone interested (beside myself) could build and test it, before official vote and release. This is for those lazy to use the SVN :) 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]
Missing support from busy worker at jk_lb_worker.find_best_bydomain
Hi,
Find that method find_best_bydomain not suppoprt the new busy lb
strategy!
---
L252 jk_lb_worker.c
/* Take into calculation only the workers that are
* not in error state, stopped or not disabled.
*/
if (JK_WORKER_USABLE(p->lb_workers[i].s)) {
if (p->lbmethod == JK_LB_BYREQUESTS) {
p->lb_workers[i].s->lb_value += p->lb_workers[i].s-
>lb_factor;
total_factor += p->lb_workers[i].s->lb_factor;
if (!candidate || p->lb_workers[i].s->lb_value >
candidate->s->lb_value)
candidate = &p->lb_workers[i];
}
else {
mytraffic = (p->lb_workers[i].s->transferred +
p->lb_workers[i].s->readed ) / p-
>lb_workers[i].s->lb_factor;
if (!candidate || mytraffic < curmin) {
candidate = &p->lb_workers[i];
curmin = mytraffic;
}
}
}
=
Can we use this at line
L:351
mytraffic = (p->lb_workers[i].s->transferred +
p->lb_workers[i].s->readed ) / p-
>lb_workers[i].s->lb_factor;
instead
mytraffic = (p->lb_workers[i].s->transferred/p->lb_workers
[i].s->lb_factor) +
(p->lb_workers[i].s->readed/p->lb_workers
[i].s->lb_factor);
Better we extract the small redundant value calculations at separate
functions!
Regards Peter
Re: svn commit: r388500 - /tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java
Cool catch => Use simple data structure, with fine performance
impact. :-)
Peter
Am 24.03.2006 um 13:37 schrieb [EMAIL PROTECTED]:
Author: remm
Date: Fri Mar 24 04:37:27 2006
New Revision: 388500
URL: http://svn.apache.org/viewcvs?rev=388500&view=rev
Log:
- As suggested by Peter, replace the (synced) Stack with a
specialized unsynced stack.
Modified:
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/
AprEndpoint.java
Modified: tomcat/connectors/trunk/util/java/org/apache/tomcat/util/
net/AprEndpoint.java
URL: http://svn.apache.org/viewcvs/tomcat/connectors/trunk/util/
java/org/apache/tomcat/util/net/AprEndpoint.java?
rev=388500&r1=388499&r2=388500&view=diff
==
--- tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/
AprEndpoint.java (original)
+++ tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/
AprEndpoint.java Fri Mar 24 04:37:27 2006
@@ -19,7 +19,6 @@
import java.net.InetAddress;
import java.util.ArrayList;
import java.util.HashMap;
-import java.util.Stack;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
@@ -109,10 +108,9 @@
/**
- * Available processors.
+ * Available workers.
*/
-// FIXME: Stack is synced, which makes it a non optimal choice
-protected Stack workers = new Stack();
+protected WorkerStack workers = null;
/**
@@ -510,7 +508,7 @@
if (initialized)
return;
-
+
// Create the root APR memory pool
rootPool = Pool.create(0);
// Create the pool for the server socket
@@ -625,6 +623,9 @@
running = true;
paused = false;
+// Create worker collection
+workers = new WorkerStack(maxThreads);
+
// Start acceptor thread
acceptorThread = new Thread(new Acceptor(), getName()
+ "-Acceptor");
acceptorThread.setPriority(threadPriority);
@@ -808,7 +809,7 @@
synchronized (workers) {
if (workers.size() > 0) {
curThreadsBusy++;
-return ((Worker) workers.pop());
+return (workers.pop());
}
if ((maxThreads > 0) && (curThreads < maxThreads)) {
curThreadsBusy++;
@@ -1516,5 +1517,60 @@
public boolean process(long socket);
}
+
+// -
WorkerStack Inner Class
+
+
+public class WorkerStack {
+
+protected Worker[] workers = null;
+protected int end = 0;
+
+public WorkerStack(int size) {
+workers = new Worker[size];
+}
+
+/**
+ * Put the object into the queue.
+ *
+ * @param object the object to be appended to the
queue (first element).
+ */
+public void push(Worker worker) {
+workers[end++] = worker;
+}
+
+/**
+ * Get the first object out of the queue. Return null if
the queue
+ * is empty.
+ */
+public Worker pop() {
+if (end > 0) {
+return workers[--end];
+}
+return null;
+}
+
+/**
+ * Get the first object out of the queue, Return null if
the queue
+ * is empty.
+ */
+public Worker peek() {
+return workers[end];
+}
+
+/**
+ * Is the queue empty?
+ */
+public boolean isEmpty() {
+return (end == 0);
+}
+
+/**
+ * How many elements are there in this queue?
+ */
+public int size() {
+return (end);
+}
+}
}
-
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: Challenges for Java hosting
Hey, Java/JSP and Tomcat for german hoster is a very bad story. For two year we start a tomcat 5.0 based spezial tomcat distibution for hosting. The Centaurus Platform has show that effectiv hosting is possible. Problem is to find hoster that use that package. Look at http://centaurus.sourceforge.net/ and see that we have create a very cool tomcat bundle. Centaurus features: Used a patched tomcat 5.0.27 full graphical and console installer package for LINUX/Windows You can have multiple installation profiles Very nice html admin/manager console for one instance Loading new Security Policy on demand without downtime every webapp can register there own policy part (admin can control this integration with rules) Integrate new host from templates without downtime Native Iintegration at os services with Java Service Wrapper Plugin concept for people to extends tomcat core functionality use of Mx4J Http adaptor with authorisation for remote control. At cvs head exist a not final tomcat 5.5 version. Regards Peter - Documentation only exist in german language. Am 06.04.2006 um 23:48 schrieb Leon Rosenberg: On 4/6/06, Preston L. Bannister <[EMAIL PROTECTED]> wrote: Define "lightweight". :) only the basics you need for a webapp. no admin/manager, no clustering, no gadgets. To explain it: Besides large portals with own server farms and millions of hits, I often have small customers which get a dynamical website with some cms etc. The problem I had and still have, is that typical hosting providers (at least in germany) don't offer any support for java webapps, best you can get is support for jsps only which sucks. This is ugly, since the customer pays money for the webapp and asks me afterwards, why should he rent a complete server to host it. Therefore I started to rent servers myself, and re-rent it to the customer. The customer gets the complete package, mail, backup, ftp/ssh access and the webapp. To ensure this, each server has an apache running with two jsp container instances on it, one for production, one for testing versions. The customer pays less than he would pay for "professional" hosting, and I can refinance the server with 3-4 customers. However, having all test-webapps in one server, and needing to restart it from time to time isn't really cool. I'd prefer to give each customer two instances, which consumes low resources, maybe even multiple tomcat instances in one jvm (is that possible?), and keep them independent from each other. Therefore lightweight. And therefore pre-configured :-) regards Leon If we are talking about a small number of users, with high average utilization, this might be a good solution. In fact this is similar in resource usage to the virtual hosting (i.e. Xen) solutions. For more typical usage, the number of users is large, and the average utilization is low. In this case one (very rarely used) JVM per user is somewhat expensive. Note you could reduce the expense with the same approach of using a fork() of a single image, expecting copy-on-write to radically reduce the real memory use (virtual memory use would be larger). Depends on what target you are trying to hit. The hosting world (by numbers of users) is dominated by very low usage sites. Is this a goal for Java/Tomcat hosting? If you can beat PHP in CGI mode *both* in performance and in resource usage, then you have a pretty compelling solution. If you are fatter or slower - this is going to disinterest a lot of hosting providers. Note that this notion is pretty much a non-starter if Linux does not do copy-on-write with fork(). This was a big deal back in the late 1980's (big Lisp apps forking "vi"). Don't know if this made it's way into Linux. I'm pretty sure copy-on-write in fork() was in SunOS, but I don't know about Solaris. On 4/6/06, Leon Rosenberg <[EMAIL PROTECTED]> wrote: isn't it easier to give each user a pre-configured lightweight but own tomcat? leon On 4/6/06, Preston L. Bannister <[EMAIL PROTECTED]> wrote: Well, that is one definition of "real applications". There are other definitions. :) On 4/6/06, Tino Schwarze <[EMAIL PROTECTED]> wrote: On Thu, Apr 06, 2006 at 09:15:17AM -0700, Preston L. Bannister wrote: You have to consider how (or if) to allow for long-running background threads. Successive requests for the same user will not use the JVM (whether this counts as an advantage or disadvantage is debatable). The JVM isn't going to be optimizing code. The point of using an application server (instead of e.g. PHP) is that it maintains state on the server. You lose this by using fork (). So it's not going to work at all for real applications since your application "returns" to it's previous state after every request. Bye, Tino. -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTE
Re: Challenges for Java hosting
Hey Henri, no problem. I have talk with Thorsten Kamann the other author and we are happy to contribute the code. Then we can translate the complete docs and finish the tomcat 5.5 integration. Regards Peter & Thorsten Am 07.04.2006 um 13:16 schrieb Henri Gomez: Very interesting stuff My german is too bad but from what I could see it seems a good candidate. Could this works be ported back into ASF Tomcat 5.5.x ? Or better included in ASF Tomcat ? 2006/4/7, Peter Rossbach <[EMAIL PROTECTED]>: Hey, Java/JSP and Tomcat for german hoster is a very bad story. For two year we start a tomcat 5.0 based spezial tomcat distibution for hosting. The Centaurus Platform has show that effectiv hosting is possible. Problem is to find hoster that use that package. Look at http://centaurus.sourceforge.net/ and see that we have create a very cool tomcat bundle. Centaurus features: Used a patched tomcat 5.0.27 full graphical and console installer package for LINUX/Windows You can have multiple installation profiles Very nice html admin/manager console for one instance Loading new Security Policy on demand without downtime every webapp can register there own policy part (admin can control this integration with rules) Integrate new host from templates without downtime Native Iintegration at os services with Java Service Wrapper Plugin concept for people to extends tomcat core functionality use of Mx4J Http adaptor with authorisation for remote control. At cvs head exist a not final tomcat 5.5 version. Regards Peter - Documentation only exist in german language. Am 06.04.2006 um 23:48 schrieb Leon Rosenberg: On 4/6/06, Preston L. Bannister <[EMAIL PROTECTED]> wrote: Define "lightweight". :) only the basics you need for a webapp. no admin/manager, no clustering, no gadgets. To explain it: Besides large portals with own server farms and millions of hits, I often have small customers which get a dynamical website with some cms etc. The problem I had and still have, is that typical hosting providers (at least in germany) don't offer any support for java webapps, best you can get is support for jsps only which sucks. This is ugly, since the customer pays money for the webapp and asks me afterwards, why should he rent a complete server to host it. Therefore I started to rent servers myself, and re-rent it to the customer. The customer gets the complete package, mail, backup, ftp/ssh access and the webapp. To ensure this, each server has an apache running with two jsp container instances on it, one for production, one for testing versions. The customer pays less than he would pay for "professional" hosting, and I can refinance the server with 3-4 customers. However, having all test-webapps in one server, and needing to restart it from time to time isn't really cool. I'd prefer to give each customer two instances, which consumes low resources, maybe even multiple tomcat instances in one jvm (is that possible?), and keep them independent from each other. Therefore lightweight. And therefore pre-configured :-) regards Leon If we are talking about a small number of users, with high average utilization, this might be a good solution. In fact this is similar in resource usage to the virtual hosting (i.e. Xen) solutions. For more typical usage, the number of users is large, and the average utilization is low. In this case one (very rarely used) JVM per user is somewhat expensive. Note you could reduce the expense with the same approach of using a fork() of a single image, expecting copy-on-write to radically reduce the real memory use (virtual memory use would be larger). Depends on what target you are trying to hit. The hosting world (by numbers of users) is dominated by very low usage sites. Is this a goal for Java/Tomcat hosting? If you can beat PHP in CGI mode *both* in performance and in resource usage, then you have a pretty compelling solution. If you are fatter or slower - this is going to disinterest a lot of hosting providers. Note that this notion is pretty much a non-starter if Linux does not do copy-on-write with fork(). This was a big deal back in the late 1980's (big Lisp apps forking "vi"). Don't know if this made it's way into Linux. I'm pretty sure copy-on-write in fork() was in SunOS, but I don't know about Solaris. On 4/6/06, Leon Rosenberg <[EMAIL PROTECTED]> wrote: isn't it easier to give each user a pre-configured lightweight but own tomcat? leon On 4/6/06, Preston L. Bannister <[EMAIL PROTECTED]> wrote: Well, that is one definition of "real applications". There are other definitions. :) On 4/6/06, Tino Schwarze <[EMAIL PROTECTED]> wrote: On Thu, Apr 06, 2006 at 09:15:17AM -0700, Preston L. Bannister wrote: You have to consider how (or if) to allow for long-running background threads. Succes
APR Sendfile Support with MAC OS X not yet implemented
Hi, I have test the sendfile apr connector feature with MAC OS X 10.4.5, Java 1.5, APR 1.2.2, Tomcat svn head, Every time as sendfile is use the AprEndpoint.add(SendfileData data) Socket.sendfilen() L1417 returned code 70023 APR_ENOTIMPL Not yet implemented?! Any hint, have APR 1.2.6 a MAC OS X sendfile support? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: APR Sendfile Support with MAC OS X not yet implemented
Arrg, you are right! It seems that MAC OS X have no sendfile support. I have search, but I can't find sys/sendfile.h I don't understand why Library.APR_HAS_SENDFILE not set correctly :-( apr.h is correct generate without sendfile support #define APR_HAS_SENDFILE 0 Regards Peter Am 08.04.2006 um 11:23 schrieb Mladen Turk: Peter Rossbach wrote: Hi, I have test the sendfile apr connector feature with MAC OS X 10.4.5, Java 1.5, APR 1.2.2, Tomcat svn head, Every time as sendfile is use the AprEndpoint.add(SendfileData data) Socket.sendfilen() L1417 returned code 70023 APR_ENOTIMPL Not yet implemented?! Looks like APR_HAS_SENDFILE is missing. Try to compile the APR with --with-sendfile=yes OTOH it might be that MAC simply does not support sendfile on the OS level (hard to believe, but ...) Any hint, have APR 1.2.6 a MAC OS X sendfile support? Look at the generated apr.h It should have #define APR_HAS_SENDFILE 1 Tcnative is using this flag, and if not present it returns 'not implemented (inside APR)' error. 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: APR Sendfile Support with MAC OS X not yet implemented
Ups, now I find the root of my strange problem...
Peter Rossbach wrote:
Arrg,
you are right! It seems that MAC OS X have no sendfile support. I
have search, but I can't find sys/sendfile.h
I don't understand why Library.APR_HAS_SENDFILE not set correctly :-(
apr.h is correct generate without sendfile support #define
APR_HAS_SENDFILE 0
So, everything is fine then ;)
Is Tomcat reporting errors. Is should detect if the
sendfile is supported or not via
Library.APR_HAS_SENDFILE field.
In case this is false, the normal methods will be
used.
Look at Library.initialize L 176
APR_HAVE_IPV6 = has(0);
APR_HAS_SHARED_MEMORY = has(1);
APR_HAS_THREADS = has(2);
APR_HAS_SENDFILE= has(3);
Start with zero, but jnilib.c starts with one?!
L 294
CN_IMPLEMENT_CALL(jboolean, Library, has)(TCN_STDARGS, jint what)
{
jboolean rv = JNI_FALSE;
UNREFERENCED_STDARGS;
switch (what) {
case 1:
#if APR_HAVE_IPV6
rv = JNI_TRUE;
#endif
break;
case 2:
#if APR_HAS_SHARED_MEMORY
rv = JNI_TRUE;
#endif
break;
case 3:
#if APR_HAS_THREADS
rv = JNI_TRUE;
#endif
break;
case 4:
#if APR_HAS_SENDFILE
rv = JNI_TRUE;
#endif
I think that isn't correct or every one at the middle decrement the
has() value! Can I change the Library.java ?
Of course the other solution is to install
the Windows on MAC ;)
OK, at the VM's from Parallels or vmware coming up final, this was a
really an option, but then also Liunx works fine ... :-)
Today, I learn the first really bad missing MAC OS X feature.
Peter
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: APR Sendfile Support with MAC OS X not yet implemented
OK, but then all user need a new tcnative releas. I thing the correction at Library.java is the better option, but I am not sure! Peter Am 08.04.2006 um 14:25 schrieb Mladen Turk: Peter Rossbach wrote: Ups, now I find the root of my strange problem... I think that isn't correct or every one at the middle decrement the has() value! Can I change the Library.java ? Sorry... Fix the jnilib.c instead Library.java -- 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]
Found two compiler warnings at MAC OS X at tcnative/apr
I got these two warnings:
/bin/sh /Users/peter/tools/local//build-1/libtool --silent --
mode=compile gcc -g -O2 -DHAVE_CONFIG_H -DDARWIN -
DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -g -O2 -
DHAVE_OPENSSL -I/Users/peter/tomcat/develop/tomcat55/connectors/jni/
native/include -I/System/Library/Frameworks/JavaVM.framework/Versions/
1.5/Home/include -I/System/Library/Frameworks/JavaVM.framework/
Versions/1.5/Home/include/ -I/Users/peter/tools/local/include -I/
Users/peter/tools/local//include/apr-1 -o src/os.lo -c src/os.c &&
touch src/os.lo
src/os.c: In function 'Java_org_apache_tomcat_jni_OS_threadCurrent':
src/os.c:49: warning: cast from pointer to integer of different size
/bin/sh /Users/peter/tools/local//build-1/libtool --silent --
mode=compile gcc -g -O2 -DHAVE_CONFIG_H -DDARWIN -
DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -g -O2 -
DHAVE_OPENSSL -I/Users/peter/tomcat/develop/tomcat55/connectors/jni/
native/include -I/System/Library/Frameworks/JavaVM.framework/Versions/
1.5/Home/include -I/System/Library/Frameworks/JavaVM.framework/
Versions/1.5/Home/include/ -I/Users/peter/tools/local/include -I/
Users/peter/tools/local//include/apr-1 -o src/ssl.lo -c src/ssl.c
&& touch src/ssl.lo
src/ssl.c: In function 'ssl_thread_id':
src/ssl.c:203: warning: cast from pointer to integer of different size
Source code
os.c
TCN_IMPLEMENT_CALL(jlong, OS, threadCurrent)(TCN_STDARGS)
{
UNREFERENCED_STDARGS;
return (jlong)apr_os_thread_current();
}
ssl.c
static unsigned long ssl_thread_id(void)
...
return (unsigned long)((jlong)apr_os_thread_current());
...
Found at after a long typedef search /usr/include/sys/_types.h
struct _opaque_pthread_attr_t { long __sig; char __opaque
[__PTHREAD_ATTR_SIZE__]; };
But I not clear what is the right cast or we need a spezial darwin
handling?
Regards
Peter
Re: "Critical poller failure" when using tcnative
Can you send me a simple testcase, then I can check it. Cheers Peter Am 10.04.2006 um 23:14 schrieb Jean-frederic Clere: Remy Maucherat wrote: Mladen Turk wrote: Right. I was hoping to have the native release by the end of the week also. Since installer depends on outside natives, the native should be out before the 5.5.17. That's a good idea. There are some small issues with some compile warnings for MacOSX, but nothing critical. Jean-Frédéric said it was a cast problem. If sizeof(apr_os_thread_t) == sizeof(unsigned long) then no problem, if not there is a problem. I don't have access to a MacOSX machine for the moment so I can't check it. Cheers Jean-Frédéric 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: "Critical poller failure" when using tcnative
+1, good time to build a next release, some off my customers see the pooler message :-) Peter Am 10.04.2006 um 16:17 schrieb Yoav Shapira: Hola, I just looked at the changelog, and the EINTR status code fix was post 5.5.16 (it will be included in 5.5.17), so at least things are fairly logical :) So you would need to either patch 5.5.16, or use tcnative HEAD. Thanks Rémy & Mladen, that worked. I'm ready to do a 5.5.17 later this week, if the other committers think this is a decent time. 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: Changing failover session's jvmRoute if cookies are disabled
Hi, Brian,
I think you are right! It exist no reason why we only change the
session id at cookie session id case!
Hmm, I thing my test env and customer app are cookie based :-( Then
I later not made it ready to support also request session ids.
I find a easy fix to getting it work. The enhancement include at
tomat 5.5.17 release.
Many thanks to reporting it,
Peter
Am 27.03.2006 um 22:07 schrieb Brian Stansberry:
Hi,
I noticed that in o.a.c.cluster.session.JvmRouteBinderValve there is a
block of code
that basically prevents changing a session's jvmRoute if URL
rewriting is used:
if (request.isRequestedSessionIdFromURL
()) {
if (log.isDebugEnabled())
log.debug(sm.getString("jvmRoute.skipURLSessionIDs"));
} else {
handleJvmRoute( request, response,session.getIdInternal(),
jvmRoute);
}
This basically means that if cookies are disabled and a session
fails over, the
jvmRoute portion of the session id won't be changed. AIUI, if this
isn't changed,
thereafter mod_jk will not pin the session to any server. That's a
pretty big
limitation to distributed sessions.
In JBoss clustering we have a similar valve that has pretty much the
same limitation.
Does anyone know any reason for this limitation? If cookies are
disabled, we
of course shouldn't emit a cookie, but why not change the id of the
session object?
Looking at how Response.encodeURL works, it uses the session object's
id when encoding,
so if we change this field, any subsequently emitted URLs should have
the proper id
with the new jvmRoute. This valve is invoked before the request enters
the webapp, so
the id change will take place before the webapp writes any URLs.
Thanks!
Brian Stansberry
Lead, AS Clustering
JBoss, Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r394113 - in /tomcat/container/tc5.5.x: modules/storeconfig/src/share/org/apache/catalina/storeconfig/StandardContextSF.java modules/storeconfig/src/share/org/apache/catalina/storeconf
Hi Yoav,
that is not the complete story. I start analyse the fix, and find
more things
I hope I can fix it next hour.
Cheers
Peter
Am 14.04.2006 um 16:58 schrieb [EMAIL PROTECTED]:
Author: yoavs
Date: Fri Apr 14 07:58:10 2006
New Revision: 394113
URL: http://svn.apache.org/viewcvs?rev=394113&view=rev
Log:
Bugzilla 37781: http://issues.apache.org/bugzilla/show_bug.cgi?
id=37781
Modified:
tomcat/container/tc5.5.x/modules/storeconfig/src/share/org/
apache/catalina/storeconfig/StandardContextSF.java
tomcat/container/tc5.5.x/modules/storeconfig/src/share/org/
apache/catalina/storeconfig/StoreConfig.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml
Modified: tomcat/container/tc5.5.x/modules/storeconfig/src/share/
org/apache/catalina/storeconfig/StandardContextSF.java
URL: http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/
storeconfig/src/share/org/apache/catalina/storeconfig/
StandardContextSF.java?rev=394113&r1=394112&r2=394113&view=diff
==
--- tomcat/container/tc5.5.x/modules/storeconfig/src/share/org/
apache/catalina/storeconfig/StandardContextSF.java (original)
+++ tomcat/container/tc5.5.x/modules/storeconfig/src/share/org/
apache/catalina/storeconfig/StandardContextSF.java Fri Apr 14
07:58:10 2006
@@ -1,5 +1,5 @@
/*
- * Copyright 2004-2005 The Apache Software Foundation.
+ * Copyright 2004-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -150,6 +150,18 @@
log.info("Store Context " + aContext.getPath()
+ " separate with backup (at file "
+ mover.getConfigSave() + " )");
+
+// Bugzilla 37781 Check to make sure we can write this
output file
+if ((mover.getConfigSave() == null) ||
+(! mover.getConfigSave().isFile()) ||
+(! mover.getConfigSave().canWrite())) {
+log.error("Cannot write context output file at "
++ mover.getConfigSave() + ", not
saving.");
+throw new IOException("Context save file at "
+ + mover.getConfigSave()
+ + " is null, not a file, or
not writable.");
+}
+
PrintWriter writer = mover.getWriter();
try {
storeXMLHead(writer);
Modified: tomcat/container/tc5.5.x/modules/storeconfig/src/share/
org/apache/catalina/storeconfig/StoreConfig.java
URL: http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/
storeconfig/src/share/org/apache/catalina/storeconfig/
StoreConfig.java?rev=394113&r1=394112&r2=394113&view=diff
==
--- tomcat/container/tc5.5.x/modules/storeconfig/src/share/org/
apache/catalina/storeconfig/StoreConfig.java (original)
+++ tomcat/container/tc5.5.x/modules/storeconfig/src/share/org/
apache/catalina/storeconfig/StoreConfig.java Fri Apr 14 07:58:10 2006
@@ -1,5 +1,5 @@
/*
- * Copyright 2004-2005 The Apache Software Foundation.
+ * Copyright 2004-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/
docs/changelog.xml?rev=394113&r1=394112&r2=394113&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Fri Apr 14
07:58:10 2006
@@ -147,6 +147,9 @@
38508: Several enhancements to Host Manager
application, including configurable
manager app support and dialog box enhancements. Thanks
to George Sexton for the patch. (yoavs)
+
+37781: Make sure context config file is
writeable, suggested by George Sexton. (yoavs)
+
-
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: svn commit: r394113 - in /tomcat/container/tc5.5.x: modules/storeconfig/src/share/org/apache/catalina/storeconfig/StandardContextSF.java modules/storeconfig/src/share/org/apache/catalina/storeconf
Hi Yoav,
the proposed StoreConfig patch is wrong, but I find a fix. After
some testing I see a very strange behaviour.
I test with a referenced war file.
and see at jconsole that docBase is set to "some" and not to the
correct war path.
After I store the context the docBase is remove. That correct
behaviour from StoreConfig for local directory deployment $
{catalina.base}/webapps/some.
But why we remove orginal docBase? How can find the orginal docBase
that I configured???
Need help from Remy
Peter
PS: I check in current stage, better work as before, but the fix is
not finished.
Am 14.04.2006 um 18:54 schrieb Yoav Shapira:
It seems like a safe check to do and a valid bug use-case, but you
know the relevant code better than I, so please check it, and if you
think it's bad for some reason feel free to revert the commit, reopen
the bug issue, and explain your thoughts...
Yoav
On 4/14/06, Peter Rossbach <[EMAIL PROTECTED]> wrote:
Hi Yoav,
that is not the complete story. I start analyse the fix, and find
more things
I hope I can fix it next hour.
Cheers
Peter
Am 14.04.2006 um 16:58 schrieb [EMAIL PROTECTED]:
Author: yoavs
Date: Fri Apr 14 07:58:10 2006
New Revision: 394113
URL: http://svn.apache.org/viewcvs?rev=394113&view=rev
Log:
Bugzilla 37781: http://issues.apache.org/bugzilla/show_bug.cgi?
id=37781
Modified:
tomcat/container/tc5.5.x/modules/storeconfig/src/share/org/
apache/catalina/storeconfig/StandardContextSF.java
tomcat/container/tc5.5.x/modules/storeconfig/src/share/org/
apache/catalina/storeconfig/StoreConfig.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml
Modified: tomcat/container/tc5.5.x/modules/storeconfig/src/share/
org/apache/catalina/storeconfig/StandardContextSF.java
URL: http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/
storeconfig/src/share/org/apache/catalina/storeconfig/
StandardContextSF.java?rev=394113&r1=394112&r2=394113&view=diff
==
--- tomcat/container/tc5.5.x/modules/storeconfig/src/share/org/
apache/catalina/storeconfig/StandardContextSF.java (original)
+++ tomcat/container/tc5.5.x/modules/storeconfig/src/share/org/
apache/catalina/storeconfig/StandardContextSF.java Fri Apr 14
07:58:10 2006
@@ -1,5 +1,5 @@
/*
- * Copyright 2004-2005 The Apache Software Foundation.
+ * Copyright 2004-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -150,6 +150,18 @@
log.info("Store Context " + aContext.getPath()
+ " separate with backup (at file "
+ mover.getConfigSave() + " )");
+
+// Bugzilla 37781 Check to make sure we can write this
output file
+if ((mover.getConfigSave() == null) ||
+(! mover.getConfigSave().isFile()) ||
+(! mover.getConfigSave().canWrite())) {
+log.error("Cannot write context output file at "
++ mover.getConfigSave() + ", not
saving.");
+throw new IOException("Context save file at "
+ + mover.getConfigSave()
+ + " is null, not a file, or
not writable.");
+}
+
PrintWriter writer = mover.getWriter();
try {
storeXMLHead(writer);
Modified: tomcat/container/tc5.5.x/modules/storeconfig/src/share/
org/apache/catalina/storeconfig/StoreConfig.java
URL: http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/
storeconfig/src/share/org/apache/catalina/storeconfig/
StoreConfig.java?rev=394113&r1=394112&r2=394113&view=diff
==
--- tomcat/container/tc5.5.x/modules/storeconfig/src/share/org/
apache/catalina/storeconfig/StoreConfig.java (original)
+++ tomcat/container/tc5.5.x/modules/storeconfig/src/share/org/
apache/catalina/storeconfig/StoreConfig.java Fri Apr 14 07:58:10
2006
@@ -1,5 +1,5 @@
/*
- * Copyright 2004-2005 The Apache Software Foundation.
+ * Copyright 2004-2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/
docs/changelog.xml?rev=394113&r1=394112&r2=394113&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Fri Apr 14
07:58:
Re: svn commit: r394113 - in /tomcat/container/tc5.5.x: modules/storeconfig/src/share/org/apache/catalina/storeconfig/StandardContextSF.java modules/storeconfig/src/share/org/apache/catalina/storeconf
OK!
Can you explain, why we set Context.docBase to MyApps as conf/
Catalina/localhost/MyApps.xml deployed with following contents
How I can find at runtime the real docBase path?
Regards
Peter
Am 14.04.2006 um 19:59 schrieb Remy Maucherat:
Peter Rossbach wrote:
Hi Yoav,
the proposed StoreConfig patch is wrong, but I find a fix. After
some testing I see a very strange behaviour.
I test with a referenced war file.
and see at jconsole that docBase is set to "some" and not to the
correct war path.
After I store the context the docBase is remove. That correct
behaviour from StoreConfig for local directory deployment $
{catalina.base}/webapps/some.
But why we remove orginal docBase? How can find the orginal
docBase that I configured???
Need help from Remy
Peter
PS: I check in current stage, better work as before, but the fix
is not finished.
Don't CC me, I can read emails just fine. The basic rule is that
the docBase is ignored if inside the hosts's appBase (because in
that case the deployer wants to use the path).
About tcnative 1.1.3, it's there as usual: http://www.apache.org/
dist/tomcat/tomcat-connectors/native/
The d/l is from the archive, so not synced yet.
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: svn commit: r394113 - in /tomcat/container/tc5.5.x: modules/storeconfig/src/share/org/apache/catalina/storeconfig/StandardContextSF.java modules/storeconfig/src/share/org/apache/catalina/storeconf
Hmm,
but why we not store the original docBase at Context ? StoreConfig
need it to store the correct path at conf/Catalina/localhost/
MyApps.xml after a change?
Peter
Am 14.04.2006 um 22:23 schrieb Bill Barker:
-Original Message-
From: Peter Rossbach [mailto:[EMAIL PROTECTED]
Sent: Friday, April 14, 2006 12:12 PM
To: Tomcat Developers List
Subject: Re: svn commit: r394113 - in
/tomcat/container/tc5.5.x:
modules/storeconfig/src/share/org/apache/catalina/storeconfig/
StandardContextSF.java
modules/storeconfig/src/share/org/apache/catalina/storeconfig/
StoreConfig.java webapps/docs/changelog.xml
OK!
Can you explain, why we set Context.docBase to MyApps as conf/
Catalina/localhost/MyApps.xml deployed with following contents
Because if unpackWARs="true", the war is exploded into the MyApps
directory,
and Tomcat then considers that to be the docBase.
How I can find at runtime the real docBase path?
The Deployer knows about it, but it isn't telling :).
Otherwise, you'd have to re-parse MyApps.xml. It is long gone from
the
Context.
Regards
Peter
Am 14.04.2006 um 19:59 schrieb Remy Maucherat:
Peter Rossbach wrote:
Hi Yoav,
the proposed StoreConfig patch is wrong, but I find a fix. After
some testing I see a very strange behaviour.
I test with a referenced war file.
and see at jconsole that docBase is set to "some" and not to the
correct war path.
After I store the context the docBase is remove. That correct
behaviour from StoreConfig for local directory deployment $
{catalina.base}/webapps/some.
But why we remove orginal docBase? How can find the orginal
docBase that I configured???
Need help from Remy
Peter
PS: I check in current stage, better work as before, but the fix
is not finished.
Don't CC me, I can read emails just fine. The basic rule is that
the docBase is ignored if inside the hosts's appBase (because in
that case the deployer wants to use the path).
About tcnative 1.1.3, it's there as usual: http://www.apache.org/
dist/tomcat/tomcat-connectors/native/
The d/l is from the archive, so not synced yet.
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]
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r395980 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/session/ManagerBase.java webapps/docs/changelog.xml
Hi Remy,
look at the stats update at StandardSession/DeltaSession exipre(boolean)
StandardSession L 713.
synchronized (manager) {
if (timeAlive > manager.getSessionMaxAliveTime()) {
manager.setSessionMaxAliveTime(timeAlive);
}
int numExpired = manager.getExpiredSessions();
numExpired++;
manager.setExpiredSessions(numExpired);
int average = manager.getSessionAverageAliveTime();
average = ((average * (numExpired-1)) + timeAlive)/
numExpired;
manager.setSessionAverageAliveTime(average);
}
expire(boolean,boolean)
DeltaSession L749
I plan to start refactoring that DeltaManager/DeltaSession at current
cluster and new ha cluster are real subclasses :-)
Cheers
Peter
Am 21.04.2006 um 22:11 schrieb Remy Maucherat:
[EMAIL PROTECTED] wrote:
Author: pero
Date: Fri Apr 21 11:29:21 2006
New Revision: 395980
URL: http://svn.apache.org/viewcvs?rev=395980&view=rev
Log:
ManagerBase increment expireSessions counter at background task
two times
Where is the other place where this field is incremented ?
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: svn commit: r395980 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/session/ManagerBase.java webapps/docs/changelog.xml
Why not? I don't want change the complete cluster module. My goal is that we get a better ManagerBase/StandardManager/ StandardSession base. I want remove the complete redundant code smell at DeltaManager/DeltaSession. We have a lot of stress last year with this code duplication. After the refactoring finished I hope the integration for all subclasses are become eaisier. Peter Am 22.04.2006 um 19:24 schrieb Filip Hanik - Dev Lists: Peter Rossbach wrote: I plan to start refactoring that DeltaManager/DeltaSession at current cluster and new ha cluster are real subclasses :-) that would be a -1, as we are not refactoring the current impl, that was the reason for the new modules to begin with. You were the one who suggested it :) in the HA module, this is work in progress 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]
Vote for Refactoring ManagerBase/DeltaManager
Yes, thing a real refactoring must start at ManagerBase. Then we get a better interface for easier subclassing Manager like DeltaManager at existing cluster and ha modules and other implementation like JBoss. I thing we have now some options: a) Refactoring at tomcat 5.5 later port to 6.0 b) Refactoring at tomcat 6.0 later backport to 5.5 c) no refactoring I vote for a) +1 Peter See dev mailing Thread Re: svn commit: r395980 - in /tomcat/container/tc5.5.x: catalina/src/ share/org/apache/catalina/session/ManagerBase.java webapps/docs/ changelog.xml Am 24.04.2006 um 17:22 schrieb Filip Hanik - Dev Lists: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: there is no need to create a branch as we have a replacement module modules/ha with the exact same code base, that was created so that refactoring could be done on clustering code. This new module is the obvious choice for refactoring, and if successful, we can vote to backport or not to the stable module. You use the "refactoring" designation quite conveniently. Your refactoring is not a refactoring, it is a rewrite. Since it replaces an existing component, it has no chance of being backported (as in: "replacing the existing component"). You can make it so that it can optionally be used by Tomcat 5.5.x users if you'd like, but that's about it. As you are fully aware, what Peter is talking about is a comparatively very small refactoring and extend the regular session implementation. This is also something you had agreed (and failed) to do a long time ago - since the initial implementation of the component, in fact. Peter doesn't think so, this is his quote: "Yes! As you look at the code duplication, a change at DeltaManager/ DeltaSession goes hand in hand with major changes at ManagerBase/ StandardManager/StandardSession. A lot of method must be spilt. I think it is a refactoring to base and all manager subclasses." Rémy ok, I'm done now :) 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: Vote for Refactoring ManagerBase/DeltaManager
OK, I have no real problem to made my changes at 6.0 base first, but it is really stable? I see that Connector change currently and this can be a problem. Quick integration tests with connector that are new is not funny. What are the next developing steps at 6.0? It is the right time to change the manager and session base classes. Proposed changes: - Remove all direct method/code duplications at the DeltaManager/ DeltaSession subclasses - analyse, at example the listener methods with a lot of code duplications. - extract some helper methodes at base classes for eaisier subclassing. - factor out the DeltaManager sender and receiver methods. - DeltaManager and DeltaSession at cluster and ha modules are very similar and porting is currently no problem. I also plan to wrote some junit testcase. I don't want change any functionality and refactor at small steps. Peter Am 24.04.2006 um 18:24 schrieb Rainer Jung: Peter Rossbach wrote: Yes, thing a real refactoring must start at ManagerBase. Then we get a better interface for easier subclassing Manager like DeltaManager at existing cluster and ha modules and other implementation like JBoss. I thing we have now some options: a) Refactoring at tomcat 5.5 later port to 6.0 b) Refactoring at tomcat 6.0 later backport to 5.5 c) no refactoring I vote for a) +1 Peter For me the right choice would depend on the size and risk of the refactoring. 5.5 is assumed to be pretty stable now. So I would have a tendency to vote for b) unless I get a better idea about how small and well-understood the changes would be. Peter: since you think a) is the way to go: could you point out, what the amount of changes would be? Thanks! Rainer - 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 v5.5.17 Stability
Am 24.04.2006 um 20:15 schrieb Yoav Shapira: Hey dudes and dudettes, Our test candidate v5.5.17-beta has been available for a little more than a week now. I hope you've had time to test it. If so, please vote on its stability below. If you haven't had time to test it, this vote will run for about 3 days, so you can get some testing in quickly ;) Apache Tomcat v5.5.17 is: [x ] Stable - no major issues +1 Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vote for Refactoring ManagerBase/DeltaManager
Hi Filip, Am 24.04.2006 um 20:19 schrieb Filip Hanik - Dev Lists: Peter Rossbach wrote: OK, I have no real problem to made my changes at 6.0 base first, but it is really stable? I see that Connector change currently and this can be a problem. Quick integration tests with connector that are new is not funny. What are the next developing steps at 6.0? It is the right time to change the manager and session base classes. Proposed changes: - Remove all direct method/code duplications at the DeltaManager/ DeltaSession subclasses - analyse, at example the listener methods with a lot of code duplications. - extract some helper methodes at base classes for eaisier subclassing. - factor out the DeltaManager sender and receiver methods. - DeltaManager and DeltaSession at cluster and ha modules are very similar and porting is currently no problem. yes, and this is the beauty of it, cause you can gut the modules/ha implementation, do all your refactoring there without hurting the stable branch or its bug fixing progress. ManagerBase and Manager should not require too much, maybe changing some private to protected, and I think that's what Remy means by "small" changes. But DeltaSession and DeltaManager will actually be "large" changes. OK, I have no problem to start refactoring at ha module at 5.5 head. 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: Memory usage Tomcat 3.3 vs 5.5
Hi Henri, I have tomorrow a talk with Thorsten. Steps: Made a tomcat 5.5 port english doc After these steps we can contribute it easier to ASF and more people can test it :-) Peter Am 26.04.2006 um 09:13 schrieb Henri Gomez: Well the extra memory could be a penalty, but what I like to see in future Tomcat impl, will be support for many instances ready to massive hosting. There was a thread about this some weeks ago, with a nice piece of code from Germany, wonder what we could do to use it or include it in Tomcat main ? 2006/4/26, Jess Holle <[EMAIL PROTECTED]>: Hmm... Sharing redundant MBeanInfo's shouldn't be that hard to wedge in. Unfortunately, I don't know when I'll have time to take a proper look at this... -- Jess Holle Remy Maucherat wrote: Costin Manolache wrote: Not sure what is the plan for commons-modeler, I think it is worth to bring it back to tomcat or fork a separate implementation Modeler is now in the tomcat.util package in the new repository, so you can try to improve it if you'd like to. One first change I made is that it uses the digester to read the descriptors (rather than DOM). 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: Why is IBM still using Tomcat 5.0?
:-) Great that also my experience. Yep, now 5.5.17 is out and I hope we got more people to migrate. Cheers Peter Am 27.04.2006 um 22:58 schrieb Filip Hanik - Dev Lists: most folks I know are still using 5.0 (and 4.1), both have been stable much longer than 5.5, most companies think better safe than sorry, no need to be bleeding edge at all times historically, the companies I have worked with have not picked up tomcat on a pre .16 release, that has seemed to be the magic number Filip Yoav Shapira wrote: Hola, Do we have anyone from IBM here who can tell us what's stopping them from using Tomcat 5.5, as opposed to 5.0, for new tools like their Web Ontology Manager that was announced earlier today? (http://www.alphaworks.ibm.com/tech/wom/requirements? open&S_TACT=105AGX59&S_CMP=GR) You can clearly see they're up to date on details, like the site name having changed from jakarta.apache.org/tomcat to tomcat.apache.org, by looking at their installation instructions... Weird. -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The purpose of provided tomcat-users.xml
Yes, defaults are very fine, but secret parameter need active user interaction. also -1 Peter Am 28.04.2006 um 11:54 schrieb Remy Maucherat: Mladen Turk wrote: Hi, The provided tomcat-users.xml is obviously used as an example. Can we tweak that so that it actually allows the admin and manager users? Sorry, but it's a bad idea. The purpose would be the same (example), but it will allow to run the provided web apps without additional editing. And most people wouldn't be changing them, creating a security problem. Any objections if I put the 'real' values there? -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: The purpose of provided tomcat-users.xml
Example are good, but people comment it out at there production server. Kismet... This problem is documented at tomcat docs main page! I hope every "user" can read and paste it to there installation :-) OK, I have no problem with a comment line. Peter Am 28.04.2006 um 12:07 schrieb Mladen Turk: Peter Rossbach wrote: Yes, defaults are very fine, but secret parameter need active user interaction. I didn't say it will be enabled by default. If commented out like in tc6, it would need an user intervention anyhow, so the user uncommenting the credentials should be aware of the consequences. 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: Core webapps and clustering
I think we can merge both cluster and storeconfig modules to new tc 6. For current user it is easier. Only change is that new ha cluster module are packaged as seperate jar (name change a build.xml) and we must change the bootstrap logic at config parsing. I think user better switch cluster implementation with system.properties as autodetect a class. Then testing current and new cluster module are a lot easier. After merge I can start session manager refactoring and later I made a tc 5.5 backport. Regards Peter Am 04.05.2006 um 17:12 schrieb Remy Maucherat: Hi, I was wondering if I should merge the code for the core manager webapp in the main source tree, or if I should keep them in the webapps subfolders. There is one dependency for the manager webapp on commons-fileupload 1.0 (so if the code for the webapp is merged in the main source tree, commons-fileupload will get the package renaming treatment). Similarly, the clustering module (the new ones, most likely) as well as the storeconfig should most likely be merged in the main source tree. 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: Core webapps and clustering
Hey Costin,
look at o.a.c.starter.ClusterRuleSetFactory
> Snip
//OLD CLUSTER 1
//first try the same classloader as this class server/lib
try {
return loadRuleSet
(prefix,"org.apache.catalina.cluster.ClusterRuleSet",ClusterRuleSetFacto
ry.class.getClassLoader());
} catch ( Exception x ) {
//display warning
if ( log.isDebugEnabled() ) log.debug("Unable to load
ClusterRuleSet (org.apache.catalina.cluster.ClusterRuleSet), falling
back on context classloader");
}
//try to load it from the context class loader
try {
return loadRuleSet
(prefix,"org.apache.catalina.cluster.ClusterRuleSet",Thread.currentThrea
d().getContextClassLoader());
} catch ( Exception x ) {
//display warning
if ( log.isDebugEnabled() ) log.debug("Unable to load
ClusterRuleSet (org.apache.catalina.cluster.ClusterRuleSet), will try
to load the HA cluster");
}
//NEW CLUSTER 2
//first try the same classloader as this class server/lib
try {
return loadRuleSet
(prefix,"org.apache.catalina.ha.ClusterRuleSet",ClusterRuleSetFactory.cl
ass.getClassLoader());
< Snap -
and ha currently build same jar name as the current cluster module.
Current and new cluster has not the same configuration dialect. :-)
My idea is, that we set instead a system.properties at
catalina.properties like:
digester.cluster.ruleset.classname=org.apache.catalina.cluster.ClusterRu
leSet
digester.cluster.ruleset.classname=org.apache.catalina.ha.ClusterRuleSet
Then we can integrate new ha at normal build and user can easliy
switch implementation.
What you thing about this idea Filip and Costin?
Peter
Am 04.05.2006 um 20:23 schrieb Costin Manolache:
On 5/4/06, Peter Rossbach <[EMAIL PROTECTED]> wrote:
I think we can merge both cluster and storeconfig modules to new tc
6. For current user it is easier.
Only change is that new ha cluster module are packaged as seperate
jar (name change a build.xml) and we must change the bootstrap logic
at config parsing. I think user better switch cluster implementation
with system.properties as autodetect a class. Then testing
current and new cluster module are a lot easier.
Could you explain a bit ?
My understanding is that ha is an optional feature, that users can
turn on - i.e.
sort of a separate module, with no dependency between tomcat and ha.
For modules - I assumed that each of them is a JMX component, that can
be configured using only JMX calls. I.e. no system.properties or
other change
to bootstrap logic.
If this is not the case - why and can we fix it ?
Re: moving the code to the src/ tree - I'm not very sure. I think it
was a clear benefit to
have all core tomcat components in the same tree - i.e. connectors,
jasper, catalina.
+1
But I think it would also be good to have a separate 'modules' and
'webapps' area, and
keep them separate, at least for things that are not required for a
basic tomcat. Or at least for things that have external deps, or are
big.
+1
Costin
After merge I can start session manager refactoring and later I made
a tc 5.5 backport.
Regards
Peter
Am 04.05.2006 um 17:12 schrieb Remy Maucherat:
> Hi,
>
> I was wondering if I should merge the code for the core manager
> webapp in the main source tree, or if I should keep them in the
> webapps subfolders. There is one dependency for the manager webapp
> on commons-fileupload 1.0 (so if the code for the webapp is merged
> in the main source tree, commons-fileupload will get the package
> renaming treatment).
>
> Similarly, the clustering module (the new ones, most likely) as
> well as the storeconfig should most likely be merged in the main
> source tree.
>
> 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: Core webapps and clustering
Hi, Am 05.05.2006 um 05:34 schrieb Filip Hanik - Dev Lists: I'd thought I'd chip in my 2 cents, 1. I don't think we should keep maintaining two clustering modules in TC6, the old one has too many limitations, I would leave it as a module since its stable, but I don't have any plans of trying to beat the dead horse and try to make it do something it wasn't built to do. +1 Currently we can copy the old one to TC6 to help people start testing. The new cluster module is pretty cool and after it was complete, we deprecate the good old horse :-) You change every day a lot. Duplicate those changes are a nightmare and do much work. Better we test the new cluster together and after the first development is finished, we can copy and maintain it. The new "ha" module, which is far from complete is trying to address most of these limitations, but also extend to features like context attribute replication, probably a second attempt at farming, delta versioning and many other features. Cool! After my conference week I hope start real testing. 2. I would integrate the new "ha" module into the main tree as Remy suggested, easier to catch when it breaks, and session,context and other data management is something that is pretty intimate with Tomcat's code base +1, to intergrate the build at tc 5.5. 3. I was gonna make the "comm" layer, default to tribes but be pluggable, if someone prefers to use something else, like Appia, Spread, jgroups etc. To avoid more server.xml clutter, I was simply thinking of binding the comm layer into the JNDI tree as a regular resource so that resources simply can look it up and take advantage of it. That way, when tomcat is embedded, that container would probably want to share this comm resource, and they are able to through JNDI. I thing JMX is the better option! 4. JMX, yes, hit it on the nail, the re is nothing pluggable about tomcat's JMX right now, For example, MBeanUtils.createObjectName(String,Connector), if the connector does not contain the string "CoyoteConnector" it simply throws a MalformedObjectNameException So this area would need to be revisited in large before it would be something like Rickard Oberg created for JBoss that made it so pluggable through JMX and MBeans, geronimo has something similar through their GBeans/XBeans. Both are good platforms, but you thing we can use it directly? On a personal note, I think JMX should do monitoring and I think injection can be done in many more ways. but that is a philosophical point. Yes! Yes, I think we need a better JMX core that are independent form implementation. Like a Tomcat JMX API and people can easier switch implementation and make real dynamic remote management possible I do see the benefit of adding the new cluster module "ha" to the main tree, and I would support that effort. I would keep the old "cluster" module as a module, eventually sunsetting it. I would keep "groupcom" as a module as this is not really a core tomcat feature, but providing the context/session management is. Let us add it for eaisier testing. +1 have a great Friday folks! Thanks and also have nice day... Peter Filip Yoav Shapira wrote: Hola, Since you asked for opinions, personally I'm: - In favor of having one clustering implementation, but I think everyone is, no whoop there - Would prefer that clustering, like admin, stay a little module that's easily added to the core (and in general would like to keep the core as small as possible) - Agnostic on JMX versus server.xml (can see equal justification for both) A lot of this is just style preference. As long as we have a working clustering module, I'm sure it will be fairly easy to have a distro with it and a distro without it. That's why I haven't chimed in much on this, I don't have a strong preference either way. Yoav On 5/4/06, Costin Manolache <[EMAIL PROTECTED]> wrote: On 5/4/06, Remy Maucherat <[EMAIL PROTECTED]> wrote: > Costin Manolache wrote: > > It's not about using a mini-jboss architecture, but about a more > > consistent and simpler > > configuration. > > > > IMO JMX should be used for configuration when possible, instead of > > adding more weird > > syntax to server.xml. > > I tried it quite hard at some point (it's the embedded distribution), > and it didn't work out that well. It's actually more complex. > > The first task is to optimize modeler (you'll do it, right ?), and then > maybe to use modeler exclusively in Tomcat (avoiding all direct JMX > dependencies). I'm actually trying to optimize it and finally implement the 'persist changes', but it'll take some time, I get less than 1h per day to work on open source. I would say jboss style config is not _that_ more complex, and even 3.3 style config was acceptable for many modules ( well, people might not agree with that, bit at least it was simple enough ). >
Re: Core webapps and clustering
Am 05.05.2006 um 14:13 schrieb Henri Gomez: Well being modular, components oriented won't be bad. It's not about cloning Geronimo, but allowing tomcat to get more and more modules and extensions, like does Apache HTTPD Good topic, small core with a lot of nice features... Tomcat as a plugin container. Sounds good to me! Smaller core with robust implementation are more straightforward embeddable. But how you think we can change tomcat at this direction? What are the timeline? 2006/5/5, Remy Maucherat <[EMAIL PROTECTED]>: Henri Gomez wrote: > May be not related, but did there is plan in TC 6.x to make use at > some time OSGI framework, like the one used in Eclipse and RCP > applications ? > > I really like this concept and it seems a good candidate to provide a > modular kernel / micro-architecture. If we do that, what doesn't make it a Geronimo clone ? The services that are shipped by default, maybe ? ;) It also most likely make Tomcat more heavyweight, although I don't know whether or not it would make it more difficult to integrate. 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: Core webapps and clustering
Am 05.05.2006 um 14:38 schrieb Henri Gomez: Well we discuss for Tomcat 6, not Tomcat 5.5 +1, exactly Did there is some deadlines for Tomcat 6 ? No! We have time, but we need a good plan, design and developer team that really implement the stuff. :-) 2006/5/5, Peter Rossbach <[EMAIL PROTECTED]>: Am 05.05.2006 um 14:13 schrieb Henri Gomez: > Well being modular, components oriented won't be bad. > > It's not about cloning Geronimo, but allowing tomcat to get more and > more modules and extensions, like does Apache HTTPD > Good topic, small core with a lot of nice features... Tomcat as a plugin container. Sounds good to me! Smaller core with robust implementation are more straightforward embeddable. But how you think we can change tomcat at this direction? What are the timeline? > 2006/5/5, Remy Maucherat <[EMAIL PROTECTED]>: >> Henri Gomez wrote: >> > May be not related, but did there is plan in TC 6.x to make use at >> > some time OSGI framework, like the one used in Eclipse and RCP >> > applications ? >> > >> > I really like this concept and it seems a good candidate to >> provide a >> > modular kernel / micro-architecture. >> >> If we do that, what doesn't make it a Geronimo clone ? The >> services that >> are shipped by default, maybe ? ;) >> >> It also most likely make Tomcat more heavyweight, although I don't >> know >> whether or not it would make it more difficult to integrate. >> >> 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
