Re: java.io.EOFException when ActiveMQ starts

2016-10-09 Thread divinedragon
My activemq.xml is configured like below.





--
View this message in context: 
http://activemq.2283324.n4.nabble.com/java-io-EOFException-when-ActiveMQ-starts-tp4717598p4717709.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: activeMQ fails on NetApp switch

2016-10-09 Thread Paul Gale
Can you please forward the details of how you're mounting the NetApp
exports? Please include all all NFS parameters.

Thanks,
Paul

On Thursday, October 6, 2016, fg  wrote:

> Hi,
>
> We have 5 managed virtual servers with managed NetApp SAN Storage at our
> hoster. On every server an instance of ActiveMQ 5.12.0 is running. We use
> the NetApp as shared file system with kahaDB and mount a folder with NFSv4.
> This is our persistenceAdapter configuration:
>
> 
>  lockKeepAlivePeriod="5000">
> 
>
> 
> 
> 
>
> Whenever our hoster test the NetApp redundancy and switch between the
> NetApp
> Nodes our ActiveMQ crashes. The following error appears in the log of
> server1:
>
> I2016-09-19 12:27:26,100 INFO  [ActiveMQ Lock KeepAlive Timer]
> org.apache.activemq.util.LockFile: Lock file /mnt/apache/queue/lock,
> locked
> at Wed Sep 14 18:49:26 CEST 2016, has been modified at Mon Sep 19 12:27:21
> CEST 2016
> I2016-09-19 12:27:26,101 ERROR [ActiveMQ Lock KeepAlive Timer]
> org.apache.activemq.broker.LockableServiceSupport: osm1Broker, no longer
> able to keep the exclusive lock so giving up being a master
>
> Server5 took the Handle but after 12 Minutes the same logs appears. I think
> there was another switch, but we don't get the info from our hoster. After
> that activeMQ stops working. More and more messages are stored in queue.
> After a complete restart, everythin works as expected.
>
> Is there any misconfiguration or tips?
> I thougt about switching to CephFS or GlusterFS to stay away from managed
> NetApp. Are there any experiences?
>
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/activeMQ-fails-on-NetApp-switch-tp4717558.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>


-- 
Thanks,
Paul


Re: ActiveMQ NMS and Failure Recovery

2016-10-09 Thread Jim Gomes
The first thing I notice is that you haven't actually enabled failover. The
connection URI should be based on this:

activemq:failover:tcp://hostname:61616

The inclusion of failover: is important.

Beyond that, if you break inside of a debugger, you most likely will be
disconnected by the broker. So I'm not sure what you are asking. Do you
want to survive breakpoints in a debugger, or do you want normal failover
in production?


On Sun, Oct 9, 2016, 9:00 AM magmasystems 
wrote:

> Hello all,
>
> As we prepare to ship our new product that uses ActiveMQ NMS heavily, I am
> trying to harden the code against possible failures. One of the things that
> our developers have noticed (and others in this group may have noticed) is
> that it is common to get NMSExceptions when you are stopped at a breakpoint
> for a while in Visual Studio. The connection is lost, and often times, we
> need to restart our services.
>
> Our typical connection string is this:
>
>
>
> activemq:tcp://myserver:61616?transport.useInactivityMonitor=falseamp;keepAlive=true
>
> I have a few questions:
>
> 1) Let's say that we have a few cached consumers. If a connection faulted,
> and we need to open a new connection, I assume that we also need to create
> new sessions and therefore, create new consumers and producers? Or is there
> any way to take an existing session and associate it with a new connection?
>
> 2) What are the best patterns for failure recovery, especially when a
> connection goes down because of a "keep-alive" violation? Do we need to
> only
> create a new connection? Do we need to recreate all sessions? Do we need to
> recreate all consumers and producers?
>
> 3) Are there any other parameters that you feel that I should add to my
> URI?
> I see that there are parameters like:
>
> wireFormat.maxInactivityDuration (set to either a large number or to -1 ...
> people have tried both)
> maxInactivityDurationInitalDelay
>
> Thanks very much for any advice.
>
> -marc
>
>
>
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>


ActiveMQ NMS and Failure Recovery

2016-10-09 Thread magmasystems
Hello all,

As we prepare to ship our new product that uses ActiveMQ NMS heavily, I am
trying to harden the code against possible failures. One of the things that
our developers have noticed (and others in this group may have noticed) is
that it is common to get NMSExceptions when you are stopped at a breakpoint
for a while in Visual Studio. The connection is lost, and often times, we
need to restart our services. 

Our typical connection string is this:

   
activemq:tcp://myserver:61616?transport.useInactivityMonitor=falseamp;keepAlive=true

I have a few questions:

1) Let's say that we have a few cached consumers. If a connection faulted,
and we need to open a new connection, I assume that we also need to create
new sessions and therefore, create new consumers and producers? Or is there
any way to take an existing session and associate it with a new connection?

2) What are the best patterns for failure recovery, especially when a
connection goes down because of a "keep-alive" violation? Do we need to only
create a new connection? Do we need to recreate all sessions? Do we need to
recreate all consumers and producers?

3) Are there any other parameters that you feel that I should add to my URI?
I see that there are parameters like:

wireFormat.maxInactivityDuration (set to either a large number or to -1 ...
people have tried both)
maxInactivityDurationInitalDelay

Thanks very much for any advice.

-marc







--
View this message in context: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


random udp port being opened

2016-10-09 Thread dobby001
Hello,

On both the client and the server (where broker is started) I am seeing an
udp port being opened.
The port number is random each time. I am not figuring out why this udp port
is being opened or which static code is opening it.
Wondering whether anyone can throw some light on why this udp port is being
opened  and where it is used and
if possible how to disable it. If some plugin is opening it, how to disable
it.
Really appreciate the comments.

I am using broker in embedded mode and the clients to connect to it from
either same system on different systems.
I am using 5.13.1 version of ActiveMQ on Linux Centos systems 7.x.

Code snippet for broker start part, if it helps...
 broker = new SslBrokerService();
 broker.setPersistent(true);
 broker.setBrokerName("dobby");
 broker.setUseJmx(false);
broker.setPlugins(new BrokerPlugin[] { new IPAuthenticationPlugin(), new
StatisticsBrokerPlugin() });
broker.setEnableStatistics(true);
broker.addSslConnector("ssl://10.1.1.10:61617",.)
broker.start();


netstat -tulpen |grep 31197  # 31197 is the java pid which starts broker
udp0  0 0.0.0.0:48924   0.0.0.0:*  
4981236777544 31197/java


The client side url is similar, ssl or failover 
Again, I see a udp port being opened here.


Thanks.
Chandra



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/random-udp-port-being-opened-tp4717699.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: Virtual topics, custom prefix limitations

2016-10-09 Thread Tim Bain
This blog post (
http://workingwithqueues.blogspot.com/2012/05/activemq-virtual-topics-or-virtual.html?m=1)
seems to indicate that you can.  Please let us know if it works.

On Oct 4, 2016 8:31 AM, "Devlin"  wrote:

> When customizing virtual topic consumer "prefix", can I use wildcards?
>
> I know this works:
>
> 
> 
> 
>
> ..not sure if this /would/ work:
>
> 
> 
> 
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Virtual-topics-custom-prefix-limitations-tp4717481.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>


Re: ActiveMQ ReplicatedLevelDB corruption

2016-10-09 Thread Tim Bain
This is the first I'd heard of a replicated KahaDB implementation.  I'd
heard of multi-KahaDB (mKahaDB), but that's multiple KahaDB databases on a
single broker (split by destination) rather than replicated.  Maybe someone
else can provide more info...

On Oct 5, 2016 1:51 AM, "mlange"  wrote:

> thanks for providing a good idea of what to expect; yet I think it's good
> to
> be aware of this.
> I did notice upon searching that there has been done some work to get
> Kahadb
> replicating; is that completely abandoned or is it still something that
> might get implemented (in a somewhat near future) I think it's a great idea
> to have the database replicating, to reduce the added complexity of shared
> storage (which may itself fail, so needs to have it's own fault tolerance)
>
> I'll explore what other options are available and work well.
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/ActiveMQ-ReplicatedLevelDB-corruption-tp4716831p4717517.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>