Re: Is ARM64 architecture officially supported ?
Hi Mark, Thank you for the answer! El vie., 17 abr. 2020 a las 15:13, Mark Thomas () escribió: > On 17/04/2020 12:04, Emilio Fernandes wrote: > > Hola Tomcat community! > > > > We consider using AWS Graviton [1] based instances which use ARM64 > > processors for our backend services. > > I've googled around and found [2] saying that Tomcat is being tested on > > ARM64 architecture at TravisCI! This is great! > > Does this mean that Tomcat is officially supported on ARM64 ? I was not > > able to find any specific documentation listing which platforms are > > officially supported. > > Tomcat is supported on any certified Java runtime providing it meets the > minimum Java version requirements for the Tomcat version you are using. > There are no restrictions on hardware or operating system. > > Right, for Java based apps it just depends whether there is a JDK/JRE for the CPU architecture. What about the C based code - tcnative and the connectors (mod_jk) ? > The more exotic the platform and/or operating system, the less likely > the developers will have access to a version for testing so platform > specific issues may be harder to track down. > At the moment ARM64 is still exotic on the server side but since cloud providers (e.g. AWS and Huawei) started promoting it we think it might become more popular in near future. Gracias, Emilio > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Is ARM64 architecture officially supported ?
Hola Tomcat community! We consider using AWS Graviton [1] based instances which use ARM64 processors for our backend services. I've googled around and found [2] saying that Tomcat is being tested on ARM64 architecture at TravisCI! This is great! Does this mean that Tomcat is officially supported on ARM64 ? I was not able to find any specific documentation listing which platforms are officially supported. Does anyone from the community have any experience with Tomcat/HTTPD on ARM64 in production ? Gracias, Emilio 1. https://aws.amazon.com/ec2/graviton/ 2. https://tomcat.apache.org/ci.html#TravisCI
Re: Sticky session and ModJK Load Balancer
Rainer Jung wrote: On 06.07.2009 20:27, Emilio Recio wrote: Mark Thomas wrote: Emilio Recio wrote: Hi, i have installed Apache 2.2 and two Tomcat 6 whit load balancing in cluster mode using mod_jk module and setting sticky session in TRUE, and memory replication. I was testing my project and work perfect. We have a dilemma using sticky session or not using it, with my team work. Setting sticky-session in TRUE, it works fine, even when one tomcat fails-over. When set to FALSE i can see that the session have some data loss, and the project start to fail. I was reading the book Professional Apache Tomcat 6, goggle searches and all kind of information in the net. The recommendation is: use sticky-session in TRUE with memory replication. Nobody mention concrete arguments, and need that to make a report to the system administrator, to make him understand why we need to use sticky-session in TRUE. I would have thought the occasional data loss you see is argument enough. What more were you looking for? Mark Hi Mark, We are developing an e-commerce app. The application store in session a lot of information like user data, user history data, etc. The scenario is: 3 PC's, one with Apache 2.2, and the others have Tomcat 6. Apache has mod_jk to make load balancing, and the Tomcat 6 have configured in memory session replication, to support fail-over. STICKY SESSION FALSE: Some times: Tomcat1 after the login, has all the user info charged in session, when load balancer try to use the Tomcat2 some info is saved but other info is missing. We need to know good arguments to justify to the client, why we should use sticky session in true to avoid this missing data issue. The client doesn't want to use sticky session in TRUE, they arguments are: We loose performance in transactions and loose of loadbalancing (using sticky session in TRUE). Using sticky session in FALSE the Tomcat more idle attend the request that incoming and gain performance. One example: You have 4 users, two in tomcat1 and the other two in tomcat2. If users in tomcat2 logout, this stay idle when the other is attending the other two users. So, you loose load balancing. They arguments are partial true, using stick-session in TRUE , you have one tomcat attending a client session during its life cycle; even if this users are idle or has very active session. Its stable and fail-over tolerant. Of course you loose performance. So we need good arguments to explain why we need use, sticky session in true. My regards, Emilio Recio Usually you only use a custering solution like Tomcat session replication if you really need high availability. Clustering adds some complexity to the system, so in order to justify that you need a reason, which should be, that your user sessions are expensive, so you do not want to loose them under any circumstances. If so, your primary goal is stability not performance. Adding any high availability solution also reduces performance (but maybe only a bit). Why use sticky sessions when doing session replication? Because without sticky sessions, each request depends on the fact, that the replication of the previous request to the same session was completed successfully. So the correctness of your application depends the whole time on the completeness of the session replication (because requests will switch form node to node a lot without stickyness). Whenever something goes wrong with respect to session replication, a user will fail. This seems to be, what you actually oberve when working without stickyness. Your application is *not* replicating completely. Stiky off is a good setting for testing, but not for production. With stickyness, under normal operation you don't rely on the fact, that replication works. Only in case a node goes bad, the sessions fail over and then you need the correctness of the previous replications. Usually this only happens unplanned like maybe once a month or even fewer times. It is also much easier to track what's going on and maybe wrong, when you have stickyness, because then all requests for one session can be usually found in the log files of only one node. You don't have to consolidate them from multiple nodes. Concerning performance: If you only plan 2 Tomcat nodes, then you have to size the in order for one node to be able to carry the full load. Otherwise when a node crashes, although you have session replication, it could happen that the remaining node is not able to cope with the load. So an uneven load distribution between the two nodes is not a real problem, each one should be able to handle all requests. Under high session load (like e.g. more than 1.000 users logged in) usually the request load distributes good enough to not produce a very uneven load. In short: stability is more important then performance in high-availability situations and a two node cluster should be designed such that a single node can carry all the load
Sticky session and ModJK Load Balancer
Hi, i have installed Apache 2.2 and two Tomcat 6 whit load balancing in cluster mode using mod_jk module and setting sticky session in TRUE, and memory replication. I was testing my project and work perfect. We have a dilemma using sticky session or not using it, with my team work. Setting sticky-session in TRUE, it works fine, even when one tomcat fails-over. When set to FALSE i can see that the session have some data loss, and the project start to fail. I was reading the book Professional Apache Tomcat 6, goggle searches and all kind of information in the net. The recommendation is: use sticky-session in TRUE with memory replication. Nobody mention concrete arguments, and need that to make a report to the system administrator, to make him understand why we need to use sticky-session in TRUE. My best regards, Emilio Recio - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Sticky session and ModJK Load Balancer
Mark Thomas wrote: Emilio Recio wrote: Hi, i have installed Apache 2.2 and two Tomcat 6 whit load balancing in cluster mode using mod_jk module and setting sticky session in TRUE, and memory replication. I was testing my project and work perfect. We have a dilemma using sticky session or not using it, with my team work. Setting sticky-session in TRUE, it works fine, even when one tomcat fails-over. When set to FALSE i can see that the session have some data loss, and the project start to fail. I was reading the book Professional Apache Tomcat 6, goggle searches and all kind of information in the net. The recommendation is: use sticky-session in TRUE with memory replication. Nobody mention concrete arguments, and need that to make a report to the system administrator, to make him understand why we need to use sticky-session in TRUE. I would have thought the occasional data loss you see is argument enough. What more were you looking for? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Hi Mark, We are developing an e-commerce app. The application store in session a lot of information like user data, user history data, etc. The scenario is: 3 PC's, one with Apache 2.2, and the others have Tomcat 6. Apache has mod_jk to make load balancing, and the Tomcat 6 have configured in memory session replication, to support fail-over. STICKY SESSION FALSE: Some times: Tomcat1 after the login, has all the user info charged in session, when load balancer try to use the Tomcat2 some info is saved but other info is missing. We need to know good arguments to justify to the client, why we should use sticky session in true to avoid this missing data issue. The client doesn't want to use sticky session in TRUE, they arguments are: We loose performance in transactions and loose of loadbalancing (using sticky session in TRUE). Using sticky session in FALSE the Tomcat more idle attend the request that incoming and gain performance. One example: You have 4 users, two in tomcat1 and the other two in tomcat2. If users in tomcat2 logout, this stay idle when the other is attending the other two users. So, you loose load balancing. They arguments are partial true, using stick-session in TRUE , you have one tomcat attending a client session during its life cycle; even if this users are idle or has very active session. Its stable and fail-over tolerant. Of course you loose performance. So we need good arguments to explain why we need use, sticky session in true. My regards, Emilio Recio - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Session replication without Apache
Manu_SF wrote: Hi, I have a working prototype tomcat cluster with 2 worker nodes connected to Apache webserver as the Loadbalancer with mod_jk connectors. The session replication works like a charm with these 2 nodes. However, my ultimate goal is to deploy it over a system that does NOT have Apache (Instead has a Big-ip hardware loadbalancer). My question is - Is there a way to implement session replication on tomcat nodes without Apache? Thanks, Manu Hi, i suggest you that read Professional Apache Tomcat 6 Author: Vivek Chopra, Sing Li, Jeff Genender (Chapter 11 and 17). They explain a lot of possibles configurations of Tomcat to Load Balancing and Replication Sessions. May by you can search the book in google and read only the chapter. See you - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
two instances of tomcat problem
I just installed the tomcat 5.5 with two instances running in the same ip address, but in different ports. Its works but the manager just work in one of them. The manager for the second port show me the following error: HTTP Status 500 - _ type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Error allocating a servlet instance org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:524) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105 ) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processC onnection(Http11BaseProtocol.java:664) org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav a:527) org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWo rkerThread.java:80) org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:684) java.lang.Thread.run(Thread.java:619) root cause java.lang.NoClassDefFoundError: org/apache/catalina/manager/ManagerServlet java.lang.ClassLoader.defineClass1(Native Method) java.lang.ClassLoader.defineClass(ClassLoader.java:620) java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLo ader.java:1815) org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.jav a:869) org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav a:1322) org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav a:1201) java.security.AccessController.doPrivileged(Native Method) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:524) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105 ) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processC onnection(Http11BaseProtocol.java:664) org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav a:527) org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWo rkerThread.java:80) org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:684) java.lang.Thread.run(Thread.java:619) note The full stack trace of the root cause is available in the Apache Tomcat/5.5 logs. Can I help me with this problem? Thanks in advance Emilio Muno
Tomcat manager - Two instances problem!
I just installed the tomcat 5.5 with two instances running in the same ip address, but in different ports. Its works but the manager just work in one of them. The manager for the second port show me the following error: HTTP Status 500 - _ type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Error allocating a servlet instance org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:524) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105 ) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processC onnection(Http11BaseProtocol.java:664) org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav a:527) org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWo rkerThread.java:80) org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:684) java.lang.Thread.run(Thread.java:619) root cause java.lang.NoClassDefFoundError: org/apache/catalina/manager/ManagerServlet java.lang.ClassLoader.defineClass1(Native Method) java.lang.ClassLoader.defineClass(ClassLoader.java:620) java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLo ader.java:1815) org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.jav a:869) org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav a:1322) org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav a:1201) java.security.AccessController.doPrivileged(Native Method) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:524) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105 ) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processC onnection(Http11BaseProtocol.java:664) org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav a:527) org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWo rkerThread.java:80) org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:684) java.lang.Thread.run(Thread.java:619) note The full stack trace of the root cause is available in the Apache Tomcat/5.5 logs. Can someone help me with this problem? Thanks in advance Emilio Muno
