Ramdas Hegde

Greenhorn
+ Follow
since Apr 07, 2003
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ramdas Hegde

Reposting this from the JBoss Tomcat forum (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=114458)

My application uses JBoss 3.2.6 running Tomcat 5.5 on a 2.4 Debian Linux kernel. I have not specified the connectionTimeout attribute on the AJP connector between Apache and Tomcat - with the idea that the connections get reused between web requests. There is no KeepAlive persistent connections between the http client and the Apache webserver.

I notice that the number of Tomcat threads that are being used to KeepAlive the connections between Apache and Tomcat is much higher than the concurrent number of http requests coming into Apache. Since the number of requests coming into the webserver is fairly even and known up front, i was hoping to have a permanent connection between Apache and Tomcat without having to tear down the connection for every request coming into the Apache webserver. But over a period of time, almost all the Tomcat threads in the pool are in the KeepAlive state and Apache instead of reusing one of the existing threads, seems to ask for a new thread and is unable to find one, resulting in connection latency. Was wondering if this is expected behaviour and does applying a connectionTimeout to force unused connections between Apache and Tomcat make sense?
Here is the stack showing the status of the Tomcat threads

"TP-Processor400" daemon prio=1 tid=0x08d430a0 nid=0x5c0 runnable [34bff000..34bff8d0]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:222)
at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
- locked <0x666cebf0> (a java.io.BufferedInputStream)
at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:598)
at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:535)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:663)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:534)
14 years ago
There are details on Bea's website at ftp://edownload:BUY_ME@ftpna2.bea.com/pub/downloads/jmsproviders.pdf with details on how to integrate a WLS MDB with a foreign JMS provider which might give you some tips.
Ramdas
Sun has a lot of useful material available through its Enterprise Blueprints (http://java.sun.com/blueprints/enterprise/index.html) which is a good place to start. There is the Petstore demo which can be also used as a good learning aid. But nothing beats actually trying out the code samples using some Application server to try out the concepts that you read in the Blueprints.
Ramdas
The reason I need to use BMT in place of CMT is because of the architecture of my application.
Here is how it works:
The MDB receives a message from the Topic/Queue and then calls another bean or business method which does a "while(TRUE) loop" on database events. In effect, the onMessage() call never completes. Since the onMessage() method never completes, if I were to use CMT for the MDB, the txn between the JMS provider and the container hosting the MDB would be open for a very long time and never end unless we forced the database event to end the while(TRUE) loop. I was not very comfortable with using long running txns and was attempting at using BMT to solve the problem.
Any suggestions on how I could design for this kind of scenario?
I need to be able to use Bean managed txns(BMT) to acknowledge message receipt in a MDB. I am using Weblogic Server 7.0 which says that in the case of MDBs which use BMT, message acknowledgement is done outside the beans txn context. The reason I need to do this is to be able to take care of situations wherein if the MDB fails for some reason after receiving the message and before having had a chance to process the message. If I use BMT with my MDB, there is no way I can indicate to the the JMS provider to resend the message when the MDB fails.
Any ideas on how to design for this?

Thanks
Ramdas