Topic
  • 4 replies
  • Latest Post - ‏2012-09-28T08:06:19Z by SystemAdmin
SystemAdmin
SystemAdmin
6184 Posts

Pinned topic Question regarding MQ adapters and release of output queue handles

‏2012-09-26T16:11:26Z |
Dear fellow TX developers/users,

I have been researching on the web and reading through the whole Websphere MQ adapter manual trying to find a description of when or how TX can be made to release handles on queues it was putting to, but I couldn't find the information I am looking for.
I'm hoping someone on this forum might be able to point me in the right direction.

Currently we have the requirement that we need to change some remote queues TX is putting messages on from time to time to change the destination queue on the remote queue manager.
As TX is keeping a handle on the queues once it has put some messages to it, the only way we could make the change was to restart the whole message broker the TX map was running in, so TX released the handle on the queues.
Trying to restart the execution group only, didn't release the queue handles.

Is there another way to make TX maps release handles on output queues other than restarting the whole message broker?

I'm grateful for any advice/hints on this one!

Thanks and kind regards,
Christian
Updated on 2012-09-28T08:06:19Z at 2012-09-28T08:06:19Z by SystemAdmin
  • repanzer1
    repanzer1
    114 Posts

    Re: Question regarding MQ adapters and release of output queue handles

    ‏2012-09-26T19:08:32Z  
    Ok, so your first input card is defined as a blob, but the data being passed to it is XML. And you want to use that XML for your second input card, which has the XML defined in the type tree the card is pointing to.

    Right off the bat, I'm going to ask why don't you just point your second input card to this data that you are pointing your first input card to? The only reason I can think of is, is that there is more data then the XML that the first input card reads in, and you want to take that XML embedded in there and pass it to your second input card. I really can't think of any other reason off hand. Could you explain why you don't just point the second input card to the data the first input card is pointing to?

    Regardless, you can not pass data to an input card from inside a map, you can only point your input card to the data, like a file in a directory or to a message queue or FTP site, which the map will read in when it is initiated. The only way to push data from a map to an input card is by executing the run map statement.

    When a map is initiated, the first thing it does is valiate the data the first input card is pointing to against the type tree, then does the same for the second input card, and so on for all the input cards.
    There are 10 types of people in this world. Those who understand binary and those who don't.
  • repanzer1
    repanzer1
    114 Posts

    Re: Question regarding MQ adapters and release of output queue handles

    ‏2012-09-26T20:31:31Z  
    • repanzer1
    • ‏2012-09-26T19:08:32Z
    Ok, so your first input card is defined as a blob, but the data being passed to it is XML. And you want to use that XML for your second input card, which has the XML defined in the type tree the card is pointing to.

    Right off the bat, I'm going to ask why don't you just point your second input card to this data that you are pointing your first input card to? The only reason I can think of is, is that there is more data then the XML that the first input card reads in, and you want to take that XML embedded in there and pass it to your second input card. I really can't think of any other reason off hand. Could you explain why you don't just point the second input card to the data the first input card is pointing to?

    Regardless, you can not pass data to an input card from inside a map, you can only point your input card to the data, like a file in a directory or to a message queue or FTP site, which the map will read in when it is initiated. The only way to push data from a map to an input card is by executing the run map statement.

    When a map is initiated, the first thing it does is valiate the data the first input card is pointing to against the type tree, then does the same for the second input card, and so on for all the input cards.
    There are 10 types of people in this world. Those who understand binary and those who don't.
    I replied to the wrong thread, please disregard what I said...sorry!


    There are 10 types of people in this world. Those who understand binary and those who don't.
  • csjh
    csjh
    3 Posts

    Re: Question regarding MQ adapters and release of output queue handles

    ‏2012-09-27T20:35:31Z  
    • repanzer1
    • ‏2012-09-26T20:31:31Z
    I replied to the wrong thread, please disregard what I said...sorry!


    There are 10 types of people in this world. Those who understand binary and those who don't.
    By default, WTX will keep up to 4 MQ connections open at any one time - even after mapping activity completes. After the connection is no longer used by the map, it remains in an idle (but open) state and will be re-used once a similar map is re-run. This helps to increase overall performance by preventing unnecessary MQ re-connections.

    In order to close down these idle MQ connections and any handles that they are keeping open, uncomment the IdleMQS and/or IdleMQSC setting in the dtx.ini file and set their respective value to 60 (or some other appropriate value). The "60" indicates that the MQ connection will be closed after 60 seconds of non-use. You can change that setting as your requirements dictate.
  • SystemAdmin
    SystemAdmin
    6184 Posts

    Re: Question regarding MQ adapters and release of output queue handles

    ‏2012-09-28T08:06:19Z  
    • csjh
    • ‏2012-09-27T20:35:31Z
    By default, WTX will keep up to 4 MQ connections open at any one time - even after mapping activity completes. After the connection is no longer used by the map, it remains in an idle (but open) state and will be re-used once a similar map is re-run. This helps to increase overall performance by preventing unnecessary MQ re-connections.

    In order to close down these idle MQ connections and any handles that they are keeping open, uncomment the IdleMQS and/or IdleMQSC setting in the dtx.ini file and set their respective value to 60 (or some other appropriate value). The "60" indicates that the MQ connection will be closed after 60 seconds of non-use. You can change that setting as your requirements dictate.
    Thanks,

    This sounds like the answer I was looking for!
    I'll definitely try this setting!