Finally I have been able to tune Jboss AS to work as per the expectation of our
company.I have made few configuration changes and I think combination of those
helped. Those are underlined below
1I have disabled XA recovery coniguration outlined in chapter 8 of JBoss
messaging installation.
Sure will try that in our development environment.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4234766#4234766
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4234766
___
Tim,
The number of client session created by remote clients are constant at 9 as
they use a connection pool. However we have some local components on the jboss
server which opens and closes connections while they put messages to the
queues.We are using the java:/JmsXA connection factory.
Howard,
Nice to see your reply again. As you suggested earlier we are using the
jboss-remoting version 2.2.2.SP11
Thanks,
Pratim
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4234547#4234547
Reply to the post :
Our JBoss server in production became very slow so we had to bounce it. But we
were able to get some important information. We found this kind of messages in
our log file
May 29, 01:25:41 WARN [arjLoggerI18N]
[com.arjuna.ats.arjuna.coordinator.BasicAction_58] - Abort of action id
Clebert,
We did the stack trace and found out that the number of WorkerThread for the
clients beyond a firewall are steadily increasing by 1 or 2 everyday.It's
shwoing up on jconsole as WorkerThread#17[10.**.2*.1**:34128] or similar.When
it's reaching about 30-35 it's bringing down the server
Clebert,
I tried with the jmap -histo option which gives me the below results while the
production server is running on a normal day. It doesn't look like anything
consuming a huge memory compared to the allocated 2GB memory. But our server
has become slow already. It takes almost 10 minutes
Thanks for replying. Let us analyze more on the stack trace and the histogram
and will update you.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4232358#4232358
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4232358
We are using JBM 1.4.2 GA SP1 with JBoss 4.2 GA. We are hosting our jboss
servers on Solaris 10 (4 processors /8 GB memory). We do not persist messages
more than 30-40 at a time. We also use JMS transactions for message rollback
within session beans. Some of the message consumers are local MDBs
forgot to mention that we use two Jboss servers in cluster and JBoss messaging
database in Oracle 10g.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4232071#4232071
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4232071
thanks for the suggestion,let me try that.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4232076#4232076
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4232076
___
jboss-user
I am coming across this problem in EJB 2. Any idea how to fix this issue with
EJB 2 on Jboss 4.2.2 GA?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4228458#4228458
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4228458
We are running jboss-messaging-1.4.2.GA-SP1 on Jboss AS 4.2.2GA. We also have a
similar situation where a transacted stateless session EJB is having a non
transacted JMS connection . Our application is quite big for testing with
Jboss profiler. Any idea whether it can cause a memory leak ?
Messaging 4.2.2 SP1 also works fine.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4213960#4213960
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4213960
___
jboss-user mailing
my bad, JBM 1.4.2 SP1 works fine.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4213961#4213961
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4213961
___
jboss-user mailing list
Thanks a lot Howard. I tried with 1.4.0 SP03-CP07 and it works. No timeout no
messages stuck in the queue!!
However during building the messaging part I found etc/ folder missing under
src/ so I copied the whole etc folder from output and it did the trick.
Another team is trying with 1.4.2 GA
I downloaded jboss-remoting SP11 from
http://repository.jboss.com/jboss/remoting/2.2.2.SP11-brew/lib/ and made
changes suggested by Howard. We had given an idle time of 14 hours for our
listener. Now some of the messages sent to the JBM queue are getting stuck as
the listener is not able to
Howard,
while we are testing failover I am seeing this in the logs
WARN org.jboss.remoting.Client - unable to remove remote callback handler:
Can not get connection to server. Problem establishing socket connection for
InvokerLocator
Howard,
I am little bit curious if JBM 1.4.2-GA-SP1 fixes the issue as well.We are
using 1.4.2 GA,so would like to upgrade to the next higher version.
Once again thanks for your help.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4213229#4213229
Reply to the
Thanks Howard for the suggestion. We downloaded SP11 and increased
validatorPingTimeout and clientLeasePeriod to 5 in remoting bisocket file.
We need to keep our dev server running overnight to see if the error goes away.
Meanwhile on the client side as I mentioned before that we have a idle
I should add one more thing here. Earlier we migrated from JBoss MQ to JBoss
Messaging. There was no cluster for JBoss Messaging and the client side
failover error handling was through the JMS ExceptionListener.
We refreshed the connection every half an hour to get over the firewall freeze
Hi,
I am using JBoss 4.2.2GA and Messaging 1.4.2 with remoting version 2.2.2.SP10.
We have setup JBM cluster with oracle as database. The jboss server is accessed
by a remote client located beyond a firewall with a one hour timeout for any
idle client. We have a JMS listener which listnes for
22 matches
Mail list logo
