Develop Reference

ActiveMQ : queue VS temporaryQueue

I am using ActiveMQ in order to communicate between servers.
Every server holds one queue in order to send messages and temporaryQueue per each thread in order to receive messages.
When i am using about ~>32 threads i am receiving
Cannot publish to a deleted Destination: temp-queue: xxx
After a while.
When i change from temporaryQueue to "regular" queue everything works perfectly.
(session.createQueue(...) instead of session.createTemporaryQueue())
Why am i getting this error ?
Does it cost more me when i use "regular" queue ?

So implementing request reply using non temporary queues you need some way to correlate the response to a request. You can use the correlation-id header. Since you are not really supposed to create request-unique regular queues, but a fixed set of queues. Like ORDER.CONFIRMATION.RESPONSE or similar. So, it's less costly to use regular queues - IF you reuse them.
To read messages using multiple threads from a common response queue - use a message selector to select JMSCorrelationID header for your particular answer.
However you should be able to use temp queues as well. Your problem is likely some kind of usage issue - but the information provided does not give any clues as it reveals no implementation or analysis.

one consumer for many queues

In my system, there are many users who write the blogs. I need to subscribe to different users. There is no centralized system(it's a swing application).
I am using JMS.
The user may follow one user, two users or 100 users.
m_destination1 = m_session.createQueue("USER.DEVID");
m_consumer1 = m_session.createConsumer(m_destination1);
m_destination2 = m_session.createQueue("USER.HARRY");
m_consumer2 = m_session.createConsumer(m_destination2);
Is there any generic way to write the above lines of code for unknown no. of users ? Like one consumer can receive message from many users.
Here wildcard will not work.

The best thing you can use is Mirrored Queue feature of activeMQ,
you can read the documentation here
http://activemq.apache.org/mirrored-queues.html
What mirrored queue basically does is,it forwards all the messages sent on queue to a similar named topic, this topic can then be subscribed by multiple consumers.
If you use mirrored queue, you will need your consumers to subscribe to different topics.
Your design cries out for publish-subscribe(topic) domain rather than a point-to-point architecture(i.e queue).As you already would be having an architecture which generates a queue for different people writing blogs,change to that system wont be required but your requirement will be catered.
I addition to this,if 2 consumers listen on a queue then they will pick up messages parallely from queue i.e If there are 2 messages on queue then both consumers will process 1 message independently,I don't think that's what you want.
Hope this helps!
Good luck!

#Vihar's answer is right that you should be using the publish-subscribe paradigm by using a topic, to allow multiple consumers to both be notified of new blog posts. It sounds like your primary pain point is that you've got one destination per author and users that want to consume messages have to subscribe to each of them individually.
Instead, have all new-post messages published into a single topic (let's call it NewPostNotificationTopic). Clients can then subscribe to all messages but immediately check them against the list of authors they care about and immediately stop processing any notification for an author they're not following. (This puts the filtering into the message handler rather than into the ActiveMQ network.) This does mean that each message will be passed to each client, but as long as the messages are small and your network is fast and your users are usually connected to the network, this might be a workable solution. But if you can't afford the network bandwidth of sending all messages to all clients, or if your consumers will be offline for long periods of time and you can't afford to hold a copy of all messages till they come back online, this may not work for you.
Alternatively, publish all messages into that same topic, but set the author's ID as a header on the message and use message selectors to tell ActiveMQ to only deliver messages matching a given author ID. This will be more efficient, but you're back to needing to explicitly tell ActiveMQ which authors you care about, either with a single subscription with a selector that contains ORs or with one subscription per author. The latter is cleaner but gets you back to your problem of one subscription per author per reader; the former results in only one subscription but it has to be updated each time you add/remove an author for a reader, and you'll need to make sure you handle the race conditions inherent in removing the subscription and adding another one. I'd go with the first solution I proposed (doing the filtering in the message handler instead of in the ActiveMQ subscriptions) if the performance concerns I raised there aren't a problem; otherwise I'd probably go with one subscription per author per reader, rather than having a single subscription with an ORed selector and needing to redo the subscription each time something changed.

ActiveMQ: Check existence of specific message on queue in ActiveMQ SV by CorrelationId

I use activeMQ server from:
http://activemq.apache.org/enterprise-integration-patterns.html
I have send some message to QUEUE.
I wondering that are there any way to check existence of specific message on queue in ActiveMQ server without consumer the message?

The best why to check for the existence of a single message would be to use a QueueBrowser with a message selector. There are no guarantees though that the browser will return the message depending on how deep the Queue is.
What you are trying to do is an anti-pattern and you should really consider using a true Database if you need to query for data. JMS Queues are meant to house some data which should be consumed rather quickly, there is a very limited feature set around querying for a reason, this is the job of a database.

Process JMS messages in correct order and with good performance

A Java EE application gets data delivered by a JMS queue. Unfortunately, some of the messages which are delivered depend on each other, so they have to be processed in the correct order. As far i understand it, i can't rely on JMS here (or can i? i know that they will be sent in the correct order).
Additionally, it may be the case that there will be one kind of message that will be split by the provider of the messages, so that in some cases thousands of these messages will be sent to the application, all of them related to a specific entity. It would not be necessary to handle them one by one (which would be the easiest way, e.g. in a MDB) and i fear it will be a bad performance if i handle them this way, because i always have to save some information in the database, so i'd prefer to batch them in some way and handle them altogether in one transaction. But i don't know how to do this, since i didn't detect a way to batch messages while reading from a queue. I could get all messages out of a queue every second or so and process them, but then i don't know for sure if messages that depend on each other are already in there.
So i think i need some kind of buffering/caching or sth. like this between receiving and processing the JMS messages, but i don't see a good approach at the moment.
Any ideas how to handle this scenario?

Section 4.4.10 of the JMS spec states that:
JMS defines that messages sent by a session to a destination must be received
in the order in which they were sent (see Section 4.4.10.2 ”Order of Message
Sends,” for a few qualifications). This defines a partial ordering constraint on a
session’s input message stream
(The qualifications are mainly about QoS and non-persistent messages).
The spec continues:
JMS does not define order of message receipt across destinations or across a
destination’s messages sent from multiple sessions. This aspect of a session’s
input message stream order is timing-dependent. It is not under application
control.
So, relying on ordering in your JMS client really comes down to the session scope of your producer and the number of producers.
You could also consider grouping the related messages in a transaction to ensure atomicity of whatever operation you're performing.
Hope that helps a bit.
EDIT: I assume you know "related messages"/dependencies by using some sort of correlationID? I'm getting the idea that your problem is very similar to eg. TCP, so perhaps you could use the algorithms from that area to ensure ordered delivery of your messages?
Cheers,

A JMS Queue will definitely process them in the correct order. It is, after all, a Queue (and you can't cut in line).

Make sure the broker holds messages until at least one consumer gets it

I am begining to implement an ActiveMQ based messaging service to send worker tasks to various servers, however I am noticing that in the default mode, if no one is "listening" to a producer's topic, any message from that producer will be lost.
I.e.,
If Producer Senders Message with a live broker
But No Consumer is there to listen
Message goes no where
I would like instead for the Broker to hold on to messages until at least one listener receives it.
I am trying a couple ways of implementing this, but not sure on the most optimal/right way way:
Implement a Message Acknowledgement feature
(Caveat to this is I need the producer to wait on its listener after every message which seems very, very clunky and last resort...)
Implement the Session Transaction
(I am having trouble with this one, it sounds like the right thing to use here because of the word transaction, but I think it has more to do with the producer-broker interaction, not the producer-consumer)
Ideally, there is a mode to send a (or a set of) messages, and after sending a Boolean is returned stating if the message(s) were listened by at least one consumer.

Transactions and acknowlegdement conflict somehow with the general idea of a JMS topic.
Just use a queue instead of a topic. Access this queue using CLIENT_ACKNOWLEDGE or a transacted session. A worker task is to be processed by one worker only anyway, so the queue solves another problem.
If there was a special reason to use topics, you could consider a message driven bean (MDB) on the same host like the JMS provider (you could achieve this by using JBoss with its integrated HornetQ for example), but this is still not really correct.
Another possibility is to have both a topic and a queue. The latter is only for guaranteed delivery of each message.

This isn't really a typical messaging pattern. Typically, you have one receiver and a durable queue or multiple receivers with durable subscriptions to a topic. in either situation, each receiver will always receive the message. i don't really understand a use case where "at least one" receiver should receive it.
and yes, transactions only deal with the interactions between client and broker, not between client and eventual receiver(s).