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
