[JBoss Messaging Users] - MessageSucker failure
by chipschoch
JBossAS 4.2.2, JBM 1.4.4
Running in out production system with two servers we are regularly getting this error. I have no idea what is causing it, but we never saw it until we upgraded to 1.4.4. This is killing us. Any ideas?
| 2009-09-16 14:29:48,726 ERROR | ReusableThread | org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager | Failed to process notifica
| tion
| org.jboss.jms.exception.MessagingJMSException: Failed to invoke
| at org.jboss.jms.client.delegate.DelegateSupport.handleThrowable(DelegateSupport.java:271)
| at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:205)
| at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:160)
| at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$createConsumerDelegate$aop(ClientSessionDel
| egate.java:267)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_8721389917985689973.invokeNext(ClientSessionDelegate$createConsumerDeleg
| ate_8721389917985689973.java)
| at org.jboss.jms.client.container.StateCreationAspect.handleCreateConsumerDelegate(StateCreationAspect.java:136)
| at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect30.invoke(StateCreationAspect30.java)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_8721389917985689973.invokeNext(ClientSessionDelegate$createConsumerDeleg
| ate_8721389917985689973.java)
| at org.jboss.jms.client.container.ConsumerAspect.handleCreateConsumerDelegate(ConsumerAspect.java:76)
| at org.jboss.aop.advice.org.jboss.jms.client.container.ConsumerAspect29.invoke(ConsumerAspect29.java)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_8721389917985689973.invokeNext(ClientSessionDelegate$createConsumerDeleg
| ate_8721389917985689973.java)
| at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
| at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_8721389917985689973.invokeNext(ClientSessionDelegate$createConsumerDeleg
| ate_8721389917985689973.java)
| at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
| at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
| at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_8721389917985689973.invokeNext(ClientSessionDelegate$createConsumerDeleg
| ate_8721389917985689973.java)
| at org.jboss.jms.client.delegate.ClientSessionDelegate.createConsumerDelegate(ClientSessionDelegate.java)
| at org.jboss.messaging.core.impl.clusterconnection.MessageSucker.start(MessageSucker.java:126)
| at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager.createSucker(ClusterConnectionManager.java:478)
| at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager.notify(ClusterConnectionManager.java:345)
| at org.jboss.messaging.core.impl.DefaultClusterNotifier.sendNotification(DefaultClusterNotifier.java:72)
| at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.addBindingInMemory(MessagingPostOffice.java:2447)
| at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.addBindingFromCluster(MessagingPostOffice.java:1036)
| at org.jboss.messaging.core.impl.postoffice.BindRequest.execute(BindRequest.java:55)
| at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:628)
| at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:610)
| at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654)
| at org.jgroups.blocks.RequestCorrelator.access$200(RequestCorrelator.java:40)
| at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
| at org.jgroups.util.ReusableThread.run(ReusableThread.java:234)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.IllegalStateException: Cannot find object in dispatcher with id r-xoi7rmzf-1-tmr6rmzf-kuxebg-mwxa
| at org.jboss.jms.wireformat.SessionCreateConsumerDelegateRequest.serverInvoke(SessionCreateConsumerDelegateRequest.java:97)
| at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:862)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:609)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:421)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:174)
| at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:182)
| at org.jboss.remoting.Client.invoke(Client.java:1858)
| at org.jboss.remoting.Client.invoke(Client.java:718)
| at org.jboss.remoting.Client.invoke(Client.java:706)
| at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255606#4255606
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255606
16 years, 9 months
[JBoss Tools Users] - Re: Web App Libraries not published?
by deanhiller
no, this thread and help ROCKS...thankYOU!!! I am just very opinionated ;) and my frustration comes out in typing, but thankyou for all the help and comments!!!
content assist fixed...(but probably a small bug there)....
so, thanks, I did figure out that somehow when selecting jars, *.txt files were allowed and showed up in the view and so that is why content assist was broken!!! I removed txt files and it works(but not sure why txt files were allowed in the first place....if I remember on standard java projects, eclipse filters those out but for some reason, they were not filtered out).
hmmm, I just realized there is a WTP servers view and a JBoss servers view. I will try the jboss servers view and see if that helps.
Please Please though, it would be great if the wizards for the next people that try to port work better and they should really add a step for Web App Libraries as well in there as that led to alot of confusion I thought(just my 2 cents)
i love the "open selection" addition so I can go from *.xhtml file to java code....Can't wait for the refactor method to affect my xhtml files though!!! that would absolutely rock!!!.
later,
Dean
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255594#4255594
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255594
16 years, 9 months
[JBoss Cache Users] - Is this a lazy loading issue? (not CacheLoader)
by chtimi2
I think i'm having a lazy-loading issue:
I have to JVMs:
-one with JBossPOJOCache (JBPC henceforth) in local mode (not replicated). On this JVM i have a class TracksTableImpl that implements its service interface by acting on an instrumented JBPC pojo TracksTableJbpcDelegate
(On second thought it looks more like a Core issue than a POJO one)
-one with a unit test that updates the remote state via a service call (remoting doesn't use JBPC), and then checks that the state is correct in case of a commit then a rollback
Server-side service:
public class TracksTableImpl implements TracksTable, TracksTableServices
| {
| private TracksTableJbpcDelegate delegate = new TracksTableJbpcDelegate ();
|
| @Override
| @Transactional
| public void updateXY ( double x , double y , boolean failOnUpdateY )
| {
| delegate.updateX ( x );
| if ( failOnUpdateY ) throw new TrackException ();
| delegate.updateY ( y );
| }
|
| @Override
| @Transactional
| public Position getPosition()
| {
| return delegate.getPosition();
| }
| }
|
Server-side, the JBPC POJO:
@org.jboss.cache.pojo.annotation.Replicable
| public class TracksTableJbpcDelegate
| {
| private List<ReadWriteTrack> tracks = new ArrayList<ReadWriteTrack> ();
|
| public void updateX ( double x )
| {
| ReadWriteKinematics k = getOrCreateReadWriteKinematics ();
| k.getReadWritePosition().setX ( x );
| }
|
| public void updateY ( double y )
| {
| ReadWriteKinematics k = getOrCreateReadWriteKinematics ();
| k.getReadWritePosition().setY ( y );
| }
|
| public Position getPosition()
| {
| Position ret = getUniqueTrack ().getKinematics().getPosition();
| //System.out.println ( "TracksTableJbpcDelegate/getPosition/ret.getX(): " + ret.getX() );
| //Navigating ret.getX: correct, up-to-date result
| //When commented: incorrect, rolled-back result
|
| return ret;
| }
|
| public ReadWriteTrack getUniqueTrack()
| {
| if ( tracks.size() != 1 ) throw new IllegalStateException ( "Cette methode ne peut etre appelee que si la liste contient un unique element" );
| ReadWriteTrack ret = tracks.get ( 0 );
| //System.out.println ( "TracksTableJbpcDelegate/getUniqueTrack/ret.getX(): " + ret.getKinematics().getPosition().getX() );
| return ret;
| }
| }
|
Of course Position is also instrumented (@Replicable).
Client side, the test:
@Test
| public void atomiciteUpdate3 () throws Exception
| {
| table.createTrack ( false );
| assertEquals ( 1 , table.size() );
|
| final double X_OK=111d, Y_OK=222d, PRECISION=0.001d;
| table.updateXY ( X_OK , Y_OK , false );
| assertEquals ( X_OK , table.getPosition().getX() , PRECISION );
| assertEquals ( Y_OK , table.getPosition().getY() , PRECISION );
|
| try
| {
| final double X_KO=333d, Y_KO=444d;
| table.updateXY ( X_KO , Y_KO , true );
| fail ();
| }
| catch ( Exception e ) {}
| finally
| {
| assertEquals ( Y_OK , table.getPosition().getY() , PRECISION );
| assertEquals ( X_OK , table.getPosition().getX() , PRECISION );
| }
| }
When the argument failOnUpdateY of method TracksTableImpl updateXY is true, the transaction is rolled back. This works correctly, that isn't the issue.
The issue is that when the bold underscored log is uncommented, the test passes, while it doesn't if it's commented.
Plus the same test with JBPC and the test in the same JVM passes.
Thus, i think i'm having a lazy-loading issue: when i call getX server-side before sending the response to the client, it works because i have just forced the state to be reloaded by navigating the getX relation.
When the test and JBPC are in the same JVM, the test passes because lazy-loading can work in this case (i'm not "detached" to use a Hibernate analogy)
But when the test is remote AND i don't navigate the relation, i'm detached and lazy-loading can't work (unlike Hibernate i don't get LazyInitializationException though, i just silently get an incorrect state).
So my question is:
-is it a lazy-loading issue?
-if so how do i specify to JBPC that i want eager-loading on serialization?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255587#4255587
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255587
16 years, 9 months
[EJB 3.0 Users] - Re: ERROR [GeneralPurposeDatabasePersistencePlugin] Cannot d
by kyle.bober
Yes that is definitely the issue at hand. I removed the classloader isolation by removing the jboss-app.xml in my EAR file. I now run into another issue which looks to be the same as mentioned in this post:
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212804#4212804
If I launch a series of EJBTimers and restart the JBoss 5.1.0.GA server I notice a good portion of them fail on JBoss restart. this is what I see in the log:
| 10:02:35,250 ERROR [TimerImpl] Error invoking ejbTimeout
| org.jboss.aop.DispatcherConnectException: EJB container is not completely started, or is stopped.
| at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:62)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:249)
| at org.jboss.as.ejb3.timerservice.TimedObjectInvokerBridge.callTimeout(TimedObjectInvokerBridge.java:44)
| at org.jboss.ejb.txtimer.TimerImpl$TimerTaskImpl.run(TimerImpl.java:561)
| at java.util.TimerThread.mainLoop(Timer.java:512)
| at java.util.TimerThread.run(Timer.java:462)
It almost looks as if my EJBTimer bean hasn't fully loaded and the Timer is kicked of before the EJBTime is completely loaded. Any ideas as to what could be causing this issue and how to rectify it???
Here is the EJBTimer code snippet:
| @Stateless
| @Remote
| @RemoteBinding(jndiBinding=IProcessTimerService.PROCESS_TIMER_EJB_JNDI)
| @TransactionManagement(TransactionManagementType.BEAN)
| public class ProcessTimerService implements IProcessTimerService { ... }
Thanks again for your help!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255580#4255580
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255580
16 years, 9 months
[Performance Tuning] - Re: Scaling of a Seam app
by PeterJ
1) None that I know of. You'll have to roll your own load tests.
2) Hmm, "setting 2 and versioning" was not the kind of answer I expected, are these Hibernate terms? I was wanting to know what isolation level was mentioned in *-ds.xml, which would be something like TRANSACTION_READ_COMMITTED.
3) Oh, you are using MySQL - now the 15 connections rings a bell! In a default installation (at least on Windows, don't have access to my Linux box just now), MySQL allows a max of 15 connections. Edit the max_connections value in the mysql config file.
Also, have you checked with mysql as to how many connections are in use, and use the jmx console to see how many connections JBoss AS has established?
5) I always use InnoDB - it is the only data engine that provides ACID properties. The myisam engine requires the entire table to be locked to ensure transactional writes (or at least that is my understanding). myisam is great if you will load the database with data in a batch operation and from then on will only read the data. For anything else use innodb.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255571#4255571
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255571
16 years, 9 months