3 Replies Latest reply on Apr 2, 2009 6:13 AM by gaohoward

    Some more comments on examples so far

    timfox

      1) TopicSelector - please follow naming convention everyone else is using.

      No need to use durable subscriptions here, we already have a durable subscription test.

      Also when consuming messages print out the value of user id.

      It's not clear from this example that only matching messages are selected. That's the point of the example, and it's not really mentioned at all.

      There's no real explanation here of what the example is doing or why people would want to use selectors.

      2) Request reply example

      Best to create all the objects at the beginng otherwise it seems you're creating them on each message which would be anti-pattern.

      Again, also there's no real explanation of what request-response is or why you'd want to do it.

      3) Temporary queue example. Again, this example is not demonstrating anything relevant about temporary queues.

      It's just sending a message to a queue, it could be any queue. It doesn't demonstrate deleting temp queues and it doesn't demonstrate scoping of temp queues (to connection).

      The readme doesn't really have any useful information either.

      4) TransactionalExample. Again (like I mentioned yesterday) this is not demonstrating anything really to do with transactions. It's just sending and consuming a message.

      5) QueueRequestor example - no explanation of what the example is supposed to demonstrate.

      Guys - you're all thinking too much like developers here! ;)





        • 1. Re: Some more comments on examples so far
          gaohoward

          Ok, I need another round of refactoring the readmes and code. I hate to do it again but Tim's points are right (and of high expectation as always). :)

          • 2. Re: Some more comments on examples so far
            timfox

            Another comment on the request-reply example-

            I don't think this is very clear still. It would be better to handle the request and send back the response using a message listener, then you can send and consume several messages without having to do everything on the same thread.

            Also setting the JMSCorrelationID when sending the request doesn't make sense to me. It only needs to be set when sending the response back.

            • 3. Re: Some more comments on examples so far
              gaohoward

               

              I don't think this is very clear still. It would be better to handle the request and send back the response using a message listener, then you can send and consume several messages without having to do everything on the same thread.


              Agree, using a message listener is more meaningful.

              Also setting the JMSCorrelationID when sending the request doesn't make sense to me. It only needs to be set when sending the response back.


              Yes the ID is used to indicate which message the reply messages is for which request message. If not set it will be null.