| Author |
Message
|
| George Carey |
 Posted: Tue May 04, 2010 4:56 pm Post subject: could as in ... could this be done |
 |
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
mvic said:
| Quote: |
| ... it's probably just cleaner and more controlled ... |
Yes, agreed probably so and probably let all active i/o complete and no new i/o start (fail if quiescing kind of thing) before termination ... my 'could' was meant to be , does it make sense that a code modification 'could' be made that would satisfy this requirement for an identifying token be available on reconnection. An enhancement in other words to the MQI.
I mean what is the qmgr's log reconciliation process doing on start up. Could not relevant log info be made available to relevant client connection agents if a connecting client had as you say some relevant identifying transaction token?
Like hey I'm client xyz and I am reconnecting and I had put message with token/transactionId 123 ... didn't have a status on that before you went away what have you got in your logs for me on the state of my cached 123 token ??? Anything, nothing??
That kind of logic ...
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed May 05, 2010 5:40 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
I believe it is safe to say that the client layer, and thus, client-bound apps, are far less robust than their server-bound equivalents.
Clearly, the client layer understands that an mqi call is/was in progress as it waited for the rc/cc to return from the svrconn - in a token or not. As the rc documentation indicates, synchronizing the client app with qmgr activity offers some interesting possibilities for not working. The rc indicates that there is confusion between the client layer and qmgr as to the current state of the mqi call.
It is overly optimistic (I tell my clients as I try to steer them away from client-bound apps) to expect that a client app will behave exactly as a server-bound app.
As with server-bound apps, it continues to be the responsibility of the well-written app to recognize (and take appropriate action) to ensure that the transaction completed successfully, to redrive the transaction if it didn't, and to recognize and manage duplicate or missing messages.
It is the responsibility of the app (client- or server-bound) to deal with all of the rc's for each mqi call. MQRC_CALL_INTERRUPTED is one of these.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bobbee |
| Posted: Wed May 05, 2010 6:12 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 546
Location: Tampa
|
I guess a good point here is that notall situations are Automatic.There may still be some'programability' that needs to be applied.A catch-all to the catch-all.
My client is going through this right now,should be fun. They are expecting the current administration view of things.............go to sleep, we will take care of everything for you. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 05, 2010 7:55 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
The APR defines the dozens (I didn't count them) of rc's that can be returned from the MQPUT call. A well-behaved application will anticipate and manage each and every one of these.
The argument that it is too costly or too time-consuming to write a well-behaved application is completely valid - until this type of problem arises.
WMQ catches the problem with a (semi-)succinct rc for the programmer. To ask IBM to fix mq so that the app does not need to deal with this or that rc is irrational.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bobbee |
| Posted: Wed May 05, 2010 9:11 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 546
Location: Tampa
|
| and being a programmer for 30+ years and now doing that on the 'dark side' I agree with 'most' of what you say. I never said the contrary. Costly, where did that come in? I experienced release features long before it was relaeased I am just slightly surprised at the current mix of out comes. Everyone I chat with onthe customer side seems to think 'bam' Autoreconnect. This does notseem to be true. I currenly have a customer who is failing over the QMGRS with the endmqm command and not the 'kill -9' It is reacting the same way. The 'call back is not being returned to. I have a demo in my hand from months ago where it is working under the same conditions. Surprise!!!! What is the difference? And here is where I am told to open a PMR. Been there done that. Just waiting now. |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu May 06, 2010 7:17 am Post subject: client connections |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
bruce2359 said:
| Quote: |
| As with server-bound apps, it continues to be the responsibility of the well-written app to recognize (and take appropriate action) to ensure that the transaction completed successfully, to redrive the transaction if it didn't, and to recognize and manage duplicate or missing messages |
This was not intended as a debate on client vs non-client connections but rather how an "automatic" reconnection capability might really be able to work.
But to add a comment on the client connection viability, I believe your bias against client connections needs to be updated. If per your quote the well-written app does as you suggest what are the negatives in using the client ?
On the other hand, one very large positive with a client connection is the ease of implementing a robust HA solution with redundant QMGR especially now with the multi-intance qmgr capability and the auto-reconnect clients of 7.0.1.
Also one of the very worst short comings of (big) MQ in general (only local gets ) are over come with client connections. Whether a queue or queues are on one or more servers clients can be easily configured robustly to put and get from them even if an application or server should fail ... no lost islands of messages if an instance of a server or app goes down.
But again that was not the original intent of my query of "could" a client be given with some enhanced MQI functionality the appropriate info to continue to reconnect without getting a 2549 rc.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding")
Last edited by George Carey on Thu May 06, 2010 7:42 am; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 06, 2010 7:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
I have no bias here. There are both positives and negatives with both client and server.
My point was that the failed connection and subsequent recovery, even at v7, is problematic.
I'd like to see the concept of an absoulute 'token' that, for the purposes of recovering a broken client connection, identifies the client platform, user, application name, application point-in-time (checkpoint) on both client and server, ... I doubt we'll see this any time soon.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu May 06, 2010 8:12 am Post subject: have no bias ? |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
No bias against clients ? I guess I was mis-interpreting your statement:
| Quote: |
| ... It is overly optimistic (I tell my clients as I try to steer them away from client-bound apps) ... |
On your absolute token concept ... a knowledge gathering inquery into the show stoppers would be an educational area where I would enjoy more enlightenment.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 06, 2010 8:46 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
From our collective experience with client applications: clients apps are generally slower and less robust (more fragile) than their server-bound equivalents. Can we agree on that?
Client apps are slower due to the influence of the network. More fragile due to the network AND the client platform hardware, o/s, environment, etc. Can we still agree?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu May 06, 2010 10:43 am Post subject: 'generally'?? |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
"generally" ???? not sure ... I would say only very specifically
clients over WANs yes (but that's not apples to apples anyway)
clients over high speed well architected and implemented LANs no ! (which is more an apples to apples performance comparison)
Networks are a far cry when properly architected, configured and implemented from what they used to be in speed/performance, dependability/robustness, etc.. In the past clear and evident advantages of local on the box connections to a server were the case but now network access/performance and robustness starts to get lost in the far often and frequently greater inefficiencies of application code implementations, or disk access performance and other non-network related dependencies.
So, at root I guess we don't agree on your premise point.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| jsware |
| Posted: Thu May 06, 2010 12:13 pm Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| bruce2359 wrote: |
| I'd like to see the concept of an absoulute 'token' that, for the purposes of recovering a broken client connection, identifies the client platform, user, application name, application point-in-time (checkpoint) on both client and server, ... I doubt we'll see this any time soon. |
I remember having a chat with an IBM labs guy about this and the gist of his problem was how long does the qmgr hang on to disconnected tokens? In the general case its always going to be n-1 and the client reconnects after n time leaving the it in doubt because the token has been discarded by the server. You can't keep it forever because a client might never reconnect and you'll fill the qmgr up with disconnected tokens.
I guess they are thinking about it, but have to consider the general case beyond our specific use-case scenarios.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 06, 2010 12:35 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
The qmgr could retain all kinds of state data about a lost client; but there are so many reasons why the client was lost, that it would be nearly impossible to re-establish a consistent session.
What if the client app abended? What if the client shell terminated? What if the box was re-booted? What if... How could the qmgr possibly be expected to allow a re-connect? How would this re-establish a UofW, for example?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu May 06, 2010 3:30 pm Post subject: max reconnect time |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
jsware wrote:
| Quote: |
| I remember having a chat with an IBM labs guy about this and the gist of his problem was how long does the qmgr hang on to disconnected tokens? |
Seems that case could easily be accommodated with something like a qmgr attribute of a maximum hold time that could be bumped up or down. And token time stamps checked to see when to toss the tokens.
IBM's client reconnection functionality for 7.0.1 is not talking about any case where the client failed ??!!! I don't think anyone would expect IBM to know how a to restart a client .
Rather I was thinking of the subset group of all failure types where only the server failed(qmgr or qmgr platform) requiring a failover to back up server and not the clients failing.
Having redundant client apps is a trivial robustness setup. But having redundant servers is not. And restrict it further to clients that are off-server clients which is where one would expect clients to be running anyway.
Having automatic reconnectable clients is a mis-nomer if they can't ... maybe a in-most-cases-automatic reconnectable clients would be more apt.
From IBM 7.0.1 doco:
| Quote: |
Automatic client reconnection
You can make your client applications reconnect automatically, without writing any additional code, by configuring a number of components.
Auto-reconnection is inline, that is, the connection is automatically restored at any point in the client application program, and the handles to open objects are all restored. |
Here is the reference url:
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzaf.doc/cs70190_.htm
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri May 07, 2010 1:32 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Rather I was thinking of the subset group of all failure types where only the server failed(qmgr or qmgr platform) requiring a failover to back up server and not the clients failing. |
Now I see... I think. You are looking for something that re-instantiates client apps to an in-flight, but now-broken connection to a restarted qmgr. Wow.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri May 07, 2010 2:11 pm Post subject: look at the demo |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Wow??
By re-instantiates do you mean reconnects ? Because that is what I mean.
Have you run the multi-instance QMGR failover demo ??
... because that is what it does ... FYI !
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
|
|
