I wanted to use projectreator.io TopicProcessor Flux for publishing market data events to several subscribers. If one client is slow the buffer will get full and it will block the publisher completely. I read about onBackpressureBuffer but I don't think this is the solution.
The best would be that I get a callback and/or the subscriber gets disconnected - how can I achieve this?
Hope that somebody can help.
Thanks,
Robert
Related
I am relatively new to JMS and I have been reading a lot on it lately.
I am planning to design a web app which would do the following:
User logs into the system and publishes a message/question to a topic.
All the users who have subscribed to the topic read the message/question and reply to it.
The originator reviews all the answers and picks the best answer.
The originator now replies to only the user whose answer he/she picked and asks for further clarification.
The responder gets the message and replies.
So, once the originator has picked the answer, the JMS now becomes a request/reply design.
My questions are:
Is it possible to publish to a topic with setJmsReplyTo(tempQueue)?
Can request/reply approach be async?
Is it a good idea to have per user queue?
These questions might some dumb to some of the experts here, but please bare in mind that I am still learning.
Thanks.
Is it possible to publish to a topic with setJmsReplyTo(tempQueue)?
You should be able but I'm not 100% sure about it. By the way, I searched in my bookmarks and found this link that should explain what you have to do to build up a Request/Response system using JMS
http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
Can request/reply approach be async?
A message listener is an object that acts as an asynchronous event handler for messages. So you approach about request/reply, if using JMS, is by default async.
http://docs.oracle.com/javaee/1.3/jms/tutorial/1_3_1-fcs/doc/prog_model.html#1023398
Is it a good idea to have per user queue?
I don't know how many user you expect to have but having one queue for each user is not a good way to handle the messages. I had a problem similar to yours but we used a single queue for each of the macro area and we structured the message to hold the information of the user that sent it in order to store the information later and use it to further analysis.
JMSReplyTo is just a message header, nothing else. So It is possible to publish a message withing a topic with specific value in this header.
Sure! If you would like to create a scalable system you should design event driven system using async instead of blocking aproach. MessageListener can help you.
It is specific to JMS broker implementation. If queue creation is quite cheap there is no problems with such a solution.
I am running into an issue wherein subscriptions to a particular topic on TIBCO is taking too long to get updates. Messages on Other topics published to the same cache are working fine. Any ideas why this would be and what can I do to debug this?
My guess is you work with TIBCO EMS (there's also another product called TIBCO Rendezvous).
That for a tool called TIBCO Gems is available. It allows you to monitor topics and queues.
That means you should be able to see when your subscriber takes something of the topic (also the acknowledgment action).
Hope that helps
Cheers
Sebastian
check your topic whether it is synchrous or asynchrous.Synchrous topics will take time. I hope you understand what does synchrous mean else ask me
I am relatively new to JMS and have encountered a weird problem implementing my first real application. I'm desporate for any help or advice.
Background: I use AtiveMQ (java) as the message broker with non-transacted, non-persitent queues.
The Design: I have a straight forward producer/consumer system based around a single queue. A number of nodes(currently 2) place messages onto/ consume from the queue. Selectors are used to filter which messages a node recieves.
The Problem: The producer succesfully places its items on to the queue (i have verified they are there using the web interface) however the consumers remain blocked and do not read them. Only when i close the JMS connection in the producer do the consumers jump into life and consume the messages as expected.
This bevaior seems very weird to me, surely you shouldnt have to completely hang up the producer connection for the consumers to be able to read from the queue. I must have made a mistake somewhere(possibly with sessions) but the at the moment the number of things that could be wrong is to large and i have no idea what would cause this behaviour.
Any hints as to a solution, the cause of the problem or just how to continue debugging would be greatly appreciated.
Thanks for your time,
P.S If you requrie any additional information i am happy to provide it
Hard to say without seeing the code, but it sounds like the producer is transacted. You should not have to close the producer in order for the consumers to receive a message but a transacted producer won't send it messages until you call commit. Other things to check is that the connection has been started. Also if you have many consumers you should look at the prefetch setting to ensure that one consumer doesn't hog all the messages, setting to prefetch of 1 might be needed, but hard to say without further insight into your use case.
I have a network of MS SQL servers connected to each other with (C++/C#)clients connected to them. and I'm about designing a way of messaging between clients and server-client messaging.
I've alread read about MS SQL Service Broker and other Brokers like Apache Qpid.
but still I cant find out how would this work, I would be thankful is someone could provide me with better sources or if someone has already worked with such an issue.
How could I make sending and recieving messages between clients without possible?
and please make sure this is no school homework or university course project.
I would really appreciate any helpful comment or advice...
+++Thanks+++
MSDN has quite a bit of technical information regarding SQL Service Broker. It is fairly high-level, but if you dig / read enough you will be a pro in no time.
http://msdn.microsoft.com/en-us/library/ms166043%28SQL.90%29.aspx
There are also a bunch of useful code samples floating around on the internet that should get you up and running so you can start experimenting.
http://blogs.msdn.com/b/sql_service_broker/
http://www.mssqltips.com/tip.asp?tip=1836
Best of Luck!
Why not poll? It's easy, the "dumbest thing that could possibly work".
I suggest you consider polling unless you have established what the problem with polling is.
Considerations:
Timeliness. How quickly must the message be recieved?
Frequency. How many messages are sent to each client per hour? Per day?
Plus, if your application has a connection heartbeat anyway, you could have it report whether there are any new messages and kill two birds with one stone.
If you are affraid of doing a
//PSUDO Code
while(!stopped){
try{
message = receiver.fetch(timeout);
}catch(TimeoutException){
//handle
}
}
You could always prefetch, set the prefetch:
receiver.setCapacity(100);
and then you could use the available messages functionality, but in all reality, this sounds like polling, in a backwards way ;)
I have an application which tries to subscribes to a lot of different topics.
The server side publishes a lot of messages through these topics and as soon as the application starts subscribing, it receives so many messages that the application cannot even reach the end of the subscription function.
It seems that the OnMessage Listener is flooded so much (the listener is the class which is trying to subscribe itself ot all the topics).
So basically is there a way to stop the reception of messages until I have subscribed to all of the topics? Or am I missing something there?
The thread trying to subsscribe to all of the topics never get the processor again.
(If the server is down, the subscription is fine since it does not receive anything so it does not lose the processing power..)
Thank you in advance.
Paul.
You could try lower the prefetch limit of the consumers, this would prevent the broker from attempting to dispatch so many messages when they are created which should help reduce the flooding issue you are seeing.
Here's some documentation that might help.
http://activemq.apache.org/what-is-the-prefetch-limit-for.html
Tim -
www.fusesource.com