Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.1.0.M2
    • Component/s: JMS
    • Labels:
      None

      Description

      Originally https://springpython.webfactional.com/ticket/12

      http://hjb.python-hosting.com/ is a python distribution that works with HJB
      http://hjb.berlios.de/ in order for Python apps to talk to JMS.

      Change History
      == 12/11/06 07:16:19 changed by gregturn ¶

      • milestone set to 0.2.

      == 01/13/07 09:15:25 changed by gregturn ¶

      • milestone changed from 0.2 to NA.

      This seems to depend on some J2EE components being up and running. Would prefer something that is 100% Python. Save this for a later build.

      1. jmstemplate-wmq-01.tar.bz2
        7 kB
        Dariusz Suchojad
      2. jmstemplate-wmq-02.tar.bz2
        8 kB
        Dariusz Suchojad
      3. jmstemplate-wmq-03.tar.bz2
        14 kB
        Dariusz Suchojad
      4. jmstemplate-wmq-04.tar.bz2
        15 kB
        Dariusz Suchojad
      5. jmstemplate-wmq-05.tar.bz2
        18 kB
        Dariusz Suchojad

        Activity

        Hide
        dsuch Dariusz Suchojad added a comment -

        I'm uploading the current version (05), still not finished, although there has been a lot of code added for getting the messages off the queues - e.g. it's now possible to have a long-running SimpleMessageListenerContainer (easily scalable with additional processes and/or threads) or to call directly WebsphereMQConnectionFactory.get to consume a single message (JmsTemplate doesn't reflect it yet though).

        Show
        dsuch Dariusz Suchojad added a comment - I'm uploading the current version (05), still not finished, although there has been a lot of code added for getting the messages off the queues - e.g. it's now possible to have a long-running SimpleMessageListenerContainer (easily scalable with additional processes and/or threads) or to call directly WebsphereMQConnectionFactory.get to consume a single message (JmsTemplate doesn't reflect it yet though).
        Hide
        gregturn Greg Turnquist added a comment -

        For reference docs, make sure all ids start with sectional name "jms-". For example,

        <section id="intro-jms"> should be <section id="jms-intro">

        <section id="quick-start"> should be <section id="jms-quick-start">

        etc.

        Show
        gregturn Greg Turnquist added a comment - For reference docs, make sure all ids start with sectional name "jms-". For example, <section id="intro-jms"> should be <section id="jms-intro"> <section id="quick-start"> should be <section id="jms-quick-start"> etc.
        Hide
        gregturn Greg Turnquist added a comment -

        Okay, I walked through each diff report, and then just skimmed the complete files. I finally generated the docs and looked at them. Everything is really quite good. The comments I have are tiny ones.

        1) docs: rename sidebar "intro-syntax" as "jms-intro-syntax".

        2) docs: replace "there were totaly 10,000 messages" with "there were a total of 10,000 messages".

        3) docs: on overview page, add link to JMS Messaging as a key feature.

        4) My system has python 2.4.6. I noticed that set works fine, and sets doesn't exist. What version of python 2.4 are you using? I saw your conditional test for using set inside src/springpython/jms/core.py. I just realized I haven't had to do that, and my tests are passing with python 2.4.6.

        5) Is pymqi a CPython-only library? If so, a note should be added where you introduce pymqi.

        6) In the documentation, I suggest that you comment on what exactly is included/not included. For instance you say that there are no JavaEE components running, and this can allow python-to-python messaging. Then what is physically acting as the message broker? I think its fine if you make it as a side note, so it doesn't interrupt the flow of documentation. Also, does the user have to download IBM Websphere to use this? Any licensing issues?

        7) In docs,

        XXX: Doesn't work, ignore for now

        • object: MyQueue
          str: TEST.1

        Is this still the case? Or am I looking at an old copy?

        8) Personal opinion: I would put this documentation before the plug-in section. Same goes for any other new features we develop. Right now, the plug-in stuff isn't that big and fancy. I think the JMS stuff is far more useful.

        9) In the docs, it is good that you are using the full pathname for the class. However, I think you only need to do this the first time you mention the class. After that, it sort of interrupts the flow of reading (at least for me). Also, whenever there is an obvious block of code showing the import statement for the class, again, you can skip the full canonical name of the class.

        10) In the docs, I see:

        • object: jms_template
          class: springpython.jms.core.JmsTemplate
          properties:
          factory: MyConnectionFactory

        I believe it should be:

        • object: jms_template
          class: springpython.jms.core.JmsTemplate
          properties:
          factory: {ref MyConnectionFactory}

        11) docs: "JmsTemplate may use a defualt JMS destination" <-- typo for default

        12) docs: "The same JmsInstance may be used " What is JmsInstance?

        13) I noticed that the docs say that receive() will time out after a certain amount of time. Is there any version of the API that will wait any amount of time until a message comes? Just curious.

        All in all, this looks pretty solid to me!

        Show
        gregturn Greg Turnquist added a comment - Okay, I walked through each diff report, and then just skimmed the complete files. I finally generated the docs and looked at them. Everything is really quite good. The comments I have are tiny ones. 1) docs: rename sidebar "intro-syntax" as "jms-intro-syntax". 2) docs: replace "there were totaly 10,000 messages" with "there were a total of 10,000 messages". 3) docs: on overview page, add link to JMS Messaging as a key feature. 4) My system has python 2.4.6. I noticed that set works fine, and sets doesn't exist. What version of python 2.4 are you using? I saw your conditional test for using set inside src/springpython/jms/core.py. I just realized I haven't had to do that, and my tests are passing with python 2.4.6. 5) Is pymqi a CPython-only library? If so, a note should be added where you introduce pymqi. 6) In the documentation, I suggest that you comment on what exactly is included/not included. For instance you say that there are no JavaEE components running, and this can allow python-to-python messaging. Then what is physically acting as the message broker? I think its fine if you make it as a side note, so it doesn't interrupt the flow of documentation. Also, does the user have to download IBM Websphere to use this? Any licensing issues? 7) In docs, XXX: Doesn't work, ignore for now object: MyQueue str: TEST.1 Is this still the case? Or am I looking at an old copy? 8) Personal opinion: I would put this documentation before the plug-in section. Same goes for any other new features we develop. Right now, the plug-in stuff isn't that big and fancy. I think the JMS stuff is far more useful. 9) In the docs, it is good that you are using the full pathname for the class. However, I think you only need to do this the first time you mention the class. After that, it sort of interrupts the flow of reading (at least for me). Also, whenever there is an obvious block of code showing the import statement for the class, again, you can skip the full canonical name of the class. 10) In the docs, I see: object: jms_template class: springpython.jms.core.JmsTemplate properties: factory: MyConnectionFactory I believe it should be: object: jms_template class: springpython.jms.core.JmsTemplate properties: factory: {ref MyConnectionFactory} 11) docs: "JmsTemplate may use a defualt JMS destination" <-- typo for default 12) docs: "The same JmsInstance may be used " What is JmsInstance? 13) I noticed that the docs say that receive() will time out after a certain amount of time. Is there any version of the API that will wait any amount of time until a message comes? Just curious. All in all, this looks pretty solid to me!
        Hide
        dsuch Dariusz Suchojad added a comment -

        Thanks for your comments, what do you think of it all now?

        [...]

        > 4) My system has python 2.4.6. I noticed that set works fine,
        > and sets doesn't exist. What version of python 2.4 are you using?

        Heh, I think I meant Python 2.3 which didn't have the 'set' builtin,
        removed the conditional importing now.

        > 9) In the docs, it is good that you are using the full pathname for the class.
        > However, I think you only need to do this the first time you mention the class.
        > After that, it sort of interrupts the flow of reading (at least for me).

        Yep, now I've read it, it also seem to be only distracting. I left it in some places
        though because I imagine not everyone will be reading it top to bottom.

        > 13) I noticed that the docs say that receive() will time out after
        > a certain amount of time. Is there any version of the API that will
        > wait any amount of time until a message comes? Just curious.

        Nope, I left it out on purpose. If someone really needs to specify a long
        timeout then they'll always be able to say '.receive(1000000000)' but that's not

        • at least as far as WebSphere MQ is concerned - a correct idiom for polling for
          messages; the problem with it being that it may prevent the queue manager from
          properly shutting down, especially when the client is not using the correct
          options for opening the queues. I've seen it overused on numerous occasions
          and I wouldn't want to encourage such a behaviour.

        The correct idiom is to sit in a 'while True' loop checking for messages every
        X seconds, where 'X' is usually just a couple of seconds; something along the lines
        of:

        while True:
        try:
        msg = jms_template.receive(2000)
        handle(msg)
        except NoMessageAvailableException, e:
        pass
        except JMSException,e:
        logger.log(e)
        raise e

        The trick here is, when the JMS provider will start the quiescing
        process, a new call to .receive will not succeed, an exception will be
        raised and the client will disconnect.

        Which brings us to Java Spring's SimpleMessageListenerContainer, an excellent
        design, a very nice way for receiving the messages. SMLC runs in a background
        thread/process, does the above loop and invokes the user's registerd handler
        on every new message. And that's what I'd like to work on next

        Show
        dsuch Dariusz Suchojad added a comment - Thanks for your comments, what do you think of it all now? [...] > 4) My system has python 2.4.6. I noticed that set works fine, > and sets doesn't exist. What version of python 2.4 are you using? Heh, I think I meant Python 2.3 which didn't have the 'set' builtin, removed the conditional importing now. > 9) In the docs, it is good that you are using the full pathname for the class. > However, I think you only need to do this the first time you mention the class. > After that, it sort of interrupts the flow of reading (at least for me). Yep, now I've read it, it also seem to be only distracting. I left it in some places though because I imagine not everyone will be reading it top to bottom. > 13) I noticed that the docs say that receive() will time out after > a certain amount of time. Is there any version of the API that will > wait any amount of time until a message comes? Just curious. Nope, I left it out on purpose. If someone really needs to specify a long timeout then they'll always be able to say '.receive(1000000000)' but that's not at least as far as WebSphere MQ is concerned - a correct idiom for polling for messages; the problem with it being that it may prevent the queue manager from properly shutting down, especially when the client is not using the correct options for opening the queues. I've seen it overused on numerous occasions and I wouldn't want to encourage such a behaviour. The correct idiom is to sit in a 'while True' loop checking for messages every X seconds, where 'X' is usually just a couple of seconds; something along the lines of: while True: try: msg = jms_template.receive(2000) handle(msg) except NoMessageAvailableException, e: pass except JMSException,e: logger.log(e) raise e The trick here is, when the JMS provider will start the quiescing process, a new call to .receive will not succeed, an exception will be raised and the client will disconnect. Which brings us to Java Spring's SimpleMessageListenerContainer, an excellent design, a very nice way for receiving the messages. SMLC runs in a background thread/process, does the above loop and invokes the user's registerd handler on every new message. And that's what I'd like to work on next
        Hide
        dsuch Dariusz Suchojad added a comment -

        Committed to trunk in r713. New JMS development will happen in new Jira tickets

        Show
        dsuch Dariusz Suchojad added a comment - Committed to trunk in r713. New JMS development will happen in new Jira tickets

          People

          • Assignee:
            dsuch Dariusz Suchojad
            Reporter:
            gregturn Greg Turnquist
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: