gefira blog

I’ve noticed quite a few people hitting this blog and looking for keywords along the lines of “pymqi read a message and leave on queue” so I thought it should be explained. The thing you’re looking for is called message browsing and this post will show it in action.

Before I get into details though, I’d like to ask you for contacting me if there’s anything I can do regarding the documentation and usage examples. Really, it’s open-source so both the code and docs should shine but I’ll never know what to improve next if you don’t tell me it first Checking the referrers is of course important but it won’t help much if you shun sending me your suggestions. Thanks!

So, the code is below.  The trick is composed of two parts that sort of resemble using cursors in SQL databases:

• The queue needs to be open for browsing using the CMQC.MQOO_BROWSE option,
• When calling queue.get, you need to pass it a proper CMQC.MQGMO_BROWSE_* option, in our simple case, there’s only one message on the queue and it just so happens that right after opening the queue for browsing, the logical cursor used for browsing is placed before the first message so we can use CMQC.MQGMO_BROWSE_NEXT and it will browse the next message which happens to be the first and the only one on the queue.

The code has been written in a form of a test case in the hope that it will make it clear that msg1 and msg2 are really equal to self.expected_msg, which is a UUID4 so we know it’s a different message on each test invocation.

I think that would be it as far as explaining the concept goes and again, don’t hesitate to contact me if you’d like me to expand on it or maybe cover something entirely else.

# stdlib
import unittest, uuid
 
# PyMQI
import CMQC, pymqi
 
queue_manager = "QM01"
channel = "SVRCONN.1"
host = "192.168.1.139"
port = "1434"
queue_name = "TEST.1"
conn_info = "%s(%s)" % (host, port)
 
class BrowsingTestCase(unittest.TestCase):
    def setUp(self):
        self.expected_msg = uuid.uuid4().hex
        self.qmgr = pymqi.QueueManager(None)
        self.qmgr.connectTCPClient(queue_manager, pymqi.cd(), channel, conn_info)
 
        self.put_queue = pymqi.Queue(self.qmgr, queue_name)
        self.put_queue.put(self.expected_msg)
        self.put_queue.close()
 
        browse_options = CMQC.MQOO_BROWSE
        self.browse_queue = pymqi.Queue(self.qmgr, queue_name,  browse_options)
        self.get_queue = pymqi.Queue(self.qmgr, queue_name)
 
    def tearDown(self):
        # Clear the queue and close all objects.
        try:
            while True:
                self.get_queue.get()
        except pymqi.MQMIError, e:
            if e.comp != CMQC.MQCC_FAILED and e.reason != CMQC.MQRC_NO_MSG_AVAILABLE:
                raise
 
        self.browse_queue.close()
        self.get_queue.close()
        self.qmgr.disconnect()
 
    def test_message_browsing(self):
 
        md = pymqi.md()
        gmo = pymqi.gmo()
        gmo.Options = CMQC.MQGMO_BROWSE_NEXT
 
        msg1 = self.browse_queue.get(None, md, gmo)
        self.assertEquals(msg1, self.expected_msg)
 
        msg2 = self.get_queue.get()
        self.assertEquals(msg2, self.expected_msg)

Spring Python 1.2 has been released some time ago and one of its newest features is the support for wrapping XML-RPC with SSL/TLS, including both clients and servers. I’ve covered it already in a tutorial some time ago but I don’t think Planet Python was picking up the blog’s posts at that time, besides, Spring Python was still a release candidate when I was writing it so things could’ve changed (but they didn’t ). In any case, now that 1.2 is a stable release, I thought I’d just mention it in case you were looking for means to secure your XML-RPC traffic. Here’s the reference material and the tutorial is here.

So I’ve just spent three hours on trying to install the WebSphere Message Broker 7.0 (CZ4VEML) on Ubuntu 10.10 and it seems the current state of the affairs is really sorry. Had the installer been a normal set of DEBs or RPMs, I would’ve had no problems with it, but instead IBM had chosen to make it a Java, an Eclipse-based, one. Sorry guys, but being written in Java doesn’t help at all, why should it. Besides, maybe users don’t mind having to install dozens of JREs and Eclipse instances but people certainly do mind it.

So what went wrong anyway? Frankly, I don’t know. I’ve prepared everything on MQ side, created the necessary users and groups and then run the installer using the -console switch (again, the convention for long options is to use –console, that’s two dashes). It went just fine, stopped at 100%, said it was a pleasure to be executed (OK, not that exactly ) and I thought that was all.

Well, not really.

After typing “mqsicreatebroker MB01 -q QM01″ I was greeted with a “BIP8011E: Unable to create the components configuration data.” error and its oh-so-helpful explanation “Ensure that the userid that is running this command has adequate authority to update the configuration or registry files.” That’s a designing user interfaces 101 guys, really. How can you possibly mention any configuration and registry files in error messages if the very concept hasn’t been defined anywhere in the documentation? How am I supposed to know what files you are talking about?! About the only registry that springs to mind is stuff you modify through the mqsichangeproperties command, but I have no idea if that’s what the author had in mind. I can – though I’d rather didn’t – pretend I didn’t see that in the installation guide you say “SELinux is not supported” (how is that making the planet a safer place) but on seeing such an error all I can do is to chmod 777 the whole system and hope it’s going to help.

After a while it turned out there was a guy who had the same problem some time ago and indeed, when I took a look at /var/mqsi it looked a bit strangely, like if the installer forgot to install half of the stuff it was supposed to put there.

So being an adult, what I did next was to have a look at that installer thing, the one written in Eclipse. I unzipped the setup.jar and saw a bunch of MD5 hashes of names pointing to who-knows-where on the file system. Each of the files had a 78 9C header so it was obvious these were the missing files, compressed with zlib. I unpacked one of them and it seemed fine, if only I’d known where they were to go, which one belonged to /var/mqsi! Just compare it with the wealth of information regarding normal package formats.

OK, so I thought maybe I could somehow put the damn thing into a debug mode so that it started logging what it was really doing. Amazingly, there was a wizard.xml file which contained interesting entries like “eventsLogged”, “logEchoedToScreen” or “optionalLogOutput” – ah, and while we’re at it, please don’t invent your own logging levels, my heart cringes when I see things like “wrn”, what is it, are we running out of vowels? How do you expect me to use a debug level? Should it be “dbg”, “dbug” or what? So anyway, I modified the file according to my best telepathic skills hoping it would be the right incantation and I would finally see why the files weren’t being installed but then when I started the installer I hit upon a “The wizard cannot continue because of the following error: wizard file has changed since it was created” message which was the last straw I’ve had enough at that point, here I am trying some obscure magick just to install this software but no, I’m not even supposed to peek under the covers because of what, really? Has any of you, authors, even bothered to ask the question of what you’re hiding and from whom?

So that’s how it looks like right now. I’m sure in some time the situation will change – and I honestly would like to help you out with it but I’m merely a user so what do I know, I can only wait for a miracle, but when it has I’ll be sure to blog about how to install the Message Broker on Ubuntu – it’s just it’s nothing to be proud of as of today. Too bad it couldn’t have gone as smoothly as with the WebSphere MQ installation which I covered some time ago.