WSTC 2007 – broker and Java

I missed part of Peter Crocker’s session on Advanced Java Topics in WMB v6 yesterday, but when I did manage to get in there, I learned a few useful snippets. Essentially this was an update of his talk from last year, and riffed off of his developerWorks article on the use of Java in Message Broker.

A few of the notes I made:

  • although the product ships a sample JavaCompute node that calls a Google API, Google themselves have now withdrawn the API, so the sample doesn’t work 🙁
  • it is important to be careful with the use of XPath… for example, try to avoid using the // selector as it is usually not the most performant way to select a message element. There should be some articles around on XPath, I need to look up some useful references.
  • The latest fixpack enables Java code in a JavaCompute node to propagate to a label in the flow.

Useful stuff to be aware of!

12 thoughts on “WSTC 2007 – broker and Java”

  1. I’m considering whether to out the mysterious Wibble-man… he is incorrect. Riffed is a word, and I meant it.

    Shakespeare was considered a genius for his use of the English language. All I can say is that I’m clearly misunderstood.

  2. All this fuss over the word “riffed” while the non-word “performant” is right in the middle there.

    Actually, that’s not true – “performant” is a noun, but it seems to be increasingly used as an adjective when the word “efficient” would fit the bill appositely.

  3. Hullo to all,
    I’m pretty new to this place, and I couldn’t find a relevant thread to post this so ended up doing so over here:

    I’ve Windows 7 Ultimate running in my PC and have installed MQ 7.0.1
    Also I’ve installed VMware Workstation, I’ve installed Windows 2008 Server on the same.

    Now, both the host and the Virtual machine are pingable to each other: Below is the list of Objects defined and used on both

    Host Ip: 192.168.1.20
    Queue Manager: Reaper
    Xmitq: qt
    remote queue: QR (pointing to QL on QM: THUNDERBOLT)
    Sender Channel : CHL.TB, chltype: SDR, TRPTYPE: TCP, Connanme: 192.168.1.2(2000)

    VIrtual Machine Ip: 192.168.1.2
    Queue manager: Thunderbolt
    Local Queue: QL
    receiving channel: CHL.TB, chltype: rcvr
    Listener: LST IP addr: 198.162.1.2 Port : 2000

    So far so good, the sender channel when started enters the Binding state first and then goes ahead and enters retrying state. (Alas)
    And the receiving channel never changes from it’s inactive state.
    The Listener is always active and running.

    Can you help me with this?

    1. First of all, this is a pretty terrible place to ask that question – you could have tried mqseries.net or Stack Overflow instead.

      The first things I would check are that your listener is on port 2000 (default is 1414), and then that you don’t have Windows firewalls in the way.

      Other than that, I’d raise a support ticket with IBM.

      1. I had tried with the default port value of 1414, to no avail.
        Hence tried different Port number (2000).
        And offcourse the firewall has been disabled (test stage)
        I presumed while the usage of VMware we need to have some more things to be taken care of which you might be aware.
        I guess I will tweak some more before I land up with IBM….

        Thanks for the suggestion

Leave a Reply