Logo 
Search:

Java Forum

Ask Question   UnAnswered
Home » Forum » Java       RSS Feeds

JMS Development Questions

  Asked By: Viveka    Date: Oct 02    Category: Java    Views: 885
  

I would like to get help in writing a tool that can dynamically create subscriptions and subscribe to different events within JMS (either type of Queue or Topic). The way I plan on enabling the dynamic part is having the connection information (port, server, topic or queue name, and topic or queue type) within a database table or properties file.
I hope to use this and allow it to continually (configurable) check the database for updates as to new events to subscribe to and create a new instance and start subscribing. The other idea would be to simply check the database upon startup and start subscribing to all the events via JMS that have been specified.
The information I retrieve I will be initially be putting into a database and then possibly using that database to display the data I have retrieved.

Any help will be great. Either examples or sites would be great.

Share: 

 

5 Answers Found

 
Answer #1    Answered By: Chung Tran     Answered On: Oct 02

I prefer a profile to keep the connectivity details; because periodic database  check/access brings excessive overhead into your system performance I would suggest the following which I think we can argue over it


If you can use a middleware component (lets call it an event handler) that reads the tunneled events  and populates them into database, and at the same time send a signal (internal event) to a coordinator which can distinguish between event types. This is a message consumer coordinator


Coordinator will then (based on the type  of event) can notify a corresponding message consumer of existence of a new event, and the MDB can then start  processing it. (Notification = pushing the event into the queue  of the MDB)

On startup  of the application, message consumer can query database for events that are already persisted and not processed (probably based on time) by interfacing with database by probably running a sql command or store procedure to read the event.

This means that message consumers are already running and subscribed, and if the traffic gets more loaded you can use some load balancers to balance the load over number of similar consumers. Of course you have MDB per event type (this is what I read from your requirements below). Because single MDB will be blocked until one of its own messages is processed, you can use some dynamic  behavior to avoid this. This would be also helpful; to avoid any failure in case an unknown event type has been received.

à Event handler à persist in DB + signaling Coordinator -> message consumer (no DB access) -> event processor

Start up:

Message consumer -> DB to collect events and process

This does not have frequent DB access which is a benefit

 
Answer #2    Answered By: Salvador Alexander     Answered On: Oct 02

Your information  is helpful, and I was wondering if you know of any examples  of how I would build the subscribe part  of my application using JMS?

 
Answer #3    Answered By: Andrew Bryant     Answered On: Oct 02

If it is a requirement that we repeatedly process events(not only at start  of application) we can create  a thread that runs at start of application and in a while loop processes events  and then goes to sleep for a while.
Hear is sodo codes:



public Class processor extends Thread{

private sleepTime = 100000;

while(true){

process events(call a stored procedure....);

sleep(sleepTime);

}

}


This thread could be started at a static block and sleepTime could be loaded from a property file.

 
Answer #4    Answered By: Becky Baker     Answered On: Oct 02

Container somhow resolves the issue with loosing events/messages in case your application goes down. If you use durable subscription model, any message that has been sent during the down time of you application will be persisted until they are processed by the subscribers. So when you app comes up, you won't loose any messages. Having said that this brings a bit of overhead due to its persistancy. For more information  I recommend you to have a look at EJB spec.

Regarding the point Reza is making, it's good but not for J2EE as this is framework internal responsibility. Although I want to argue with the idea  somehow, because there are drawbacks to it. specially the concept of predefined sleep interval. I understand that you keep the interval in a property file  so it can be modified later according to the condition, but, if the network throughput is too high or too low, you can never know what interval to specify, so I rather keep the applicaton smart enough to adapt to the network load and to be flexible.

For instance  if object A is sending message to B (B is consumer)

I go with a psuedo code as follow:


A->queueTheMessage();
A->signalB();

B::queueConsumerThread()
{
while(true) {
waitForSignalFromA();
while(there are messages in the queue){
read_Off_The_Queue();
process_Message();
}
} // considering the proper lock and unlock stuff (out of scope)


Important note: The above sample does NOT apply to J2EE as container takes care of everything completely transparent of MDB so you shouldn't be worry about such implementation.

To answer the question as how to do the subscription, You can find loads of examples  in JMS tutorial and java.sun.com

 
Answer #5    Answered By: Stacie Martin     Answered On: Oct 02

while loop should be in run method of thread!

 
Didn't find what you were looking for? Find more on JMS Development Questions Or get search suggestion and latest updates.




Tagged: