Assume that consumers receiving duplicate messages are NOT a problem. Can
the fanout protocol possibly be used for this scenario? Maybe combined with
failover? (Can you tell I have not thought this through?)
Producers use fanout to duplicate all messages to 2 brokers. Consumers use
fanout (gul
Maybe the TX part is not the real problem.
Keep in mind that it only takes a single message to hold an entire 32mb
kahadb file. Note 32mb is the default; the size can vary.
So, check for any destinations with some number of old messages.
--
View this message in context:
http://activemq.2283
I'll be re-running my stress test and Monday and report my findings back to
this thread. Thanks! Your questions are thought provoking.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Stress-testing-OOME-tp4677959p4678010.html
Sent from the ActiveMQ - User mailing list ar
Thanks all for the comments - I will rerun my stress test on Monday and
report back. I do not think my url-based parameter were being used because
of pilot error: I was using a jndi.properties file (a practice I have now
abandoned) and the connection url was specified in that file, not in my
exter
Is the client code setting a Client ID on the connection via setClientID()?
http://docs.oracle.com/javaee/1.4/api/javax/jms/Connection.html#setClientID(java.lang.String)
If so, then only one connection with a specific client ID can connect to the
broker/network-of-brokers at any one time. Given
Im using an only one cosumer for all queues.
Regards
El feb 14, 2014 6:13 PM, "Noel OConnor" escribió:
> Are you using topics and reusing the same client id for multiple producers.
> Its just a guess but check just in case.
>
>
> On Sat, Feb 15, 2014 at 9:18 AM, Rodrigo Ramos
> wrote:
>
> > Hi
Are you using topics and reusing the same client id for multiple producers.
Its just a guess but check just in case.
On Sat, Feb 15, 2014 at 9:18 AM, Rodrigo Ramos wrote:
> Hi
>
>
> Im testing a web application that is connected with ActiveMQ as producer.
> IM getting below error with load:
>
>
Hi
Im testing a web application that is connected with ActiveMQ as producer.
IM getting below error with load:
[#|2014-02-14T15:59:26.840-0600|WARNING|glassfish3.1.2|javax.enterprise.system.core.transaction.com.sun.jts.jta|_ThreadID=801;_ThreadName=Thread-2;|JTS5041:
The resource manager is doin
Want to post the code for your consumer?
Is each consumer in its own JVM or are all consumers sharing the same JVM?
Sharing same Session/Connection?
On Thu, Feb 13, 2014 at 2:31 PM, jlindwall wrote:
> I am stress testing activemq 5.9.0 by sending a flood of non-persistent
> messages to a topic us
Something is very odd. This error:
Should not be reported when hitting the main Queue page on the broker
because that page is iterating existing destinations in the broker, unless
the broker is starting up with JMX disabled.
Is it possible the wrapper is causing a different broker config file
I'm testing with ActiveMQ Replicated too (latest SNAPSHOT build) and seeing
similar problems with stability and reliability. Performance-wise, it
depends on the messaging pattern, number of pubs / subs, message size, and
transaction size. Also, very dependent on network speed and local disk
speed
http://activemq.apache.org/kahadb.html
On Feb 14, 2014, at 10:19 AM, xabhi wrote:
> Can somebody from activemq dev answer these queries please?
>
> Thanks,
> Abhi
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Slow-KahaDB-access-tp4677915p4677981.html
> S
Can somebody from activemq dev answer these queries please?
Thanks,
Abhi
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Slow-KahaDB-access-tp4677915p4677981.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
the rebalance is all about new brokers in the cluster, so the
rebalance should only fire on a broker start.
the priorityBackup options allow a failover client to be sticky. Also
updateURIsSupported=false and reconnectSupported=false disables this
feature client side
On 8 February 2014 17:07, Enri
Not, I'm sorry. I tried your suggestion but that option prevents clients to
reconnect to other brokers if the actual connected broker goes down.
2014-02-10 0:09 GMT+01:00 artnaseef :
> Try this on the broker transport conntector.
>
> updateClusterFilter=nosuchthing
>
> Let me know if it does n
15 matches
Mail list logo