No obvious solutions available, you should explore the broker plugin mechanism
at first and then have to write your own broker plugin to protect the broker
from creating too many temp queues by clients,but the more simple solution
would be using TaskRunnerFactory based on the shared thread pool.
Is any way to protect broker from malicios or badly written client code that
keep creating temp queues?
At some point broker hits virtual memory limits and number of live threads
is very high...
javax.jms.JMSException: unable to create new native thread
at
org.apache.activemq.util.JMSExcep
As far as I recall, consumers are selected using a hash function. If the
hashes for both values match, it could justify this behaviour.
You can change the bucketing algorithm with something like:
...
Check the AMQ Javadoc for implementations of the MessageGroupMapFactory
interface to see what
I have a single queue, configured with 50 consumers.
When building the message I do,
message.setStringProperty("JMSXGroupID", jmsGroupID);
Where jmsGroupID is selected based on some string in the message body. There
are about 20 different values for jmsGroupID at this time. However, when
processi
Did you try enabling TCP keepalives on the Connection Factory (client) and
the Transport Connector (broker)? Perhaps that hints the intermediate
router that the connection is still alive on both ends.
See the keepAlive option in [1].
[1] http://activemq.apache.org/tcp-transport-reference.html
Re
I had a peek that your code, the problem is on the broker.
The problem is that the prefetch value specified in broker config via the
policy entry is not enforced by stomp, so the default topic prefetch value
(maxInt-1) is in effect.
You could validate that via jconsole jmx on the broker, looking at
Hi, Christian!
I think you've solved the mystery. Besides 5 different directories, the
following files exist:
apache-activemq-5.7.0-bin.tar.gz
apache-activemq-5.7.0-bin.zip
These must have been the files that Tim was referring to. I will try
extracting one of these files.
Thanks again!
- Bruce
(Tim, sorry, my last reply to you got mangled. Let me try again.)
Tim, unfortunately, our directory structures seem to be different. From the
ActiveMQ root directory (activemq-parent-5.7.0), there is no src
sub-directory. Here is a listing of my ActiveMQ root directory:
total 284
4 drwxr-xr-x 28
On Thu, 2012-12-20 at 06:43 -0800, Bruce.Hall wrote:
> Hi, Tim! Thanks for the response.
>
> If I'm downloading the binary tar file in order to get the application to
> work correctly, doesn't that defeat the entire purpose of compiling the
> application from source? Is there a way to make use
Hi, Tim! Thanks for the response.
If I'm downloading the binary tar file in order to get the application to
work correctly, doesn't that defeat the entire purpose of compiling the
application from source? Is there a way to make use of the source I just
compiled to launch the application?
- Bruc
On Thu, 2012-12-20 at 06:28 -0800, Bruce.Hall wrote:
> I'm new to ActiveMQ so please forgive my ignorance if this question seems
> obvious. I downloaded the 5.7 version the ActiveMQ source to a Tilera
> (non-x86 architecture) CentOS machine and then compiled it using "mvn clean
> install -Dmaven.
I'm new to ActiveMQ so please forgive my ignorance if this question seems
obvious. I downloaded the 5.7 version the ActiveMQ source to a Tilera
(non-x86 architecture) CentOS machine and then compiled it using "mvn clean
install -Dmaven.test.skip=true". The compilation reported success with all
mo
12 matches
Mail list logo
