[jboss-user] [JBoss Messaging Users] - Re: Urgent! Clustered-queue on 2 nodes failed
Forgot to mention, I am also running AS 5.1.0 GA with the JbossMessaging that came with it (I believe it is 1.4.3). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252949#4252949 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252949 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Messaging Users] - Re: Urgent! Clustered-queue on 2 nodes failed
It appears that I, too, am facing the same issue as described by venkadesan. the messages are sent to two queues in round robin (say out of 10 messages, 5 goes to node1 and 5 goes to node 2). When we try to consume, consumer pointing to node1 can consume only 5 from node 1 and nothing from node2. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252948#4252948 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252948 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Re: Error on stage transfer during SessionCache start up
The clustering seems to work okay in a local setting. But the CacheMarshaller200 class is in the jbosscache-core.jar (jbosscache-core.jar MANIFEST shows version 3.1.0.GA). Should it be in this jar? I am using the jar that came with JBoss AS 5.1.0. | jar -tvf jbosscache-core.jar | grep CacheMarshaller | 30170 Mon May 04 15:48:16 PDT 2009 org/jboss/cache/marshall/CacheMarshaller200.class | 1801 Mon May 04 15:48:16 PDT 2009 org/jboss/cache/marshall/CacheMarshaller210.class | 4274 Mon May 04 15:48:16 PDT 2009 org/jboss/cache/marshall/CacheMarshaller300.class | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246261#4246261 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246261 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Cache: Core Edition] - Error on stage transfer during SessionCache start up
Application server: JBoss AS 5.1.0
I am upgrading from JBoss 4.0.5 to JBoss 5.1.0.
When I deploy a second node in my parititon I am getting an error during
SessionCache start up. It occurs during state transfer. The stack trace is
posted below.
I am using udp and the standard-session-cache. The partition for the two nodes
starts up fine. There are no other errors during start up.
I used the jgroups test program found here:
http://www.jboss.org/community/wiki/JGroupsLargetStateOrPacketTransferProblems
The state transfer completed fine; only took about 1 second).
I tried adjusting the stateRetrievalTimeout (from 6 to 12) but it did
not help. I also tried adjusting the FRAG2 size but that did not help.
Here is my configuration for udp (from the file
jgroups-channelfactory-stacks.xml
|
|
| '>
| ]>
|
|
|
|
|
|
| &shared-udp;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Here is my configuration for standard-session-cache (from
jboss-cache-manager-jboss-beans.xml):
|standard-session-cache
|
|
|
|
| org.jboss.cache.transaction.BatchModeTransactionManagerLookup
|
|
| ${jboss.partition.name:DefaultPartition}-SessionCache
|
| ${jboss.default.jgroups.stack:udp}
| true
|
| PESSIMISTIC
| REPEATABLE_READ
| false
| REPL_ASYNC
|
|
| 17500
|
| 15000
|
|
|
|
| false
|
| false
|
|
| 0
|
| 0
|
| true
|
|
|
|
|
|false
|
|
|default
|
|17500
|
|
|false
|true
|true
|
|
|
|
| 1
|
| true
|
|
|
|
|
|
|
|true
|false
|
|
|
|
|
|${jboss.server.data.dir}${/}session
|
|false
|true
|true
|false
|false
|
|
|
|
|
|
|
|
|
The stack trace
| DEBUG [Incoming-2,10.10.67.6:33425][2009-07-17
| 12:04:52,389][org.jboss.cache.remoting.jgroups.ChannelMessageListener]
| ChannelMessageListener.java(118): Caught exception integrating state!
| org.jboss.cache.CacheException: java.lang.NullPointerException
| at
|
org.jboss.cache.statetransfer.LegacyStateTransferIntegrator.integrateTransientState(LegacyStateTransferIntegrator.java:118)
| at
|
org.jboss.cache.statetransfer.LegacyStateTransferIntegrator.integrateState(LegacyStateTransferIntegrator.java:88)
| at
|
org.jboss.cache.statetransfer.LegacyStateTransferManager.setState(LegacyStateTransferManager.java:155)
| at
|
org.jboss.cache.statetransfer.DefaultStateTransferManager.setState(DefaultStateTransferManager.java:163)
| at
|
org.jboss.cache.remoting.jgroups.ChannelMessageListener.setState(ChannelMessageListener.java:190)
| at
|
org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:676)
| at
|
org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:776)
| at org.jgroups.JChannel.up(JChannel.java:1252)
| at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:462)
| at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:501)
| at
|
org.jgroups.protocols.pbcast.STATE_TRANSFER.handleStateRsp(STATE_TRANSFER.java:421)
| at
org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:120)
| at org.jgroups.protocols.FRAG2.up(FRAG2.java:188)
| at org.jgroups.protocols.FC.up(FC.java:473)
| at org.jgroups.protocols.pbcast.GMS.up(GMS.java:824)
[jboss-user] [JBoss Cache: Core Edition] - distributed entity cache (invalidation based)
I am trying to deploy distributed caching for a single entity. I am running
JBoss AS 5.1.0 with jdk 1.5. I have two nodes running on two separate servers
in a single partition.
I see the caching work fine on each single node but the cache does not
replicate/invalidate between the two nodes (I'd like to use invalidation).
Test case:
1. Ran a JUnit test that loaded the entity on node1 and node2 so it was in the
cache on each node in the partition.
2. Ran a JUnit test that changed the entity on node1.
3. Ran a JUnit test that loaded the entity on node1 and node2.
>From looking at logging in both of the servers I can tell that node2 has the
>stale version (grabbed the entity from its cache instead of reloading it). I
>also have looked at the database log to verify that node2 did not try to load
>the entity when I requested it after it was changed by node1.
I added this to my entity class:
| import org.hibernate.annotations.Cache;
| import org.hibernate.annotations.CacheConcurrencyStrategy;
|
| @Cache (usage=CacheConcurrencyStrategy.TRANSACTIONAL)
|
I added this to my persistence unit.
|
|
|
|
|
|
|
Is there some other attribute that must be set in order to have a node notify
the other nodes in the partition when a cached entity has changed? mvcc-entity
has the property cacheMode set to INVALIDATION_SYNC. I figured that would do
it. I also tried using pessimistic-entity but had no luck.
The only change that I have made to jboss-cache-manager-jboss-beans.xml is to
set the multiplexer property to ${jboss.default.jgroups.stack:tcp} (did not
want to use udp). I did this for each cache entry in this file.
For example,
|
|mvcc-entity
|
|
|
|
| MVCC
|
| READ_COMMITTED
| false
|
|
| INVALIDATION_SYNC
|
|
| ${jboss.partition.name:DefaultPartition}-mvcc-entity
|
|
|
| ${jboss.default.jgroups.stack:tcp}
|
|
| false
|
|
| 6
|
|
| 17500
|
|
| 15000
|
|
| true
|
| true
|
|
| 0
|
| 0
|
|
|
|5000
|
|
|
| /
|
|
|
|1
|
|1000
|
|120
|
|
|
|
|
|
|
|
| /TS
|
|
|
|
|
|
|
|
|
|
|
|
Thanks.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236185#4236185
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236185
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Messaging] - Re: NullPointerException when trying to open a session for s
Thanks for the reply. I have two separate clusters (partitions), each with one node. One cluster named AppPartition, one cluster named BatchPartition. The JMS server is running on the single node in BatchPartition. The single node in AppPartition is unable to send a JMS message from within the application server to the JMS server hosted on BatchPartition. On the same machine that acts as the single node for AppPartition I can execute a standalone program that sends a JMS message to the JMS server hosted on the single node in BatchPartition. When I start up JBoss I use command line switches for the partition name and the rmi server hostname. E.g., [for the BatchParition node] -Djava.rmi.server.hostname=172.16.77.70 -Djboss.partition.name=BatchPartition [for the AppParition node] -Djava.rmi.server.hostname=172.16.77.2 -Djboss.partition.name=AppPartition View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233699#4233699 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233699 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Messaging] - NullPointerException when trying to open a session for sendi
I am getting a NullPointerException when trying to open a session for sending a
JMS message.
I have two clusters, each with one node started up. I run into the error when
trying to send a message from within the server that is not running the JMS
server (I removed the deploy/messaging folder from this server).
I know that the server trying to send the message can see the server that is
running the JMS server because I can successfully send a JMS message when
running a standalone app from this same machine using the same JMS message
sending code. This also shows that the JMS destination is accessible via JNDI.
Also, when I run the same code in the server on which the JMS server is running
it is able to send the JMS message without a problem.
* Version: JBoss AS 5.1.0GA (also had the problem on 5.0.1); the JBossMessaging
version that comes with JBoss AS 5.1.0GA
* IP address for jboss-batch-11, the server running the JMS server: 172.16.77.70
* Using Java 1.6.
* Additional note: This code worked fine in JBoss 4.0.5, JBossMQ.
Here is the relevant log output (exception stacktrace found at the end).
| DEBUG [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,102][com.squaretrade.jms.PersistentQueueProcessingThread]
PersistentQueueProcessingThread.java(69): Requesting object from queue
| DEBUG [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,334][com.squaretrade.jms.PersistentQueueProcessingThread]
PersistentQueueProcessingThread.java(72): Message dequeued; ready to process
| DEBUG [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,418][com.squaretrade.jms.MessageDeliveryDelegate]
MessageDeliveryDelegate.java(127): Looking up the destination
| INFO [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,422][com.squaretrade.locator.Locator] Locator.java(238): LOOKING UP
JMS RESOURCE: queue/DataReplication
| INFO [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,513][com.squaretrade.locator.Locator] Locator.java(364): USING
PROVIDER URL FOR REMOTE CONTEXT:
jboss-batch-local-11:1100,jboss-batch-local-12:1100
| DEBUG [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,554][org.jnp.interfaces.TimedSocketFactory] Logger.java(228):
createSocket, hostAddr: jboss-batch-local-11/172.16.77.70, port: 1100,
localAddr: null, localPort: 0, timeout: 0
| FINE [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,654][sun.rmi.loader] Log.java(212): ha-jms-queue-proces...@199aa4e:
interfaces = [org.jnp.interfaces.Naming,
org.jboss.ha.framework.interfaces.HARMIProxy], codebase =
"http://172.16.77.70:8083/";, defaultLoader =
baseclassloa...@1015293{vfszip:/usr/local/jboss-5.1.0.GA/server/app/deploy/app.ear/}
| FINE [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,656][sun.rmi.loader] Log.java(212): ha-jms-queue-proces...@199aa4e:
name = "java.lang.reflect.Proxy", codebase = "http://172.16.77.70:8083/";,
defaultLoader =
baseclassloa...@1015293{vfszip:/usr/local/jboss-5.1.0.GA/server/app/deploy/app.ear/}
| FINE [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,659][sun.rmi.loader] Log.java(212): ha-jms-queue-proces...@199aa4e:
name = "org.jboss.ha.framework.interfaces.HARMIClient", codebase =
"http://172.16.77.70:8083/";, defaultLoader =
baseclassloa...@1015293{vfszip:/usr/local/jboss-5.1.0.GA/server/app/deploy/app.ear/}
| FINE [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,662][sun.rmi.loader] Log.java(212): ha-jms-queue-proces...@199aa4e:
name = "java.util.ArrayList", codebase = "http://172.16.77.70:8083/";,
defaultLoader =
baseclassloa...@1015293{vfszip:/usr/local/jboss-5.1.0.GA/server/app/deploy/app.ear/}
| FINE [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,664][sun.rmi.loader] Log.java(212): ha-jms-queue-proces...@199aa4e:
name = "org.jboss.ha.framework.server.HARMIServerImpl_Stub", codebase =
"http://172.16.77.70:8083/";, defaultLoader =
baseclassloa...@1015293{vfszip:/usr/local/jboss-5.1.0.GA/server/app/deploy/app.ear/}
| FINE [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,666][sun.rmi.loader] Log.java(212): ha-jms-queue-proces...@199aa4e:
name = "java.rmi.server.RemoteStub", codebase = "http://172.16.77.70:8083/";,
defaultLoader =
baseclassloa...@1015293{vfszip:/usr/local/jboss-5.1.0.GA/server/app/deploy/app.ear/}
| FINE [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,668][sun.rmi.loader] Log.java(212): ha-jms-queue-proces...@199aa4e:
name = "java.rmi.server.RemoteObject", codebase = "http://172.16.77.70:8083/";,
defaultLoader =
baseclassloa...@1015293{vfszip:/usr/local/jboss-5.1.0.GA/server/app/deploy/app.ear/}
| FINE [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,670][sun.rmi.client.ref] Log.java(212):
ha-jms-queue-proces...@199aa4e: get connection
| FINE [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,672][sun.rmi.transport.tcp] Log.java(212):
ha-jms-queue-proces...@199aa4e: create connection
| FINE [ha-jms-queue-proces...@199aa4e][2009-05-26
16:57:28,674][sun.rmi.tra
[jboss-user] [Installation, Configuration & DEPLOYMENT] - Re: Singleton mbean
This forum thread may be of interest to you when you do decide to upgrade. http://www.jboss.org/index.html?module=bb&op=viewtopic&t=149505&start=0 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4232310#4232310 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4232310 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration & DEPLOYMENT] - Re: Singleton mbean
Did you ever find a solution to this problem? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4232037#4232037 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4232037 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] - Re: Quartz Job unable to access deployed EJB (JBoss AS 5.01)
Yeah, I saw that jira issue and a posting
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=147180. I figured
that it was likely the same issue but was not sure.
Here is a simple example I made that runs in the server. It will be easier
than posting all the related code pertaining to the log output above. Here
goes:
QueueingEngineMessageSenderI.java
| package com.squaretrade.queueing;
|
| public interface QueueingEngineMessageSenderI {
| public void displayMessage(String message);
| }
|
QueueingEngineMessageSenderRemote.java (not really necessary for this exact
example as I could have just used the interface above as the remote reference
but displaying anyway)
| package com.squaretrade.queueing;
|
| public interface QueueingEngineMessageSenderRemote extends
QueueingEngineMessageSenderI
| {
| }
|
QueueingEngineMessageSenderImpl.java
| package com.squaretrade.queueing;
|
| import javax.ejb.Stateless;
| import javax.ejb.Remote;
| import org.apache.log4j.Logger;
|
| @Stateless
| @Remote(QueueingEngineMessageSenderRemote.class)
| public class QueueingEngineMessageSenderImpl
| implements QueueingEngineMessageSenderRemote
| {
| private static final Logger log =
| Logger.getLogger(QueueingEngineMessageSenderImpl.class);
|
| /**
| * Logs the message.
| * @param message the type of the message
| */
| public void displayMessage(String message) {
| log.info("Message: " + message);
| }
| }
|
ejb-jar.xml
|
| http://java.sun.com/xml/ns/javaee";
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
| xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
|
http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd";
| version="3.0">
|
|
|RequeueingEngineMessageSenderTestMDB
|
com.squaretrade.queueing.spec.RequeueingEngineMessageSenderTest
|Container
|
|
|
cronTrigger
|0 0/5 * * *
?
|
|
|
jobName
|
RequeueingEngineMessageSenderTest
|
|
|
|
|
|
The relevant server log output for the quartz job execution:
| 2009-05-08 12:40:00,023 DEBUG
[org.jboss.ejb3.interceptors.aop.InterceptorSequencer]
(DefaultQuartzScheduler_Worker-4) aroundInvoke [advisedMethod=public void
com.squaretrade.queueing.spec.RequeueingEngineMessageSenderTest.execute(org.quartz.JobExecutionContext)
throws org.quartz.JobExecutionException, unadvisedMethod=public void
com.squaretrade.queueing.spec.RequeueingEngineMessageSenderTest.execute(org.quartz.JobExecutionContext)
throws org.quartz.JobExecutionException, metadata=null,
targetobject=com.squaretrade.queueing.spec.requeueingenginemessagesendert...@18697cd,
arguments=[Ljava.lang.Object;@1aea098]
| 2009-05-08 12:40:00,023 INFO
[com.squaretrade.queueing.spec.RequeueingEngineMessageSenderTest]
(DefaultQuartzScheduler_Worker-4) Get initial context for ejb
| 2009-05-08 12:40:00,024 INFO
[com.squaretrade.queueing.spec.RequeueingEngineMessageSenderTest]
(DefaultQuartzScheduler_Worker-4) Look up jndi
name:batch/QueueingEngineMessageSenderImpl/remote
| 2009-05-08 12:40:00,025 DEBUG
[org.jboss.ejb3.proxy.objectfactory.ProxyObjectFactory]
(DefaultQuartzScheduler_Worker-4)
org.jboss.ejb3.proxy.objectfactory.ProxyObjectFactory servicing request for
batch/QueueingEngineMessageSenderImpl/remote
| 2009-05-08 12:40:00,031 DEBUG [org.jboss.remoting.InvokerRegistry]
(DefaultQuartzScheduler_Worker-4) removed
org.jboss.remoting.transport.local.localclientinvo...@c7732a from registry
| 2009-05-08 12:40:00,031 DEBUG
[org.jboss.ejb3.proxy.objectfactory.session.SessionProxyObjectFactory]
(DefaultQuartzScheduler_Worker-4) Created Proxy of type $Proxy345 for EJB3
Business Interface: com.squaretrade.queueing.QueueingEngineMessageSenderRemote
| 2009-05-08 12:40:00,031 ERROR
[com.squaretrade.queueing.spec.RequeueingEngineMessageSenderTest]
(DefaultQuartzScheduler_Worker-4) javax.naming.NamingException: Could not
dereference object [Root exception is java.lang.RuntimeException: Can not find
interface declared by Proxy in our CL +
baseclassloa...@1f85f8c{vfszip:/usr/local/jboss-5.0.1.GA/server/batch/deploy/quartz-ra.rar/}]
|
Other things to note:
The session bean is deployed. I verified this in two ways:
1. By looking at the jmx-console
2. By running a client program from the command line that accesses the
stateless session bean in the remote context
Here is the relevant server log output that happened when calling session
bean's remote context from a client program (command line). It shows that the
sessions bean has a remote context that is accessible to clients.
| 2009-05-08 12:43:27,161 DEB
[jboss-user] [EJB 3.0] - Quartz Job unable to access deployed EJB (JBoss AS 5.01)
I am upgrading from JBoss AS 4.05 to JBoss 5.01. The code mentioned below
works fine in JBoss 4.05.
I have a quartz job that is unable to get a remote access to a deployed EJB. I
know that the EJB is deployed because I see it in the JMX console.
Additionally, I wrote a client program that uses the same code (as is used by
the quartz job) to access the EJB remotely. The client program works fine.
It seems to be a class loader issue (where quartz is running).
Here is the relevant part of the stack trace:
| 2009-05-07 17:30:00,101 INFO [com.squaretrade.locator.Locator]
(DefaultQuartzScheduler_Worker-2) LOOKING UP SESSION:
batch/QueueingEngineMessageSenderImpl/remote
| 2009-05-07 17:30:00,101 INFO [com.squaretrade.locator.Locator]
(DefaultQuartzScheduler_Worker-2) USING PROVIDER URL FOR REMOTE CONTEXT:
jboss-batch-local-11:1100,jboss-batch-local-12:1100 2009-05-07 17:30:00,102
DEBUG [org.jboss.ejb3.proxy.objectfactory.ProxyObjectFactory]
(DefaultQuartzScheduler_Worker-2)
org.jboss.ejb3.proxy.objectfactory.ProxyObjectFactory servicing request for
batch/QueueingEngineMessageSenderImpl/remote
| 2009-05-07 17:30:00,140 DEBUG [org.jboss.remoting.InvokerRegistry]
(DefaultQuartzScheduler_Worker-2) removed
org.jboss.remoting.transport.local.localclientinvo...@1ac1a45 from registry
| 2009-05-07 17:30:00,140 DEBUG
[org.jboss.ejb3.proxy.objectfactory.session.SessionProxyObjectFactory]
(DefaultQuartzScheduler_Worker-2) Created Proxy of type $Proxy271 for EJB3
Business Interface: com.squaretrade.queueing.QueueingEngineMessageSenderRemote
| 2009-05-07 17:30:00,140 INFO [com.squaretrade.locator.Locator]
(DefaultQuartzScheduler_Worker-2) CAUGHT NAMING EXCEPTION: Could not
dereference object ATTEMPTING RETRY
| 2009-05-07 17:30:00,201 ERROR [com.squaretrade.locator.Locator]
(DefaultQuartzScheduler_Worker-2) CAUGHT NAMING EXCEPTION: Could not
dereference object FINISHED RETRYING
| 2009-05-07 17:30:00,201 ERROR
[com.squaretrade.queueing.AbstractQueueingOperation]
(DefaultQuartzScheduler_Worker-2) Exception caught in
AbstractQueueingOperation.execute when executing queueing spec:
com.squaretrade.queueing.spec.WarrantyOrderRequeueingOperation
| javax.naming.NamingException: Could not dereference object [Root exception
is java.lang.RuntimeException: Can not find interface declared by Proxy in our
CL +
baseclassloa...@16fde80{vfszip:/usr/local/jboss-5.0.1.GA/server/batch/deploy/quartz-ra.rar/}]
| at
org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1472)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:818)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:682)
| at javax.naming.InitialContext.lookup(InitialContext.java:392)
| at com.squaretrade.locator.Locator.getSession(Locator.java:196)
| at
com.squaretrade.queueing.AbstractQueueingOperation.sendMessage(AbstractQueueingOperation.java:137)
| at
com.squaretrade.queueing.AbstractQueueingOperation.execute(AbstractQueueingOperation.java:101)
| at
com.squaretrade.semaphore.quartz.AbstractSerialQuartzJob.execute(AbstractSerialQuartzJob.java:56)
| at sun.reflect.GeneratedMethodAccessor436.invoke(Unknown Source)
| at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at
org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
| at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
| at
org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
| at
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
| at
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
| at sun.reflect.GeneratedMethodAccessor435.invoke(Unknown Source)
| at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at
org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
| at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
| at
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_11445709.invoke(InvocationContextInterceptor_z_fillMethod_11445709.java)
| at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
| at
org.jboss.aop.advice.org.jboss.ejb3.intercep
[jboss-user] [Messaging, JMS & JBossMQ] - Re: MDB's activated too early
You can make the MDB depend upon that which must be deployed before the MDB is
deployed. This can be set using the @Depends class-level annotation.
For example, if there are two session beans that must be deployed prior to the
MDB then add the following annotation.
| @Depends({
|
"jboss.j2ee:ear=myEar.ear,jar=myJarFile.jar,name=MySessionBean1,service=EJB3",
|
"jboss.j2ee:ear=myEar.ear,jar=myJarFile.jar,name=MySessionBean2,service=EJB3"
| })
|
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020820#4020820
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020820
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Messaging, JMS & JBossMQ] - HAJMS with durable topic subscribers; clientID already regis
I have two clustered JMS servers running JBoss [Zion] 4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000); the servers run linux (debian). JMS data is persisted to a postgres8.1 database; each server has the same configuration (same JMS destinations; same datasource for the JMS persistence manager, etc.) and the same ear files deployed. I have a Topic with one non-durable subscriber (no client id required) and two durable topic subscribers as MDBs (durable subscribers have client ids 'myClientId' and 'anotherClientId'). I deploy the same ear file to each of the two nodes. The node that is not the master node outputs log entries (pasted below) for 'JMS provider failure'; each of the two messages indicate that the client id is already connected to the server. Now this makes sense because the master node has the same two MDBs deployed. I have read in another forum post that the JMS spec mentions that if another connection with the same clientID is already running the JMS provider should detect the duplicate ID and throw an InvalidClientIDException (I did not see this in the spec when I searched on "InvalidClientIDException" but it seems reasonable). As you can see the log entries are only WARN level entries but they continue to be logged. I have seen a forum post that says to use the "ClientMonitorInterceptor" in jbossmq-service.xml but I am not confident that this is a good solution. Has anyone else who has run into this problem found a good solution? The posts that I have seen do not provide a solution. Perhaps it is nothing of high concern. Thanks for any help. | 10:55:54,538 INFO [EJB3 MDB Create Recovery Thread][MDB] Trying to reconnect to JMS provider | 10:55:54,538 INFO [EJB3 MDB Create Recovery Thread][MDB] Reconnected to JMS provider | 10:55:54,579 INFO [EJB3 MDB Create Recovery Thread][MDB] Reconnected to JMS provider | 10:55:54,579 WARN [EJB3 MDB Create Recovery Thread][MDB] JMS provider failure detected: | javax.jms.InvalidClientIDException: This client id 'myClientId' is already registered! | at org.jboss.mq.sm.AbstractStateManager.addLoggedOnClientId(AbstractStateManager.java:196) | at org.jboss.mq.server.JMSDestinationManager.checkID(JMSDestinationManager.java:384) | at org.jboss.mq.server.JMSServerInterceptorSupport.checkID(JMSServerInterceptorSupport.java:138) | at org.jboss.mq.server.TracingInterceptor.checkID(TracingInterceptor.java:226) | at org.jboss.mq.server.JMSServerInvoker.checkID(JMSServerInvoker.java:139) | at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:120) | at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396) | at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392) | at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748) | at java.lang.Thread.run(Thread.java:595) | 10:55:54,579 INFO [EJB3 MDB Create Recovery Thread][MDB] Trying to reconnect to JMS provider | 10:56:04,577 WARN [EJB3 MDB Create Recovery Thread][MDB] JMS provider failure detected: | javax.jms.JMSSecurityException: The login id has an assigned client id 'anotherClientId', that is already connected to the server! | at org.jboss.mq.sm.AbstractStateManager.checkUser(AbstractStateManager.java:180) | at org.jboss.mq.server.JMSDestinationManager.checkUser(JMSDestinationManager.java:627) | at org.jboss.mq.server.JMSServerInterceptorSupport.checkUser(JMSServerInterceptorSupport.java:288) | at org.jboss.mq.server.TracingInterceptor.checkUser(TracingInterceptor.java:704) | at org.jboss.mq.server.JMSServerInvoker.checkUser(JMSServerInvoker.java:289) | at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:204) | at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396) | at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392) | at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748) | at java.lang.Thread.run(Thread.java:595) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968472#3968472 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968472 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Messaging, JMS & JBossMQ] - Re: Two servers assuming the role of master node (JMS)?
One other thing to note: When the server is restarted (say when node1 is restarted in Step 5) and the exceptions begin to pour out the MDBs deployed on that server (and the other one for that matter) are consuming messages. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3965386#3965386 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3965386 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Messaging, JMS & JBossMQ] - Two servers assuming the role of master node (JMS)?
I have two clustered JMS servers running JBoss [Zion] 4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000); the servers run linux (debian). JMS data is persisted to a postgres8.1 database; each server has the same configuration (same JMS destinations; same datasource for the JMS persistence manager, etc.). I have been doing some testing to verify that when the master node (node1) goes down, the other node (node2) assumes the role of master. Also testing to be sure that when node1 comes back up all still processes without problems. I have seen a bunch of exceptions that lead me to believe that both servers are trying to be master when node1 is brought back up; I am pretty sure that this is not possible (andI see that at any given moment only one has assumed the role of MasterNode when I check the HASingletonDeployer in the JMX console for each server); so I am hoping that there is a better explanation for what I am seeing. Here are the steps that I have carried out: 1. Bring up two clustered JBoss servers; each one has an identical JMS configuration; each one has the same ear file deployed 2. Start a client that continously produces messages for a Topic; messages begin to be persisted; note that the client uses HA-JNDI (it has a list of both servers) 3. There are 3 MDBs; two have durable subscriptions; one sleeps for a couple of seconds during processing 4. Kill the master node (node1) [e.g., stop the JBoss server]; other node (node2) assumes the responsibility of master; client recognizes this change and starts to connect to the new master (node2) 5. bring up node1; exceptions start to fly on node1 (none on node2); the exceptions do not stop; client sees no exceptions Here is an example of the exception(s): | 2006-08-15 17:14:13,343 ERROR [org.jboss.jms.asf.StdServerSession] failed to commit/rollback | org.jboss.tm.JBossRollbackException: Unable to commit, tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=dingle/535, BranchQual=, localId=535] status=STATUS_NO_TRANSACTION; - nested throwable: (org.jboss.mq.SpyXAException: - nested throwable: (org.jboss.mq.SpyTransactionRolledBackException: | Transaction was rolled back.; - nested throwable: (org.jboss.mq.SpyJMSException: Could not mark the message as deleted in the database: update affected 0 rows))) | at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:372) | at org.jboss.tm.TxManager.commit(TxManager.java:240) | at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:351) | at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:902) | at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170) | at org.jboss.mq.SpySession.run(SpySession.java:323) | at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:194) | at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748) | at java.lang.Thread.run(Thread.java:595) | Caused by: org.jboss.mq.SpyXAException: - nested throwable: (org.jboss.mq.SpyTransactionRolledBackException: Transaction was rolled back.; - nested throwable: (org.jboss.mq.SpyJMSException: Could not mark the message as deleted in the database: update affected 0 rows)) | at org.jboss.mq.SpyXAResource.commit(SpyXAResource.java:102) | at org.jboss.tm.TransactionImpl$Resource.commit(TransactionImpl.java:2253) | at org.jboss.tm.TransactionImpl.commitResources(TransactionImpl.java:1784) | at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:340) | ... 8 more | Caused by: org.jboss.mq.SpyTransactionRolledBackException: Transaction was rolled back.; - nested throwable: (org.jboss.mq.SpyJMSException: Could | not mark the message as deleted in the database: update affected 0 rows) | at org.jboss.mq.server.JMSDestinationManager.transact(JMSDestinationManager.java:435) | at org.jboss.mq.server.JMSServerInterceptorSupport.transact(JMSServerInterceptorSupport.java:200) | at org.jboss.mq.security.ServerSecurityInterceptor.transact(ServerSecurityInterceptor.java:197) | at org.jboss.mq.server.TracingInterceptor.transact(TracingInterceptor.java:422) | at org.jboss.mq.server.JMSServerInvoker.transact(JMSServerInvoker.java:201) | at org.jboss.mq.il.jvm.JVMServerIL.transact(JVMServerIL.java:342) | at org.jboss.mq.Connection.send(Connection.java:1110) | at org.jboss.mq.SpyXAResourceManager.commit(SpyXAResourceManager.java:164) | at org.jboss.mq.SpyXAResource.commit(SpyXAResource.java:98) | ... 11 more | Caused by: org.jboss.mq.SpyJMSException: Could not mark the message as deleted in the database: update affected 0 rows | at org.jboss.mq.pm.jdbc2.PersistenceManager.remove(PersistenceManager.java:1204) | at org.jboss.mq.server.Basi
