Justin,
thanks again for the additional explanation (always interested in the how and why).
 
<soapboxOn>
I still think the whole point of having channels is to deal with network failures and whatever can go wrong in between,
channels in itself should be intelligent enough so they can handle recovery by themselves.
In practice this is often not the case and you need all kinds of tools to detect a failure and sometimes only a simple 
push of a button to restart is enough, why couldn't the channel figure this out by itself???
<soapboxOff> 
 
I like MQ, but sometimes feel it is unneccessary complicated...
 
Michael  

-----Original Message-----
From: Justin Fries [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 31, 2003 4:09 PM
To: [EMAIL PROTECTED]
Subject: Re: inet2 vs MQ listener (UNIX) - Answered


Michael,

        Channel parameters like DISCINT, HBINT, KAINT, etc. are intended to work around problems with networks, which will always be with us (unless someone invents a perfect network that never fails--if so, let me in on your IPO).  If you're running MQ 5.2, you should find the 5.3 listener more stable since it has much less work to do--just listen() on a socket, accept() a connection, and give it to amqrmppa to handle.  Which version of MQ are you running?

        You can set up runmqlsr to run out of inittab with the 'respawn' option.  This would restart it in the way you desire (although I would still call service if you find it terminating for any reason).  Just edit /etc/inittab and run 'telinit q' to force init to reread the file.  One downside is that you will need root authority to stop the listener, unless you just turn off its execute bits (although I'm not sure how init will react to that).

        Cheers,

       Justin T. Fries
       WebSphere MQ Support
       Raleigh, North Carolina
       Email: [EMAIL PROTECTED]



[EMAIL PROTECTED]
Sent by: MQSeries List <[EMAIL PROTECTED]>

07/31/2003 09:23 AM
Please respond to MQSeries List

       
        To:        [EMAIL PROTECTED]
        cc:        
        Subject:        Re: inet2 vs MQ listener (UNIX) - Answered



Justin,
I agree and we do call IBM and we did, unfortunately one problem fixed, 10 lurking around waiting to pop-up, inetd has proven to be more stable for us. Same goes for channels (which I consider one of the key things of MQ) problems, why have things like DISCINT, HBINT or KAINT, when everything works as it is supposed to?
 
Michael  
-----Original Message-----
From:
Justin Fries [mailto:[EMAIL PROTECTED]
Sent:
Thursday, July 31, 2003 2:49 PM
To:
[EMAIL PROTECTED]
Subject:
Re: inet2 vs MQ listener (UNIX) - Answered


Michael,


       The listener shouldn't die, period.  I don't think MQ should restart dead processes in the way you suggest since that just papers over a larger problem.  (One exception is amqzlwa0 which runs the optional custom-written cluster workload exit--because it runs untrusted code, MQ wll restart it if necessary.)  If you do see your listener dying, call it in.


       Regards,


      Justin T. Fries
      WebSphere MQ Support
      Raleigh, North Carolina
      Email: [EMAIL PROTECTED]



-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------

Reply via email to