Rickard �berg wrote:
> I'm confused by this. Can you please explain to me what is so bad with
> using JMS to solve this?
It's more code and has the potential for more things to go wrong than
the equivalent (prohibited) thread-based scenario.
I grant you that if the tasks are going to take lots of time then JMS is
certainly the way to go. But for lightweight parallelism JMS is
overkill, IMHO.
Specific comments below.
> Here's some pseudocode I would use to do it (shamelessly copied from Don
> Fergusons/BEA session at their User Conference. Thanks Don!):
> InitialContext ctx = new InitialContext(env);
>
> Topic topic = (Topic) ctx.lookup("sometopic");
> TopicConnectionFactory connectionFactory =
> (TopicConnectionFactory)
> ctx.lookup("javax.jms.TopicConnectionFactory");
>
> TopicConnection connection =
> connectionFactory.createTopicConnection();
> TopicSession session = connection.createTopicSession(false,
> Session.AUTO_ACKNOWLEDGE);
> TopicPublisher publisher = session.createPublisher(topic);
>
> TextMessage message = session.createTextMessage();
> message.setText(?hello world?);
> publisher.publish(message);
>
> publisher.close();
> // Message sent; wait for response
> TopicSubscriber subscriber = session.createSubscriber(topic);
> connection.start();
>
> Message m = subscriber.receive();
>
> subscriber.close();
> session.close();
> connection.close();
> -----
> That wasn't so bad, was it?
Compared to:
Runnable r = new SomeRunnable(); // thing taht does work
Thread t = new Thread(r);
t.start();
t.join();
// go retrieve results from where SomeRunnable put them
Note that if t dies for some reason then the join call returns
immediately. Different things happen with messaging systems (I'm
familiar with ActiveWorks, not JMS in particular, but they're the same
sort of beast). Let's consider these two lines from your example:
TopicSubscriber subscriber = session.createSubscriber(topic);
connection.start();
Message m = subscriber.receive(); // !!!
Depending on your JMS implementation, subscriber.receive() could block
forever. If the publisher of the message that you are subscribing to
never comes online, then you have no way of knowing the status of the
publisher, and hence have no way of receiving a message he puts out.
Consequently you may block on subscriber.receive() for a very, very,
very long time.
With Thread.join() (again, I'm only arguing for its usefulness in
lightweight, quick tasks) you have no such issues.
> Now, you've gotta explain to me what's so bad with the above, 'cause I
> aint getting it.
Reliability and predictability in lightweight tasks.
(Again, I have no quibble with you when it comes to longish
workflow-like tasks, where "longish" is highly subjective but can be
taken to mean, oh, let's say, greater than 10 seconds for the sake of
this discussion. Using threads for longish workflow tasks is bad
because you can lose state if something goes wrong. But for quickies
:-) threads seem to be easier to use. That's all.)
Cheers,
Laird
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
