Re: Failover and non-persistent messages

2014-02-14 Thread jlindwall
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

Re: kahadb cleanup problem

2014-02-14 Thread artnaseef
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

Re: Stress testing: OOME

2014-02-14 Thread jlindwall
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

Re: Stress testing: OOME

2014-02-14 Thread jlindwall
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

Re: already connected from tcp://xx.xxx.x.xxx:59357

2014-02-14 Thread artnaseef
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

Re: already connected from tcp://xx.xxx.x.xxx:59357

2014-02-14 Thread Rodrigo Ramos
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

Re: already connected from tcp://xx.xxx.x.xxx:59357

2014-02-14 Thread Noel OConnor
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: > >

already connected from tcp://xx.xxx.x.xxx:59357

2014-02-14 Thread Rodrigo Ramos
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

Re: Stress testing: OOME

2014-02-14 Thread Christian Posta
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

Re: Problem with JMX mbean, not showing ActiveMQ.DLQ when ActiveMQ service restarted

2014-02-14 Thread artnaseef
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

Re: performance Replicated LevelDB vs. SAN

2014-02-14 Thread shippers
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

Re: Slow KahaDB access

2014-02-14 Thread Johan Edstrom
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

Re: Slow KahaDB access

2014-02-14 Thread xabhi
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.

Re: rebalanceClusterClients , failover and transactions

2014-02-14 Thread Gary Tully
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

Re: rebalanceClusterClients , failover and transactions

2014-02-14 Thread Enrico Olivelli
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