• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

Help with JMS solutions

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,
I am trying to find a solution for a problem I have. My application is initially setup with a Topic where all my agents and users can post messages where everyone receives those msgs. Now my agents and users have to added/removed dynamically, meaning I want to be able to make them dynamic durable subscribers/publishers. I want to be able to create a queue between an agent and a user for private communication "on-the-fly" when an agent wants to communicate to a user in private and vice-versa. Also would be nice to have the feature of sending offline messages from/to either of them (I know this is what durable subscribers does) but not sure how to create on the fly persistent queue connections on JMS server and let the subscribers/publishers connect to this queue. I could later delete the queues if I wanted to, but would like to be persistent queues which should not die after my connection is lost. This is what I thought of, but if you guys think of any alternate solutions, please share with me..

I always wondered how IM systems like yahoo messenger works if one were to create a similar system using JMS with offline messaging, 1 to 1 and group messaging capabilities.

TIA
GS
 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As you use JMS, you can simply create persistent queues in your application server. However, I didn't get if you want to create them on the fly or not. You can simple deploy them at run time and assign a specific name.



And about the naming problem in a sense that your agent does not know about the specific name of the queue that it should subscribe to, I would use a wrapper class for my message migration to enforces a naming convention in my system. It means that upon having certain criteria, the name can be easily guessable. It would be an easier job if you're using persistent queue.
 
Jay Shaw
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, I need to be able to create queues on the fly, meaning when either a "user" join my application, i should be able to create a queue for him in case the user wants to initiate a private conversation with an "agent". Once he initiates the private conversation with an agent, I can subscribe that agent to that queue and they both can continue conversing.
So your solutions seems interesting, but I thought JMS api only lets you create temporary queues which caanot be deployed on JMS server at runtime and which expire once the session ends. Can you elaborate a bit on your suggestion or any sample code would really help. Also I was a bit confused with your discussion with "naming", wasn't sure if you are talking about JNDI naming for those newly created queues..

Thank you for your time
GS
 
Amir Pourteymour
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No you can create persistent queue as well. You just deploy it at runtime.

For the naming issue, I don't have any code right now, but what I suggest you is to prepare a naming convention. This can be applied by a wrapper class. It means that you have certain criteria in your application e.g. user location, and etc.. You can check them at very beginning, and based on that create a queue for each of them. An agent on the other side has minimum knowledge about the new user, so it can guess the name of the queue. However, you can lookup your newly created queue at anytime to see if it's new or not.

I don't know if for such a chat room application, it's efficient to create a queue per user. It is interesting to discuss it more in detail.
 
Jay Shaw
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Amir,
pardon my ignorance, but when you said persistent queues and deploy them runtime, won't these queues expire once I recycle the server for some reason. How do I deal with such situation? Also, I am not trying to build a chat application, this is for a user interactive forum kind of application. we can take this offline if you are interested to know more about what I am trying to achieve. Let me know your email address and I can send you a detail description. Maybe this will help give you a clear picture.

Thanks
 
Amir Pourteymour
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
If you create a persistent queue, it does not disappear from your system until you remove them from your JNDI lists manually. This is the story with the persistent queue, but with temporary you're right. So, if you create and deploy persistent destinations at runtime, you won't have such a problem.

Yes Of course, I would like to know more about your project, and I will send you a private message for my contact information.

Thanks,
Amir
 
Goodbye moon men. Hello tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic