Hi there,

Let me first describe the way I am planning to use activemq for my service.

The service provides API for its clients and guarantees to notify anybody
interested in the changes happened to its data. For example if new user is
created, every API user should be able to be notified about it and query for
new information if they want to (or handle the notification any other way).
To implement these notifications I use activemq. Notifications are sent as
persistent messages to the associated topics, e.g. "Service.User" and
therefore everyone who wants to stay notified about new users can simply
implement the durable consumer to receive messages from that topic.

There are not many topics I need, but the volume of messages might be quite
high - I am expecting around 100-200k notification per day for the very
beginning and be able to increase this number drastically when deploying to
production.

Having implemented the above scenario I seem to face a problem of
limitations of some sort.
The service is developed in C#.Net and Apache.NMS and ActiveMQ is installed
on Windows Server machine.
I didn't have time to optimize my code and I do create a new
connection/session/producer for every single notification sent. But it's not
an issue since for the moment I am not concerned about this sort of
performance.

The problem I have that when running my functional tests it seems I am not
able to send messages to activemq once it reaches around 20k of messages. It
just hangs and results in a timeout for my transaction (40 secs). It gets
resolved when I remove all topics' messages at
http://localhost:8161/admin/topics.jsp admin page.

Can you please point me to the right actviemq configuration I should use for
my case? 

What can be the reason of the problem I am facing?

Any overall suggestions are welcome as well! 
Thanks in advance.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Long-time-persistence-service-tp3693598p3693598.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Reply via email to