[jboss-user] [JBoss Messaging] - What if singleton JBM starts on two servers?

2009-03-25 Thread szhigunov
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

[jboss-user] [JBoss Messaging] - Re: MessagingXAResourceRecovery can not reconnect

2009-03-17 Thread szhigunov
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

[jboss-user] [JBoss Messaging] - View message stuck in indoubt tx

2008-11-06 Thread szhigunov
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 :

[jboss-user] [JBoss Messaging] - Re: Message is redelivered while the original transaction is

2008-11-05 Thread szhigunov
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 :

[jboss-user] [JBoss Messaging] - Re: Message is redelivered while the original transaction is

2008-10-29 Thread szhigunov
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

[jboss-user] [JBoss Messaging] - Message is redelivered while the original transaction is sti

2008-10-28 Thread szhigunov
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

[jboss-user] [JBoss Messaging] - Re: Message is redelivered while the original transaction is

2008-10-28 Thread szhigunov
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?

[jboss-user] [JBoss Messaging] - Re: Duplicate message after recovery rollback

2008-10-21 Thread szhigunov
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

[jboss-user] [JBoss Messaging] - Duplicate message after recovery rollback

2008-10-20 Thread szhigunov
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

[jboss-user] [JBoss Messaging] - Re: MessagingXAResourceRecovery can not reconnect

2008-10-14 Thread szhigunov
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

[jboss-user] [JBoss Messaging] - Re: MessagingXAResourceRecovery can not reconnect

2008-10-09 Thread szhigunov
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

[jboss-user] [JBoss Messaging] - MessagingXAResourceRecovery can not reconnect

2008-10-08 Thread szhigunov
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

[jboss-user] [JBoss Messaging] - Can JBM server share an Oracle database with the application

2008-07-16 Thread szhigunov
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

[jboss-user] [JBoss Messaging] - Re: Redelivery order

2008-06-16 Thread szhigunov
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,

[jboss-user] [JBoss Messaging] - DLQ override depends on the queues definition order.

2008-06-14 Thread szhigunov
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.

[jboss-user] [JBoss Messaging] - Re: Redelivery order

2008-06-11 Thread szhigunov
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

[jboss-user] [JBoss Messaging] - Redelivery order

2008-06-10 Thread szhigunov
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

[jboss-user] [JBoss Messaging] - Re: Redelivery order

2008-06-10 Thread szhigunov
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 :

[jboss-user] [JBoss Messaging] - Re: Does SlowConsumers flag work correctly?

2008-06-05 Thread szhigunov
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

[jboss-user] [JBoss Messaging] - Does SlowConsumers flag work correctly?

2008-06-04 Thread szhigunov
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)

[jboss-user] [JBoss Messaging] - JMS authentication problem

2008-05-23 Thread szhigunov
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