We are about to go production on the following configuration:
1) Two JBoss servers are in the cluster for failover purpose.
2) JBM is deployed as a singleton, so expected to run on one JBoss at a time.
3) Remote JMS clients connect through HAJNDI.
The question was raised, what if connectivity
No. We got away from using JBM recovery for number of reasons. Implemented
custom XA based solution.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4218656#4218656
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4218656
Is there a way to view the message which is stuck in indoubt tx (other then
read JBM tables)?
Understand there is no JMS standard.
The purpose is a custom recovery interface: review indoubts, commit or
rollback via XAResource.
View the original post :
I have the test case, but when I try to create JIRA bug report I can not see
any attachment link. May be I do not have permissions? I tried to contact
couple people from JIRA admin list - but did not get any response.
View the original post :
gaohoward wrote : IMO, unacknowledged messages may be sent twice. In this
case after the client reconnects, first thing it should do is a transaction
recovery.
If that is correct, what would you recommend when two clients read from the
same queue? When the first dies, the second will get the
I get the same message received twice; in both cases transaction was committed.
Here are the steps:
1) Remote client reads message in XA from the remote JBM queue (transaction
one).
2) Client dies after JBM was prepared, but before commit.
3) Client starts up, reconnects, gets the same message
OK, I will try to come up with a test case that is easy to execute. Currently I
see the issue in the distributed environment and kill TS from debugger in the
middle of two phase commit - not the test case I can send over.
BTW, do you guys have any recovery test case I can take a look at?
I agree with what you said, but it is not what happened. In my scenario there
were three delivery attempts.
1) The first one failed and was eventually rolled-back.
2) The second one committed. It happened as soon as JBM client started up after
the failure and reconnected to the remote queue
I run XA transaction which includes read from remote JBM queue and write to the
application database (non-XA driver). The steps are the following:
1) Message received and processed (application database update).
2) TM calls prepare on JBM; transaction record is created in JBM_TX table.
Remote
Can anybody comment on this, please?
I think JBM recovery code is expected to handle the remote resource restart.
To restate the problem. I have recovery configured on the JMS client, which
connects to the remote server. If I bounce (restart) the remote server, the
recovery module starts
Sorry for confusion, but I was trying to say that server which hosts that
resource was restarted, not just stopped (kill server A and then start it
again). And even after it is back, the server which runs the transaction would
keep logging the warning.
So I have both server up and running, my
Hi,
I am testing JBM XA recovery. I have two JBoss servers. Server A runs a
non-clustered queue. Server B runs a JMS listener, which connects to server A
through JCA + remote JMS provider. I added the following configuration to
server B (where TM is running) to turn the recovery on:
property
I have one JBoss server running the JBM (hosting the queues), and separate
JBoss running the application (remote JMS clients).
The clients update the application database and send / receive messages in XA
transactions. Oracle is the database.
Question is: can JBM tables reside in its own
1) Queue is deployed on the remote server.
2) My consumer is not an MDB. It is a normal JMS consumer deployed as MBean. It
gets connection to the queue through JCA adapter.
3) I control the transaction using TransactionManager interface.
4) On RuntimeException, I close all JMS objects (consumer,
I set DLQ for MyQ to MyDLQ.
The queues are defined in destinations-service.xml.
If MyDLQ is defined before MyQ, everything works fine.
But if MyDLQ is defined after MyQ, the behavior is confusing.
1) Server starts up without errors.
2) MyQ MBean shows MyDLQ as the value of DLQ attribute.
Thanks for the clarification.
I still have the following question.
Can we rely on the assumption that after the queue restart, JBM will deliver
messages strictly in the order they were sent,
even if for some of them it is redelivery?
At least that is what I see in my tests.
View the
I ran into a problem that message redelivery order depends on if the server was
restarted before redelivery or not.
This is my scenario.
I read three messages from the queue (sequentially) in separate transacted
sessions and rollback them all.
Then, if I restart the server, the messages are
The work around may be to restart the queue using MBean interface.
So when client restarts after the failure, it does EJB / MBean remote call to
restart the queue. That will restore the original message order.
Is there a better way?
View the original post :
In my scenario I always consume one big message per session (in its own XA
transaction). So the behavior described above (PrefetchSize=1) seems like
unnecessary overhead: I want to consume one message; I download two to the
client, use one; release the other.
Is there the way to tell the
Hi,
I want to turn off message buffering, so I set SlowConsumers=true on my
connection factory.
But it looks like one message gets prefetched anyway.
Here is my test:
1) There are 10 messages on the queue.
2) Session is opened.
3) Queue MBean shows MessageCount=10, DeliveringCount=0.
3)
Hi,
This is the problem: when I try to receive from the remote queue the first time
and my principal
is not in the authentication cache of the remote server, I get
JMSSecurityException.
At the same time authentication does happen. The principal shows up in the
authentication cache
and
21 matches
Mail list logo
