| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| syncpoint question |
« View previous topic :: View next topic » |
| Author |
Message
|
| JasonE |
 Posted: Tue Oct 05, 2004 3:50 am Post subject: |
 |
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Oct 05, 2004 4:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kirani wrote: |
| Well, MTS can act as a Transaction Coordinator. In his case MQ and SQL Server DB will act as Resource managers within the same transaction. |
Yeah, but only with the Extended Transactional Client, not with the regular client.
And the ETC didn't used to support MTS, although apparently that changed today.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JasonE |
| Posted: Tue Oct 05, 2004 5:05 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Not quite today, but recently - I just hope it works 
(And yes, I did clarify it was the transaction client) |
|
| Back to top |
|
|
| AKoerner |
| Posted: Tue Oct 12, 2004 2:59 am Post subject: |
|
|
Newbie
Joined: 11 Oct 2004
Posts: 3
Location: Duisburg, Germany
|
| bower5932 wrote: |
| If your app happens to be client connected, you may need to wait for the agent that is running on the qmgr to time out before the message becomes available. However, this is simply timing. The message isn't lost. |
How can I configure the timeout behaviour of that agent?
Maybe that will solve our problems described in
http://www.mqseries.net/phpBB2/viewtopic.php?t=18195 |
|
| Back to top |
|
|
| JasonE |
| Posted: Tue Oct 12, 2004 3:07 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
hbint and keepalive
hbint - impacts the max time the client side will ever go into a receive for an API response before timing out. If you are not in an API call, this wont help.
keepalive - If enabled, how long before the o/s checks the other end of the socket is still alive. The problem is you only determine socket problems when you flow data down a socket (ie a send), so the server will sit in a recv call and not be told if the other side has died until keepalive pops. You need to enable it, and then it defaults to 2 hours on most operating systems. After 2 hours, a dummy packet is sent along the tcpip link by the o/s and if that fails, the socket is closed and the waiting receiver can then clean up |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
