cluster problems: memberDisappeared errors

2005-07-18 Thread Joshua Szmajda
I'm using the cluster fix patch on 5.5.9 (from 
http://issues.apache.org/bugzilla/show_bug.cgi?id=34389) with 8 hosts 
clustered together. I was seeing alot
of memberDisappeared errors before I applied this patch, now I'm still 
seeing them, but with more detail.

Here's an example error from catalina.out:

Jul 18, 2005 5:40:51 PM org.apache.catalina.cluster.tcp.SimpleTcpCluster 
memberDisappeared
INFO: Received member 
disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://10.0.0.15:4002,10.0.0.15,4002, 
alive=1018550]
Jul 18, 2005 5:40:51 PM org.apache.catalina.cluster.tcp.DataSender 
pushMessage
INFO: resending 782 bytes to 10.0.0.15:4002 from 55784 
java.net.SocketException: Socket closed

   at java.net.SocketInputStream.read(SocketInputStream.java:162)
   at java.net.SocketInputStream.read(SocketInputStream.java:182)
   at 
org.apache.catalina.cluster.tcp.DataSender.waitForAck(DataSender.java:542)
   at 
org.apache.catalina.cluster.tcp.DataSender.pushMessage(DataSender.java:504)
   at 
org.apache.catalina.cluster.tcp.FastAsyncSocketSender$FastQueueThread.run(FastAsyncSocketSender.java:401)


A typical cluster config is:
   Cluster 
className=org.apache.catalina.cluster.tcp.SimpleTcpCluster 
name=hydraNation

managerClassName=org.apache.catalina.cluster.session.DeltaManager

expireSessionsOnShutdown=false
useDirtyFlag=true
notifyListenersOnReplication=true

   Membership
   className=org.apache.catalina.cluster.mcast.McastService
   mcastAddr=228.0.0.4
   mcastPort=45564
   mcastFrequency=700
   mcastDropTime=5000/

   Receiver
   
className=org.apache.catalina.cluster.tcp.Jdk13ReplicationListener

   tcpListenAddress=10.0.0.12
   compress=false
   tcpListenPort=4002
   /

   Sender
 
className=org.apache.catalina.cluster.tcp.ReplicationTransmitter

 replicationMode=fastasyncqueue
 compress=false
 doProcessingStats=true
 queueTimeWait=true
 maxQueueLength=1000
 queueDoStats=true
 queueCheckLock=true
 ackTimeout=15000
 waitForAck=true
 autoConnect=false
 keepAliveTimeout=@node.ackTimeout@
 keepAliveMaxRequestCount=-1/

   Valve 
className=org.apache.catalina.cluster.tcp.ReplicationValve
 
filter=.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;/


   Deployer 
className=org.apache.catalina.cluster.deploy.FarmWarDeployer

 tempDir=/tmp/war-temp/
 deployDir=/tmp/war-deploy/
 watchDir=/tmp/war-listen/
 watchEnabled=false/
   /Cluster


any ideas? I'm thinking there's something wrong with my multicast setup, 
but everything was working fine this morning... The servers are running 
RHEL3, all 2 way AMD64 machines with 4Gb ram each. They each have two 
network interfaces, each eth0 is connected to one gigabit switch, each 
eth1 to another (internal) gigabit switch. I don't think I should be 
hitting any network bottlenecks.. ? There is alot of load on the site 
being served in general, but no big jump in hits today.


Should I be using a fastasyncqueue? What are the tradeoffs in Sender modes?

Thanks in advance!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



tomcat clustering

2005-04-25 Thread Joshua Szmajda
Hey all,

Is there a way to get the cluster system to replicate ServletContext
scope variables between cluster members? If not, is there a good guide
to writing Multicast sockets somewhere?

Thanks alot!
-Josh

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: tomcat clustering

2005-04-25 Thread Joshua Szmajda
Awesome!
I think though since I need this functionality now, I might go with
JGroups' DistributedHashtable system. It's basically what I need right
out of the box.

Thanks, and good luck! I'll be looking forward to that functionality.

-Josh

Peter Rossbach wrote:

 With the next release I hope we support those handlings context
 attribute replication handling.
 We start a discussion at this list ( last three days).

 Topic:
 http://marc.theaimsgroup.com/?t=11141745513r=1w=2

 Peter




 Joshua Szmajda schrieb:

 Hey all,

 Is there a way to get the cluster system to replicate ServletContext
 scope variables between cluster members? If not, is there a good guide
 to writing Multicast sockets somewhere?

 Thanks alot!
 -Josh

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



  



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Tomcat, Apache connected in interesting way

2004-11-23 Thread Joshua Szmajda
Hi all,
I run a pretty high traffic site using Tomcat. We've gone through a 
number of configurations in the past, and I wanted to share with you the 
newest setup that we're using. It's a bit unorthodox perhaps, and I was 
wondering if anyone could think of possible problems? It does seem to be 
the fastest and most stable setup we've had yet.

Previously we've used Apache and Tomcat connected through jk1 and jk2. 
Also we've run direct to tomcat's http connector. JK1 was ok, but very 
slow. JK2 was fast (using unixSocket communication), but very buggy and 
crash prone. Tomcat alone was good, but it lacked some advanced apache 
stuff we wanted (Mostly URL Rewriting and good SSL handling).

After reading about the upcoming mod_proxy ajp connector for apache 2.2, 
I had the idea to use stuff that's in the current RHEL apache 2.0 
release to accomplish what I feel to be a similar effect. We've set up 
apache to reverse proxy requests for .jsp and .do (we're using struts) 
to tomcat's standard http connector.
From the httpd.conf:

Proxy *
 Order deny,allow
 Allow from all
/Proxy
ProxyRequests off
RewriteEngine on
RewriteRule ^/$ http://128.121.26.205/index.jsp [P,NC]
RewriteRule ^/(.*.jsp.*)$ http://128.121.26.205/$1 [P,NC]
RewriteRule ^/(.*.do.*)$ http://128.121.26.205/$1 [P,NC]
This allows apache to process additional rewriting things (I left them 
out) and also to serve images and other static content. I felt that 
apache would be better at handling static content than tomcat in 
general, so this will be an overall speed improvement.

Anyway, any flaws here I should be aware of? Comments? Thanks!
-Joshua Szmajda
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Tomcat, Apache connected in interesting way

2004-11-23 Thread Joshua Szmajda
Both are on the same server, yes. They are however listening on 
different IP addresses. If needed, you could set the tomcat http 
connector to listen on a different port and adjust the rewrite rule 
accordingly.

As far as SSL goes, the SSL encryption will be in place from the client 
to apache, but not from apache to tomcat. This is ok because apache and 
tomcat are both in the same trusted subnet (in fact, on the same 
machine). If that weren't the case, you could alter the rewrite rule on 
the SSL vhost to send requests to tomcat's ssl connector, thereby 
encrypting all connections.

-Josh
Joshua -
Are tomcat and apache running on the same server? If so, it appears 
from what you have here that they are on the same port...so...what am 
I missing?

Also, how do you handle .jsps and .dos that need to be handled by 
Tomcat securely (using SSL). This seems to pass them all off to the 
non-secure version. Would it just be a more complex RewriteRule that 
tests for https vs. http?


Thanks,
Matt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: AW: Tomcat 4.1.24 + Security Manager + weird Exceptions

2004-07-21 Thread Joshua Szmajda
I'm experiencing this same issue. I've got Tomcat 5.0.27, Apache 2.0.46,
and jk2 version 2.0.4. Has there been any solution? It occurs primarily
under heavy load.
-Joshua Szmajda
We've got a similar issue, though this in on Linux and using channelUnix/JNI instead 
of normal tcp channelSocket.
We're using Apache2/mod_jk2 (built from tomcat-connectors-1.1M1).

On heavy load, there are over 3000 sockets open by one Tomcat/JVM, they don't seem to 
go down again too while Tomcat is running.
(since File Descriptor limit on Solaris is lower normally (1024 or summat i think) 
this would cause us heavy problems there too)

The Tomcats and Apache are restarted during the night to free up Memory, so socket 
count goes down then.

However the application doesn't seem to be affected by this.
In catalina.out there are many errors like this:
org.apache.jk.common.ChannelUn receive
SEVERE: receive error:   12
java.lang.Throwable
   at org.apache.jk.common.ChannelUn.receive(ChannelUn.java:230)
   at org.apache.jk.common.ChannelUn.processConnection(ChannelUn.java:282)
   at org.apache.jk.common.AprConnection.runIt(ChannelUn.java:350)
   at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:631)
   at java.lang.Thread.run(Thread.java:536)

org.apache.jk.common.JniHandler nativeDispatch
SEVERE: nativeDispatch: error -3
java.lang.Throwable
   at org.apache.jk.common.JniHandler.nativeDispatch(JniHandler.java:312)
   at org.apache.jk.common.ChannelUn.send(ChannelUn.java:221)
   at org.apache.jk.common.ChannelUn.invoke(ChannelUn.java:306)
   at org.apache.jk.server.JkCoyoteHandler.doWrite(JkCoyoteHandler.java:249)
   at org.apache.coyote.Response.doWrite(Response.java:530)
   at org.apache.coyote.tomcat4.OutputBuffer.realWriteBytes(OutputBuffer.java:384)
   at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:439)
   at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:359)
   at org.apache.coyote.tomcat4.OutputBuffer.writeBytes(OutputBuffer.java:411)
   at org.apache.coyote.tomcat4.OutputBuffer.write(OutputBuffer.java:398)
   at 
org.apache.coyote.tomcat4.CoyoteOutputStream.write(CoyoteOutputStream.java:110)
   at 
org.apache.catalina.servlets.DefaultServlet.copyRange(DefaultServlet.java:1996)
   at org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:1745)
   at 
org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1073)
   at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:506)
.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


JK2 possible JNI problem? nativeDispatch exceptions

2004-07-20 Thread Joshua Szmajda
Hi All,
I've got Tomcat 4.1.20 and Apache 2.0.46 running on Red Hat Enterprise 
Linux AS 3. I'm using the jk2 connector (connectors version 2.0.4) with 
a unixSocket channel. My problem is that the catalina.out file 
constantly gets the following two entries:

this one comes constantly..
[Mon Jul 19 19:20:51 2004] ( info ) [jk_jni_aprImpl.c (431)]  jkInvoke() 
invoke a971c670

and an exception (very often):
Jul 19, 2004 7:20:11 PM org.apache.jk.common.JniHandler nativeDispatch
SEVERE: nativeDispatch: error -3
java.lang.Throwable
   at 
org.apache.jk.common.JniHandler.nativeDispatch(JniHandler.java:310)
   at org.apache.jk.common.ChannelUn.send(ChannelUn.java:218)
   at org.apache.jk.common.ChannelUn.invoke(ChannelUn.java:303)
   at 
org.apache.jk.server.JkCoyoteHandler.doWrite(JkCoyoteHandler.java:279)
   at org.apache.coyote.Response.doWrite(Response.java:586)
   at 
org.apache.coyote.tomcat4.OutputBuffer.realWriteBytes(OutputBuffer.java:405)
   at 
org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:436)
   at 
org.apache.coyote.tomcat4.OutputBuffer.doFlush(OutputBuffer.java:354)
   at 
org.apache.coyote.tomcat4.OutputBuffer.flush(OutputBuffer.java:336)
   at 
org.apache.coyote.tomcat4.CoyoteWriter.flush(CoyoteWriter.java:117)
   at 
org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:209)
   at 
org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:810)
   at org.apache.jsp.error_jsp._jspService(error_jsp.java:337)
   at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
   at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:210)
   at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
   at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
   at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
   at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:432)
   at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:356)
   at 
org.apache.catalina.valves.ErrorDispatcherValve.custom(ErrorDispatcherValve.java:420)
   at 
org.apache.catalina.valves.ErrorDispatcherValve.throwable(ErrorDispatcherValve.java:258)
   at 
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:179)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
   at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:163)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
   at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
   at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
   at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
   at 
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:199)
   at 
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:324)
   at 
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:395)
   at 
org.apache.jk.common.ChannelUn.processConnection(ChannelUn.java:286)
   at org.apache.jk.common.AprConnection.runIt(ChannelUn.java:347)
   at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
   at java.lang.Thread.run(Thread.java:534)
   
I'm running a very high traffic site and so I was wondering if perhaps 
this was due to file locking collisions on the socket? I'm not sure 
there. This didn't used to happen when I was using regular domain 
sockets. I do need the unixSocket channel however, as it's proven to be 
much much faster.

I've tried commenting out the line that writes the first line, but that 
only seems to exacerbate the number of exceptions. I also was able to 
diminish the number of exceptions by changing the shm file from anon to 
a real file on the system. I'm thinking this is slowing down the JNI 
somehow? (leading me back to the collisions theory).

Any help is greatly appreciated! Otherwise I'm left with trying to read 
the code and learn JNI =/

Thanks Again,
-Joshua Szmajda
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: AW: Tomcat 4.1.24 + Security Manager + weird Exceptions

2004-07-20 Thread Joshua Szmajda
I'm experiencing this same issue. I've got Tomcat 5.0.27, Apache 2.0.46, 
and jk2 version 2.0.4. Has there been any solution? It occurs primarily 
under heavy load.

-Joshua Szmajda
We've got a similar issue, though this in on Linux and using channelUnix/JNI instead 
of normal tcp channelSocket.
We're using Apache2/mod_jk2 (built from tomcat-connectors-1.1M1).

On heavy load, there are over 3000 sockets open by one Tomcat/JVM, they don't seem to 
go down again too while Tomcat is running.
(since File Descriptor limit on Solaris is lower normally (1024 or summat i think) 
this would cause us heavy problems there too)

The Tomcats and Apache are restarted during the night to free up Memory, so socket 
count goes down then.

However the application doesn't seem to be affected by this.
In catalina.out there are many errors like this:
org.apache.jk.common.ChannelUn receive
SEVERE: receive error:   12
java.lang.Throwable
   at org.apache.jk.common.ChannelUn.receive(ChannelUn.java:230)
   at org.apache.jk.common.ChannelUn.processConnection(ChannelUn.java:282)
   at org.apache.jk.common.AprConnection.runIt(ChannelUn.java:350)
   at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:631)
   at java.lang.Thread.run(Thread.java:536)

org.apache.jk.common.JniHandler nativeDispatch
SEVERE: nativeDispatch: error -3
java.lang.Throwable
   at org.apache.jk.common.JniHandler.nativeDispatch(JniHandler.java:312)
   at org.apache.jk.common.ChannelUn.send(ChannelUn.java:221)
   at org.apache.jk.common.ChannelUn.invoke(ChannelUn.java:306)
   at org.apache.jk.server.JkCoyoteHandler.doWrite(JkCoyoteHandler.java:249)
   at org.apache.coyote.Response.doWrite(Response.java:530)
   at org.apache.coyote.tomcat4.OutputBuffer.realWriteBytes(OutputBuffer.java:384)
   at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:439)
   at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:359)
   at org.apache.coyote.tomcat4.OutputBuffer.writeBytes(OutputBuffer.java:411)
   at org.apache.coyote.tomcat4.OutputBuffer.write(OutputBuffer.java:398)
   at 
org.apache.coyote.tomcat4.CoyoteOutputStream.write(CoyoteOutputStream.java:110)
   at 
org.apache.catalina.servlets.DefaultServlet.copyRange(DefaultServlet.java:1996)
   at org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:1745)
   at 
org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:1073)
   at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:506)
.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


passing a session from non-SSL to SSL

2002-09-07 Thread Joshua Szmajda

Hi all,

I'm upgrading an application from Tomcat 3.2 to Tomcat 4.0, and I'm 
noticing that my application is now losing track of its sessions when I 
switch from non-SSL to SSL. The code worked fine in Tomcat 3.2.. I was 
wondering if there's something I'm missing. My server.xml has a single 
Ajp13 connector and a plain vanilla host / context configuration. I've 
JKMount'ed /* to ajp13 in apache on both the normal and SSL virtual hosts.

I'm sure it's something in the spec that's changed, but I can't for 
the life of me find out what. Changing the code is possible, but 
preferably avoidable as I didn't write it.

Thanks in advance!
-Joshua Szmajda


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]