| Author |
Message
|
| balareddy |
 Posted: Mon Jan 08, 2007 2:40 am Post subject: JMS Session timeout |
 |
|
Acolyte
Joined: 06 Feb 2006
Posts: 54
|
Hello All,
Is there any timeout is Transacted JMS session???
I am using standalone JMS API with Java program to connect WebsphereMQ . I am using Treansacted JMS. Once transaction begins, to commit transaction is there time??
I mean i am starting transaction, getting message from one MQ Queue and putting wait for some hours and sending message to other MQ queue and committing transaction. My problem is, if i keep transaction on Hold for some hourse, message is getting backedout. some other thread is taking tht message.
Until JMS session commit or rollback, message should be with that session only right?? I am not doing any rollback in my application.
_________________
bala |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Jan 08, 2007 2:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I can not imagine a good design that has a transaction that stays open for several hours.
Why do you need to keep it open for so long?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| balareddy |
| Posted: Mon Jan 08, 2007 3:13 am Post subject: |
|
|
Acolyte
Joined: 06 Feb 2006
Posts: 54
|
| jefflowrey wrote: |
I can not imagine a good design that has a transaction that stays open for several hours.
Why do you need to keep it open for so long? |
Good question!!!!
I will explain my application scenario. My application has more number of threads communicating to some other server with FTP session . For some reason on remote server's FTP component, my application is not getting response sometimes. my Java thread just hangs forever till it get response. While hanging, some other thread is getting same message from Queue.
Here sometimes FTP session is getting response from remote server after 2 or 3 hours. After that i am committing JMS session. But before this time some othere thread is processing the same message.
1) If Thread hangs, before JMS session commit, how come other thread is getting same message from Queue. (how the message is getting rolledback??)
_________________
bala |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 08, 2007 4:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay.... that's actually a good reason to keep a transaction open for a while.
It hadn't occured to me that someone would perform queue->FTP without queue->File first.
There are a large number of factors that determine the JMSSession timeout - most of them are in the app server configuration. Some of them have to do with MQ log space, too. An app server will automatically roll back open transactions that have been sitting around for a while, in order to help protect the server from badly written applications.
You should examine the app server's log file to find out if it is automatically terminating and rolling back the transaction for you, because of timeout.
You should also consider putting a timeout on your FTP session, with some reasonable guesses as to how long it should take to transfer the particular message. Then if it's taking 3 hours to process a 5 minute file, you won't wait 3 hours to find out.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| balareddy |
| Posted: Mon Jan 08, 2007 8:51 am Post subject: |
|
|
Acolyte
Joined: 06 Feb 2006
Posts: 54
|
| jefflowrey wrote: |
You should examine the app server's log file to find out if it is automatically terminating and rolling back the transaction for you, because of timeout.
|
Well, I am not using any Application server. Instead it is just an Java standalone program running as unix process in AIX machine with multiple threads running in a loop infinately(getting msg from Q and sending that to another server with FTP).
As for FTP timeout, I am using PASV socket programming (Socket sk = new Socket(hostName, hostControlPort, localAddress, localControlPort) and getting data with getInputStream().)
how do i specify FTP timeout in this scenario??
_________________
bala |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 08, 2007 9:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You're not using an app server..?
I'm not sure you're really getting a transacted JMS session then...
But on the other hand, your session shouldn't necessarily time out then.
There should be a timeout value on Socket somewhere.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 08, 2007 7:15 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Is there a specific reason not to use a java client to remotely dequeue the message and write it to the file system locally. This way you suppress the FTP process....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| balareddy |
| Posted: Tue Jan 09, 2007 3:29 am Post subject: |
|
|
Acolyte
Joined: 06 Feb 2006
Posts: 54
|
I am not dequeing message thru Java remotely. i am dequeing msg from local and sending that msg to Remote server thru FTP PASV socket.
IF we use JMS with Transacted session thru Java, JMS transaction will work fine.
But the other hand, to test tiemout with jms session, i tried keeping sleep for some hrs inside java thread in multi threaded program. other thread is not at all picking this msg even i put sleep for days.. so, i can say there is no timeout in jms session.
But only in FTP socket hang scenario, jms message is getting rolledback somehow...
_________________
bala |
|
| Back to top |
|
|
| balareddy |
| Posted: Tue Jan 09, 2007 3:31 am Post subject: |
|
|
Acolyte
Joined: 06 Feb 2006
Posts: 54
|
| jefflowrey wrote: |
You're not using an app server..?
There should be a timeout value on Socket somewhere. |
I am not using any App server. it is just standalone java application.
_________________
bala |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jan 09, 2007 3:53 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And I repeat my question:
Why dequeue on the machine you are dequeuing from?
Dequeue with a client connection on the machine you need to write the file to.
This will suppress the need to FTP it there.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 09, 2007 4:15 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
FJ - maybe the remote machine doesn't belong to the company that balareddy works for. Perhaps this is a b2b filte transfer solution...
balareddy - are you able to build a test setup that will reliably hang the FTP transfer? If not... you're going to have a very hard time debugging this.
If you can, then turn on MQ trace, start your program, and hang the FTP session. Then wait until the transaction is rolled back and stop the tracing. Then look at the trace output and see what it says.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jan 09, 2007 4:29 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
| FJ - maybe the remote machine doesn't belong to the company that balareddy works for. Perhaps this is a b2b filte transfer solution... |
That's why there is ssl and client channels.
| jefflowrey wrote: |
balareddy - are you able to build a test setup that will reliably hang the FTP transfer? If not... you're going to have a very hard time debugging this.
If you can, then turn on MQ trace, start your program, and hang the FTP session. Then wait until the transaction is rolled back and stop the tracing. Then look at the trace output and see what it says. |
In any case not a good solutions. Depending on the volume going through the logs the transaction can be rolled back at any time to free log space. This gets written to the AMQ00001.LOG in the errors directory of the qmgr.
As you have no control over the volume of messages passing through the qmgr while waiting you are SOL with a solution like this.
If you have to do FTP I suggest you dequeue locally to the file system and FTP the local file. You can keep the connection to the qmgr open and wait your 3 hours to dequeue the next message (to a local file). Now the MQ transaction only spans from message to local file and would not get rolled back as it never waits for 3 hours...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 09, 2007 4:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
FJ - maybe the receiver partner doesn't want to use MQ...
Otherwise, yes... leaving a transaction in MQ running this long is a challenge and is hard on the system. If I were to do something like this, I would put this particular process on it's own queue manager with it's own logs that had been tuned and designed to handle the workload.
And I've done queue->file->ftp before, and it's worked reasonably well. But then you have to implement a host of file processing logic to replicate the transactional behavior of MQ in a non-transactional file system. And the FTP itself was being handled by a commercial file transfer product (that didn't have an MQ interface), and had a lot of retry and timeout logic and audit trails and etc.
It's not an inherently bad approach to skip the file processing stuff. The WBI FTP Adapter does it, after all.
I started off saying that leaving a transaction open this long was almost certainly not necessary - but this is a reasonable approach to a difficult problem.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jan 09, 2007 4:46 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The problem I have with FTP is that I have seen it give an "OK" return code to the sender side (meaning all bytes were sent) but on the receiving side not have the full file... So unless you add some controls to the file (like header / footer record with total records, total $$ amount etc...) you are exposing yourself to some risk...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 09, 2007 4:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm not disagreeing with you that FTP is not the most reliable protocol for exchanging business data. It's one reason that message replay is an important aspect to enterprise file transfer...
I'm just saying that working with business partners is always a process of compromise, usually along the lines of the business relationship that exists (vendor, partner, competitor, reseller, supplier, etc). And therefore it's possible that balareddy is trying to implement a technical solution under business constraints...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
