SSL configuration for Tomcat 9
My system uses embedded Tomcat to connect to a HttpServlet instance. I have just uprgraded from Tomcat 8.0.2 to 9.0.64 I am implementing SSL for the first time. I created a keystore with no alias. Keytool gave it the alias "mykey". (2nd entry below) I imported an issued PEM certificate (4 items in chain) The final item in the chain has the alias "tomcat" as per https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html#Importing_the_Certificate (The same documentation recommends the keystore alias also be 'tomcat' but If the keystore and the issued certificate are both given the same alias (ie 'tomcat'), keytool will import the final entry as "self generated" and throw an error. Here is my abbreviated keystore list using alias 'mykey' for the keystore. keystore listing___ Keystore type: PKCS12 Keystore provider: SUN Your keystore contains 5 entries intermediate, 16/07/2022, trustedCertEntry, Certificate fingerprint (SHA-256): 68:B9:C7:61. intermediate2, 16/07/2022, trustedCertEntry, Certificate fingerprint (SHA-256): 7F:A4:FF:68 mykey, 16/07/2022, PrivateKeyEntry, Certificate fingerprint (SHA-256): 36:F8:64:73:. root, 16/07/2022, trustedCertEntry, Certificate fingerprint (SHA-256): D7:A7:A0:FB.. tomcat, 16/07/2022, trustedCertEntry, Certificate fingerprint (SHA-256): 36:A9:B7:A9:.. Here is my startup code (no server.xml file) Tomcat tomcat = new Tomcat(); tomcat.setPort(PATHS.getPortNumber()); Connector c=tomcat.getConnector(); c.setSecure(true); c.setScheme("https"); c.setProperty("SSLEnabled","true");//crucial bit of code SSLHostConfig ss=new SSLHostConfig(); //ss.setHostName("localhost"); this breaks the init process - leave as "_default_" ss.setCertificateKeyAlias("mykey"); // if set to 'tomcat' init will throw "Alias name [tomcat] does not identify a key entry" ss.setCertificateKeystorePassword("changit"); ss.setCertificateKeystoreFile(PATHS.getHomePath()+"/ks/mykeystor.jks"); ss.setCertificateKeystoreType("PKCS12"); ss.setCertificateKeystoreProvider("SUN") c.addSslHostConfig(ss); org.apache.catalina.Context ctx = tomcat.addContext("", new File(".").getAbsolutePath()); Tomcat.addServlet(ctx, "myApp", new MyApp()); ctx.addServletMappingDecoded("/*", "myApp"); Logr.s("connector scheme "+c.getScheme()); Logr.s("connector SSLEnabled "+c.getProperty("SSLEnabled")); Logr.s("connector redirect "+c.getRedirectPort()); //defaults to 443 Logr.s("connector protocol "+c.getProtocol()); tomcat.start(); tomcat.getServer().await(); When I use "tomcat" as the alias for the keystore I cannot load the final issued certificate without an error. If I use "mykey" as the keystore alias everything seems to be working but the certificate returned to the browser is not the domain-specific certified certificate but a certificate generated with the certificate keystore fingerprint. In a properly operating implementation, what certificate should be returned to the browser? I'm obviously doing something wrong. But what ? -- Vince Stewart
secureRandom... using [SHA1PRNG] ..took (up to) 20 minutes
I started recently using my my java app with embedded Tomcat / 8.0.28 on a debian VPS (DigitalOcean). Unfortunately, it can take up to 20 minutes to launch into action from the time you start execution. The issue relates to "Creation of SecureRandom instance ... using SHA1PRNG". Slowness has been described and explained in Stackoverflow. My tomcat has otherwise been so reliable that I have had no motivation to keep it upgraded. Can anyone advise if some change will apply if I upgrade to the latest version 8. Otherwise, is there a configuration change I could employ. Many thanks, -- Sent from: http://tomcat.10.x6.nabble.com/Tomcat-User-f1968778.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with Clustering / Session Replication
, java.util.logging.**ConsoleHandler, 5cluster.org.apache.juli.**FileHandler # just the new cluster log handler - all others are stock # logging.properties # beware of the wrapping 5cluster.org.apache.juli.**FileHandler.level = FINER 5cluster.org.apache.juli.**FileHandler.directory = ${catalina.base}/logs 5cluster.org.apache.juli.**FileHandler.prefix = cluster. # just the clustering logs - all others are stock logging.properties org.apache.catalina.tribes.**MESSAGES.level = FINE org.apache.catalina.tribes.**MESSAGES.handlers = 5cluster.org.apache.juli.**FileHandler org.apache.catalina.tribes.**level = FINE org.apache.catalina.tribes.**handlers = 5cluster.org.apache.juli.**FileHandler org.apache.catalina.ha.level = FINE org.apache.catalina.ha.**handlers = 5cluster.org.apache.juli.**FileHander org.apache.catalina.ha.deploy.**level = INFO org.apache.catalina.ha.deploy.**handlers = 5cluster.org.apache.juli.**FileHandler Set logging at the desired level. I think I've posted this to the mailing list before . . . /mde/ --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Vince Stewart
Re: Problems with Clustering / Session Replication
alternatively try an explicit address in the Receiver configuration Receiver className=org.apache.catalina.tribes.transport.nio.NioReceiver address=auto port=4001 autoBind=100 selectorTimeout=5000 maxThreads=6/ instead of address=auto try address=192.168.1.43 this should alter the log displayed at start-up and I would be very interested if you still had a problem. On Thu, Sep 19, 2013 at 10:35 AM, Vince Stewart stewart.vi...@gmail.comwrote: Hi Nicholas, I'm am a bit of a novice but I did have a very similar problem when I started using the clustering modules. My Tomcat output was referring to localhost (10.x.x.x) addresses while my netstat was reporting LISTEN on network addresses (192.x.x.x:400?). You have the same disparity. My system operated to expectation after I registered my machine's network IP address in linux folder /etc/hosts. Once I did that tomcat clustering logs started reporting membership with network addresses instead of localhost addresses. On Thu, Sep 19, 2013 at 2:37 AM, Mark Eggers its_toas...@yahoo.comwrote: On 9/18/2013 6:00 AM, Nicholas Violi wrote: Thanks Daniel. On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa dmik...@gopivotal.com wrote: Tried a quick two node setup on my Mac w/out HTTPD and it worked OK. Go to one Tomcat instance's port in chrome, it increments the counter in my app. Refresh a few times. Open a second tab, go to the second Tomcat instance's port. The counter picks up where it left off and continues incrementing. Flipping back and forth between tabs / servers works fine. Here's the cluster config that I used in case it helps. Cluster channelSendOptions=8 className=org.apache.**catalina.ha.tcp.**SimpleTcpCluster Manager className=org.apache.**catalina.ha.session.**DeltaManager expireSessionsOnShutdown=**false notifyListenersOnReplication=**true/ Channel className=org.apache.**catalina.tribes.group.**GroupChannel Membership address=228.0.0.4 className=org.apache.**catalina.tribes.membership.**McastService dropTime=3000 frequency=500 port=45564/ Receiver address=auto autoBind=100 className=org.apache.**catalina.tribes.transport.nio.**NioReceiver maxThreads=6 port=4000 selectorTimeout=5000/ Sender className=org.apache.**catalina.tribes.transport.** ReplicationTransmitter Transport className=org.apache.**catalina.tribes.transport.nio.** PooledParallelSender/ /Sender Interceptor className=org.apache.**catalina.tribes.group.**interceptors.** TcpFailureDetector/ Interceptor className=org.apache.**catalina.tribes.group.**interceptors.** MessageDispatch15Interceptor/** /Channel Valve className=org.apache.**catalina.ha.tcp.**ReplicationValve filter=/ Valve className=org.apache.**catalina.ha.session.**JvmRouteBinderValve/ ClusterListener className=org.apache.**catalina.ha.session.** JvmRouteSessionIDBinderListene**r/ ClusterListener className=org.apache.**catalina.ha.session.**ClusterSessionListener/ /Cluster Just tried this with the same results. My test that replication is behaving is accessing my webapp on the two ports and monitoring the session counter and list in the tomcat manager, and as I said before, I can only see the sessions created on the server attached to the manager instance. Is that a reasonable test? With the clustering config pretty well ruled out as the culprit, maybe my webapp is not dealing with sessions appropriately? Would you mind sending me your counter test app? Beyond that, have you tried increasing the log levels? I found conflicting information about enabling logging. What I had previously was org.apache.catalina.tribes.**level = FINE org.apache.catalina.tribes.**MESSAGES = FINE in logging.properties, which was reporting the FINE log statements in my original post. I just added some more: org.apache.catalina.ha.level = FINE org.apache.catalina.ha.**session.level = FINE org.apache.catalina.ha.**session.DeltaManager.level = FINE org.apache.catalina.ha.tcp.**level = FINE org.apache.catalina.ha.tcp.**level = FINE org.apache.catalina.ha.tcp.**ReplicationValve.level = FINE org.apache.catalina.ha.**session.**ClusterSessionListener.level = FINE org.apache.catalina.ha.**session.**JvmRouteSessionIDBinterListene**r.level = FINE And I still don't see any
Re: buffer expand warning in Tomcat (apache-tomcat-8.0.0-RC1-embed)
Hi Mark, a bit more follow-up on accessing the servlet InputStream: You advised You'd be better off dropping the call to in.ready() and doing a blocking read on the socket.If you remove the call to in.ready(), I'm fairly sure you'll see the warnings disappear. I just thought I'd let you know, that prediction was absolutely correct. On Thu, Aug 29, 2013 at 7:09 AM, Vince Stewart stewart.vi...@gmail.comwrote: Appreciate this a lot Mark. I'm pretty sure my previous code had a short sleep in each loop but thankfully, in-coming data rarely exceeds the Servlet InputBuffer size of 8192 so looping is rare. I have been trying to get to grips with the asynchronous stuff but have not got it going yet. The concept is very appealing. Thanks for your contributions. On Wed, Aug 28, 2013 at 11:00 PM, Mark Thomas ma...@apache.org wrote: On 28/08/2013 09:41, Mark Thomas wrote: On 27/08/2013 03:40, Vince Stewart wrote: hi all, thought I would add some progress on this topic. I have changed my method for reading from the HttpServletRequest object but the same warning message is thrown for every 8192 bytes read. I no longer regard my code to be suspect though am happy to be corrected. The application operates completely normally except for the warning message. The code I am using to read the input is shown below. public void doPost(HttpServletRequest httpServletRequest.etc ...other code.. char[] cbuf=new char[8192]; int i=0; int requestLength=httpServletRequest.getContentLength(); BufferedReader in=httpServletRequest.getReader(); StringBuilder sb=new StringBuilder(requestLength); while(sb.length()requestLength){ if(in.ready()){ i=in.read(cbuf,0,reqLen); } sb.append(cbuf,0,i); } in.close(); String message=sb.toString(); //.etc It looks like there is a possible Tomcat bug but the above code is not the way to read data from the client as it puts the thread into a tight loop while it is waiting for more data to arrive. I've just cleaned up the code for Tomcat 8.0.x to fix the bug that your example highlighted. Thanks for such a clear problem statement that made it very easy to track down the root cause of the issue. The fix will be in 8.0.0-RC2 onwards. That said, my comments about there being a better way to do what you are doing stand. Mark You'd be better off dropping the call to in.ready() and doing a blocking read on the socket. The elapsed time should be the same (might even be a little less) and your CPU consumption during the read when the client is slow sending data will be significantly lower. If you remove the call to in.ready(), I'm fairly sure you'll see the warnings disappear. Ideally, you should look at non-blocking IO as supported by Servlet 3.1 but that might be too big a change as it fundamentally changes how data is read and written. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Vince Stewart -- Vince Stewart
Re: buffer expand warning in Tomcat (apache-tomcat-8.0.0-RC1-embed)
Appreciate this a lot Mark. I'm pretty sure my previous code had a short sleep in each loop but thankfully, in-coming data rarely exceeds the Servlet InputBuffer size of 8192 so looping is rare. I have been trying to get to grips with the asynchronous stuff but have not got it going yet. The concept is very appealing. Thanks for your contributions. On Wed, Aug 28, 2013 at 11:00 PM, Mark Thomas ma...@apache.org wrote: On 28/08/2013 09:41, Mark Thomas wrote: On 27/08/2013 03:40, Vince Stewart wrote: hi all, thought I would add some progress on this topic. I have changed my method for reading from the HttpServletRequest object but the same warning message is thrown for every 8192 bytes read. I no longer regard my code to be suspect though am happy to be corrected. The application operates completely normally except for the warning message. The code I am using to read the input is shown below. public void doPost(HttpServletRequest httpServletRequest.etc ...other code.. char[] cbuf=new char[8192]; int i=0; int requestLength=httpServletRequest.getContentLength(); BufferedReader in=httpServletRequest.getReader(); StringBuilder sb=new StringBuilder(requestLength); while(sb.length()requestLength){ if(in.ready()){ i=in.read(cbuf,0,reqLen); } sb.append(cbuf,0,i); } in.close(); String message=sb.toString(); //.etc It looks like there is a possible Tomcat bug but the above code is not the way to read data from the client as it puts the thread into a tight loop while it is waiting for more data to arrive. I've just cleaned up the code for Tomcat 8.0.x to fix the bug that your example highlighted. Thanks for such a clear problem statement that made it very easy to track down the root cause of the issue. The fix will be in 8.0.0-RC2 onwards. That said, my comments about there being a better way to do what you are doing stand. Mark You'd be better off dropping the call to in.ready() and doing a blocking read on the socket. The elapsed time should be the same (might even be a little less) and your CPU consumption during the read when the client is slow sending data will be significantly lower. If you remove the call to in.ready(), I'm fairly sure you'll see the warnings disappear. Ideally, you should look at non-blocking IO as supported by Servlet 3.1 but that might be too big a change as it fundamentally changes how data is read and written. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Vince Stewart
Re: buffer expand warning in Tomcat (apache-tomcat-8.0.0-RC1-embed)
hi all, thought I would add some progress on this topic. I have changed my method for reading from the HttpServletRequest object but the same warning message is thrown for every 8192 bytes read. I no longer regard my code to be suspect though am happy to be corrected. The application operates completely normally except for the warning message. The code I am using to read the input is shown below. public void doPost(HttpServletRequest httpServletRequest.etc ...other code.. char[] cbuf=new char[8192]; int i=0; int requestLength=httpServletRequest.getContentLength(); BufferedReader in=httpServletRequest.getReader(); StringBuilder sb=new StringBuilder(requestLength); while(sb.length()requestLength){ if(in.ready()){ i=in.read(cbuf,0,reqLen); } sb.append(cbuf,0,i); } in.close(); String message=sb.toString(); //.etc -- View this message in context: http://tomcat.10.x6.nabble.com/buffer-expand-warning-in-Tomcat-apache-tomcat-8-0-0-RC1-embed-tp5003745p5003777.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
buffer expand warning in Tomcat (apache-tomcat-8.0.0-RC1-embed)
greetings all, since commencing with version 8 (embedded) I have encountered no problems except when the HttpServletRequest object receives a message bigger than 16384 k. In that circumstance a warning(below) is repeated X times for messages bigger than 8192+(X*8192). I notice in the InternalNioInputBuffer.expand method, the comment //should not happen precedes the logging of the warning message. I am using a modified BufferedReader class with a buffer size of 8192 and the warning seems to coincide with each read. This same class has operated without a problem for years but I am sure my reader is causing this new problem. So the question is how best to read a large message from the ServletInputStream in tomcat-8 = Aug 26, 2013 10:59:33 AM org.apache.coyote.http11.InternalNioInputBuffer expand WARNING: Expanding buffer size. Old size: 16384, new size: 24576 java.lang.Exception at org.apache.coyote.http11.InternalNioInputBuffer.expand(InternalNioInputBuffer.java:420) at org.apache.coyote.http11.InternalNioInputBuffer.readSocket(InternalNioInputBuffer.java:467) at org.apache.coyote.http11.InternalNioInputBuffer.nbRead(InternalNioInputBuffer.java:187) at org.apache.coyote.http11.InternalNioInputBuffer.available(InternalNioInputBuffer.java:171) at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:818) at org.apache.coyote.Request.action(Request.java:373) at org.apache.catalina.connector.InputBuffer.available(InputBuffer.java:243) at org.apache.catalina.connector.CoyoteInputStream.available(CoyoteInputStream.java:137) at sun.nio.cs.StreamDecoder.inReady(StreamDecoder.java:362) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:323) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) at java.io.InputStreamReader.read(InputStreamReader.java:184) at oodbpds.BigBufferedReader.read1(BigBufferedReader.java:136) at oodbpds.BigBufferedReader.read(BigBufferedReader.java:156) at oodbpds.ASIFTI.doPost(ASIFTI.java:90) at javax.servlet.http.HttpServlet.service(HttpServlet.java:647) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:223) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:107) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:504) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:75) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:90) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:494) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1009) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:632) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1592) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1550) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) -- Vince Stewart
Re: Share info across different sessions servers
tribes (on p4000) has fixed LAN address say 192.168.1.63 //(in Linux you set fixed LAN IP address in the '/etc/hosts' file) //lets say you create a port-forwarding in the router so port 4 redirects to 192.168.1.63 / port 4000 //in such a case the value for remoteHostIPv4Address will be 203.12.32.235 //and remoteHostPort will be 4 //ie {203.12.32.235 , 4} = redirects to = {192.168.1.63 , 4000} //if there is no router (say you have 2 VPS), then no redirect is required //whereupon remoteHostPort will probably be 4000 (as long as that address is free when tribes starts) msgListener = new MyMessageListener(); mbrListener = new MyMemberListener(); myChannel = new GroupChannel(); myChannel.addMembershipListener(mbrListener); myChannel.addChannelListener(msgListener); myChannel.start(Channel.DEFAULT); log(TRIBES HAS STARTED ON PORT: +Integer.toString(getLocalPort())); } void sendMessage(String message,Member member) throws ChannelException{ Member[] group = new Member[]{member}; this.myChannel.send(group,new ByteMessage(message.getBytes(UTF8)),Channel.SEND_OPTIONS_DEFAULT); } String addressesForThisMachine() throws SocketException{ String ss=network addresses for this machine: ; EnumerationInetAddressee; EnumerationNetworkInterfaceei; ei=NetworkInterface.getNetworkInterfaces(); while(ei.hasMoreElements()){ ee=((NetworkInterface)ei.nextElement()).getInetAddresses(); while(ee.hasMoreElements()){ ss=ss+ee.nextElement().getHostAddress()+;; } } return ss; } /* * subserver will run this */ private void engageInDialogue(){ do{ try{ this.sendMessage(* hello superserver *,superServerStaticMember); } catch (ChannelException ex) { TribesRemote.log(ex); } try { Thread.currentThread().sleep(1); } catch (InterruptedException ex) { System.exit(0); } if(System.currentTimeMillis()-lastMessageTime()12000){ log(no messages in last 12 seconds); } }while(true); } /* * superserver will run this */ private void waitForMessages(){ do{ try{ Thread.currentThread().sleep(1); } catch (InterruptedException ex) { System.exit(0); } }while(true); } int getLocalPort() { return this.myChannel.getLocalMember(true).getPort(); } private void engage(){ if(this.amSuperServer){ this.waitForMessages(); } else{ this.engageInDialogue(); } } private long lastMessageTime() { return this.lastMessageReceived; } void messageReceived(String message, Member sender) throws ChannelException { this.lastMessageReceived=System.currentTimeMillis(); if(this.amSuperServer){ this.sendMessage(message + ((hello back )),sender); } } private static class MyMessageListener implements ChannelListener{ @Override public void messageReceived(Serializable s,Member sender){ byte[] b=((ByteMessage)s).getMessage(); String message=new String(b,TribesRemote.UTF8); TribesRemote.log(message received: +message); try{ TribesRemote.tribesRemote.messageReceived(message,sender); } catch (ChannelException ex) { TribesRemote.log(ex); } } @Override public boolean accept(Serializable msg, Member sender) { return true; } } //this is part of clustering that has not been removed from tribes private static class MyMemberListener implements MembershipListener{ @Override public void memberAdded(Member member){ //TribesRemote.tribesRemote.memberDetected(member); } @Override public void memberDisappeared(Member member){ //TribesRemote.tribesRemote.memberGone(member); } } } On Thu, Jul 4, 2013 at 6:57 PM, Jose María Zaragoza demablo...@gmail.comwrote: Thanks Vince. I'll take a look , but , it doesn't look trivial , not at all Regards 2013/7/4 Vince Stewart stewart.vi...@gmail.com Hi Jose, a couple of things, 1) I use embedded Tomcat to build my application and this has allowed me to maintain 2 single-line patches in tribes classes by adding tribes source code to my compilations. However those patches are only necessary with large messages that take more than 3 seconds to be transmitted from the transmitting machine to the Internet Service Provider machine (approx 0.5 meg for my system). There is a config setting (Sender/Transport/timeout) that's supposed to alter this 3 second timeout limit but I'm not sure it works. 2) The implementation is not at all trivial. You have to register StaticMember objects because usual member discovery does not work over wide-area network (WAN). I allocate one machine as SuperServer and all other machines have to enroll with SuperServer at startup. All machines need to have a unique combination of Ipv4 address and port number (which might represent a redirection port for use by the router whereupon networked machines also need LAN addresses set). Once registration
Re: Share info across different sessions servers
Hi Jose, a couple of things, 1) I use embedded Tomcat to build my application and this has allowed me to maintain 2 single-line patches in tribes classes by adding tribes source code to my compilations. However those patches are only necessary with large messages that take more than 3 seconds to be transmitted from the transmitting machine to the Internet Service Provider machine (approx 0.5 meg for my system). There is a config setting (Sender/Transport/timeout) that's supposed to alter this 3 second timeout limit but I'm not sure it works. 2) The implementation is not at all trivial. You have to register StaticMember objects because usual member discovery does not work over wide-area network (WAN). I allocate one machine as SuperServer and all other machines have to enroll with SuperServer at startup. All machines need to have a unique combination of Ipv4 address and port number (which might represent a redirection port for use by the router whereupon networked machines also need LAN addresses set). Once registration is complete, all sub-Server machines can send/receive SuperServer and vice versa. There is a tutorial on-line which is adequate but not for WAN. I think you have at least two weeks of work in front of you using tribes but I am very happy I used this method. None of my code would add much (except confusion) to that in the tutorial. Make sure you start without multicast enabled as it currently is suitable only for LAN. ///Class Constructor public ServerMessaging() throws SocketException{ this.myChannel=new GroupChannel(); ChannelListener msgListener = new ServerMessaging.MyMessageListener(); MembershipListener mbrListener = new ServerMessaging.MyMemberListener(); myChannel.addMembershipListener(mbrListener); myChannel.addChannelListener(msgListener); try{ myChannel.start(Channel.MBR_TX_SEQ|Channel.MBR_RX_SEQ|Channel.SND_TX_SEQ|Channel.SND_RX_SEQ);//no multicast } catch(ChannelException e){ U.log(e); } } public void detectOrderNumber_EnrollWithSuperServer() throws ChannelException{ setMyServerOrderStatus(); // machine reads its mac address or some file; then from a table will set serverOrderNumber to 0 for superserver ; others 1,2,3... if(this.getServerOrderNumber()==0){ meaning this is the superserver someObject.doSomeThingMaybe(); } else{ this.sendAckRequiredMessage(0,Enrollment); /// first argument specifies SuperServer, member 0 (a table will need to be provided to hold IPv4 address and port for each member) } }
Re: Share info across different sessions servers
I have am using tribes messaging to send messages between remote applications which include tomcat embedded. You construct your message and submit to a sendMessage process. All running apps are always listening for messages. They receive the message and then may or may not reply or broadcast as a result. On Wed, Jul 3, 2013 at 7:43 AM, Jose María Zaragoza demablo...@gmail.comwrote: Thanks Christopher : Maybe I explained myself badly I really need to send messages to a specific web session , not share data I need to pass some data ( message ) to a specific session from a remote system ( a remote process from a remote system). Finally, this data is passed to client's browser by AJAX Reverse My idea is the session creates a dynamic Queue and it configures itself as Consumer If I pass the Queue to remote process ( in message.replyTo() ) , the remote process can send data to that specific session I could use a RDBS but , in this case, session needs to create a thread to polling on a share table. And I don't like this idea, sorry. memcached sounds good but I don't know anything about it and I don't know is is based on a event-driven architecture I need 1) send data/message from a remote process to a specific web session 2) execute some code in this session 3) consume ( a.k.a, delete ) that message Persistence is not a requirement but ActiveMQ allows it I'l try it with ActiveMQ Thanks again and regards 2013/7/2 Christopher Schultz ch...@christopherschultz.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jose, On 7/2/13 3:22 AM, Jose María Zaragoza wrote: Thanks I need to share formatted text data ( XML, key/value, ...I'm not sure yet ) I don't understand your comment about JMS . I will use a JMS broker as ActiveMQ . Probably it will be embebbed into the same JVM than Tomcat server. ActiveMQ supports persistent messages While JMS may work, it's really not the right solution. JMS is a messaging service, and you want a data-storage service. I could use a database but I don't want to be making polling every X seconds by a session You don't have to pull any data that the user doesn't need, do you? If you don't want to use a RDBMS, how about something like memcached? I asked about using memcached a while back on this list and got some other suggestions as well (as memcached doesn't make a great fail-safe shared-data storage system... it's really meant to be more of a cache of data available elsewhere). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR0ycOAAoJEBzwKT+lPKRYaAsP+wfhqoLQWwJoYLpur0Z5VOeJ GUmylaW+kllpcbdFdVG81691rjUW1Ph5yQ2MQzPFKv0bCp2cyHMWQuJgAp1rq/Lo T6Bpba6IHeyucxEAk0XZfGu4efS+wc39ncq9C3GPamEvrN+locYGtM/lqSpkSxKz 5ADXD9o2//U5Nk00N0KHPH4xsp/wtx0NJgT1p9f1VUKgU9pVvGFhHvrozvdAEcnv 9U7IQroNO7uR3RnKL/rq9CH3MsxL/gbWCWEZ21WkaguLFysc67naaSQvimIoLok9 eUfCK6Z5Bll4VeefK6YlA6E49sj01NZD1zuj0J/DGUiwBuFiNSZc1Z2NOZlue7Oo efpaRkjINouIfyk3RONa8/ZuNWf80ImX5vvJKEYK7ujc2LB7G8+ID95Toeej0eyg cZWHZo3N67nYgker4Kp4xn4VXBs4QfDzY/uOfsUyp8voNcCz6lBo38w8T3jvVJzV ci18cbWdRXQ3NrlaBkI8qJeEzMWAegM7C1IqJUspmlDHvsUIiamGA+ZF6nBNPr16 w3lx8X8xWjGM63OQaoYMbTc2ZXFCkP0zkXXEcx49zyGMSEDSk2NySw2HkAOh9iVx tr7YCDChtFg8mBQPY6CiiasEtn8j9JMK/XawdDI34LTsO1molB5OvJDGo558BqMm 3hK/JZGxPkEPapvOfWRM =tOMh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Vince Stewart
Re: BackupManager start fails under heavy load
Hi Patrick, A similar problem has been reported before: http://tomcat.10.n6.nabble.com/org-apache-catalina-tribes-ChannelException-Operation-has-timed-out-3000-ms-Faulty-members-tcp-64-88-td4656393.html The important error message from your log output is: Caused by: org.apache.catalina.tribes.ChannelException: Operation has timed out(3000 ms.).; Faulty members:tcp://{10, 230, 20, 86}:4001; tcp://{10, 230, 20, 87}:4001; tcp://{10, 230, 20, 94}:4001; tcp://{10, 230, 20, 95}:4001; tcp://{10, 230, 20, 70}:4001; tcp://{10, 230, 20, 89}:4001; at org.apache.catalina.tribes.transport.nio.ParallelNioSender.sendMessage(Paral lelNioSender.java:109) ... I am familiar with the code that generates this message; the problem is that the sending operation is abandoned for any sender object which has not been drained of data within timeout milliseconds. The timeout parameter is declared in AbstractSender class as (long) 3000. By my reckoning a small change to the timeout value could result a large reduction in messaging failures. According to information from this page: http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-sender.html you should be able to increase the timeout parameter by setting a transport attribute thus: Sender className=org.apache.catalina.tribes.transport.ReplicationTransmitter Transport className=org.apache.catalina.tribes.transport.nio.PooledParallelSender timeout=4000 /Transport /Sender However, I can not find the code where the system reads the configuration to override the default value; if you make the alteration and find the error message still reports 3000ms, this would indicate an oversight in the coding which could be reported. BTW, your configuration for receiver has selectorTimeout=100 The code suggests that this should be the same value as sender/transport timeout (ie 3000). The documentation says the default is 5000. My examination of the code suggests that the PooledParallelSender class does not read the configuration but always uses 5000. Nevertheless, you could try setting that value to 5000 and seeing what happens. BTW my own interest was to implement tribes at Internet connection speed; by manipulating the parameter in question, my system copes with data transfers that take multiple seconds. http://tomcat.10.x6.nabble.com/overcoming-a-message-size-limitation-in-tribes-parallel-messaging-with-NioSender-tt4995446.html
Re: tomcat7 cluster not communicating
if this is a newly installed system with linux in each virtual machine, make sure you have registered the IP address (192.168.x.x) in \etc\hosts files. On Sat, Mar 9, 2013 at 8:42 AM, Zippy Zeppoli zippyzepp...@gmail.comwrote: So, I have a tomcat7 cluster on AWS with a cluster configuration that works on my local VirtualBox cluster. Specs: - Same config. - Firewall turned off on all hosts. - unicast instead of multicast the following commands time out: nc -zv member1 8080 nc -zv member1 4110 They are listening however: tcp0 0 0.0.0.0:41100.0.0.0:* LISTEN tcp0 0 0.0.0.0:80800.0.0.0:* LISTEN tcpdump shows over and over SYN's but no replies on all members: 18:57:23.762712 IP member1: 52548 192.168.10.10.g2tag: Flags [S], seq 215397535, win 14600, options [mss 1460,sackOK,TS val 159216257 ecr 0,nop,wscale 7], length 0 Connecting to any other port from one member to another works fine, for example ssh. So I can't figure out why network communication works between all hosts, tomcat is listening, but trying to connect to the listening port fails. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Vince Stewart
Re: unwanted tcp6 protocol in tribes listener socket;
much appreciation for your help on this Tim, Actually you can learn so much more when things are not working because you come up with all possible reasons why they don't work and research widely. I started off totally naive about sockets, IPv4/6, and Ubuntu firewalls and have experienced quite a learning curve. In the end the problem would have been trivial to most but not to someone coming from my start point. The problem was that my home machine (behind a dsl modem) did not have an IP entered in the '/etc/hosts' file; the socket on the home machine needed to announce itself as 192.168.1.x but instead was one of two machines addressed by 127.0.1.1 meaning the dsl could not resolve the address and initial 'hand shake' failed. The whole process of getting tribes to communicate remote-peer-to-peer took almost a week which made it so gratifying to finally get it running. thanks again, On Mon, Feb 4, 2013 at 6:40 PM, Tim Watts t...@cliftonfarm.org wrote: On Mon, 2013-02-04 at 17:51 +1300, Vince Stewart wrote: Hi Tim, thanks so much for your reply netstat -t -l yields that includes: Active Internet connections (only servers) Proto Recv-Q Send-QLocal Address Foreign Address State tcp6 0 0 myComputerName:4000 [::]:*LISTEN netstat -atn | grep -P :4000\W yields (without any headings line) tcp6 0 0 127.0.1.1:4000 :::* LISTEN re But why would you want that limitation? My first aim was to send a single message from home to my VPS or vice versa. When I did not succeed I have been fishing for reasons and the first thing that struck me was that Ubuntu was reporting tpc6 but NioReceiver object clusterReceiver had a bind property of type Inet4Address and an address of 2130706689 (127.0.0.1). Possibly though, this is a normal IPv6 connection and I should treat it accordingly. I'll give that ago tomorrow morning and keep CATALINA_OPTS in mind as well. Yes, I believe this is normal. Looks like your system is using IPv4-mapped addresses which allows interoperability between IPv46 hosts without needing two IP stacks on the IPv6 host. Many thanks for your help. On Mon, Feb 4, 2013 at 4:06 PM, Tim Watts t...@cliftonfarm.org wrote: On Mon, 2013-02-04 at 14:39 +1300, Vince Stewart wrote: Using Tomcat 7.0.35 embedded in Java standalone application. Java SE 1.7.0. Ubuntu 12.04 Hi All, I have an experimental class below. The aim is just to open a listening port on port 4000 in the localhost address. When this has run, the address for the listener is 127.0.0.1 in other words an IPv4 address. However the SocksSocketImpl object representing the real socket continues to display the* useV4* property as *false* and my Ubuntu system displays the listening socket as tpc6. Listening only for tcp6? What does netstat -atn | grep -P :4000\W show? Perhaps what you want is to set the java.net.preferIPv4Stack system property in CATALINA_OPTS? Description here: http://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html But why would you want that limitation? I suspect there is some configuration issue somewhere and if anyone can help with this, I would be most grateful. I have also noted that the java.nio.channels.spi.SelectorProvider cannot return a Provider from loadProviderFromProperty() or loadProviderAsService() so therefore issues *provider = sun.nio.ch.DefaultSelectorProvider.create()*resulting in a ServerSocketChannel that is of type *sun.nio.ch.ServerSocketChannelImpl* and a ServerSocket of type *sun.nio.ch.ServerSocketAdapter*. I'm not sure that these are intended and may be I need a system property named java.nio.channels.spi.SelectorProvider to ensure some other SelectorProvider and therefore different ServerSocketChannel and ServerSocket types. public class TribalAfiliations{ Channel myChannel; private static class MyMemberListener implements MembershipListener{...} private static class MyMessageListener implements ChannelListener{...} TribalAfiliations() throws SocketException{ this.myChannel=new GroupChannel(); ChannelListener msgListener = new TribalAfiliations.MyMessageListener(); MembershipListener mbrListener = new TribalAfiliations.MyMemberListener(); myChannel.addMembershipListener(mbrListener); myChannel.addChannelListener(msgListener); try{ myChannel.start(Channel.MBR_TX_SEQ|Channel.MBR_RX_SEQ|Channel.SND_TX_SEQ|Channel.SND_RX_SEQ); /// same problem, withmyChannel.start(Channel.DEFAULT); } catch(ChannelException e){ System.out.println(e.getMessage()); } } -- Vince
Re: unwanted tcp6 protocol in tribes listener socket;
Hi Tim, thanks so much for your reply netstat -t -l yields that includes: Active Internet connections (only servers) Proto Recv-Q Send-QLocal Address Foreign Address State tcp6 0 0 myComputerName:4000 [::]:*LISTEN netstat -atn | grep -P :4000\W yields (without any headings line) tcp6 0 0 127.0.1.1:4000 :::* LISTEN re But why would you want that limitation? My first aim was to send a single message from home to my VPS or vice versa. When I did not succeed I have been fishing for reasons and the first thing that struck me was that Ubuntu was reporting tpc6 but NioReceiver object clusterReceiver had a bind property of type Inet4Address and an address of 2130706689 (127.0.0.1). Possibly though, this is a normal IPv6 connection and I should treat it accordingly. I'll give that ago tomorrow morning and keep CATALINA_OPTS in mind as well. Many thanks for your help. On Mon, Feb 4, 2013 at 4:06 PM, Tim Watts t...@cliftonfarm.org wrote: On Mon, 2013-02-04 at 14:39 +1300, Vince Stewart wrote: Using Tomcat 7.0.35 embedded in Java standalone application. Java SE 1.7.0. Ubuntu 12.04 Hi All, I have an experimental class below. The aim is just to open a listening port on port 4000 in the localhost address. When this has run, the address for the listener is 127.0.0.1 in other words an IPv4 address. However the SocksSocketImpl object representing the real socket continues to display the* useV4* property as *false* and my Ubuntu system displays the listening socket as tpc6. Listening only for tcp6? What does netstat -atn | grep -P :4000\W show? Perhaps what you want is to set the java.net.preferIPv4Stack system property in CATALINA_OPTS? Description here: http://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html But why would you want that limitation? I suspect there is some configuration issue somewhere and if anyone can help with this, I would be most grateful. I have also noted that the java.nio.channels.spi.SelectorProvider cannot return a Provider from loadProviderFromProperty() or loadProviderAsService() so therefore issues *provider = sun.nio.ch.DefaultSelectorProvider.create()*resulting in a ServerSocketChannel that is of type *sun.nio.ch.ServerSocketChannelImpl* and a ServerSocket of type *sun.nio.ch.ServerSocketAdapter*. I'm not sure that these are intended and may be I need a system property named java.nio.channels.spi.SelectorProvider to ensure some other SelectorProvider and therefore different ServerSocketChannel and ServerSocket types. public class TribalAfiliations{ Channel myChannel; private static class MyMemberListener implements MembershipListener{...} private static class MyMessageListener implements ChannelListener{...} TribalAfiliations() throws SocketException{ this.myChannel=new GroupChannel(); ChannelListener msgListener = new TribalAfiliations.MyMessageListener(); MembershipListener mbrListener = new TribalAfiliations.MyMemberListener(); myChannel.addMembershipListener(mbrListener); myChannel.addChannelListener(msgListener); try{ myChannel.start(Channel.MBR_TX_SEQ|Channel.MBR_RX_SEQ|Channel.SND_TX_SEQ|Channel.SND_RX_SEQ); /// same problem, withmyChannel.start(Channel.DEFAULT); } catch(ChannelException e){ System.out.println(e.getMessage()); } } -- Vince Stewart