Re: Rfresh org.apache.activemq.broker.SslContext from disk/jks content

Issue created. m -- View this message in context: http://activemq.2283324.n4.nabble.com/Rfresh-org-apache-activemq-broker-SslContext-from-disk-jks-content-tp4698040p4698319.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Rfresh org.apache.activemq.broker.SslContext from disk/jks content

Thank you for the answers: it is clear now. I'll create the enhancement request in JIRA and I'll try to implement what Gary suggests. Many thanks, matteo -- View this message in context: http://activemq.2283324.n4.nabble.com/Rfresh-org-apache-activemq-broker-SslContext-from-disk-jks-content-tp

Rfresh org.apache.activemq.broker.SslContext from disk/jks content

Dear all, I have the following configuration for the BrokerService object: The custom implementation of SslContext allows me to reload the truststore when a new certificate is added in the jks file. Everything works fine when I have my clients directly connected to the broker but it mysteriously

Re: AMQ-5260 - Cross talk over duplex network connection can lead to blocking (alternative take)

As a first approach I put under test this one: -- View this message in context: http://activemq.2283324.n4.nabble.com/AMQ-5260-Cross-talk-over-duplex-network-connection-can-lead-to-blocking-alternative-take-tp4683060p4683065.html Sent from the ActiveMQ - User mailing list archive at Nabble.co

AMQ-5260 - Cross talk over duplex network connection can lead to blocking (alternative take)

Hello, I'm trying to develop a patch for AMQ-5260. Since the problem involves locks that are held in classes that are quite far apart from each other (MutexTransport and DemandForwardingBridgeSupport), a hint from AMQ gurus on what is the best approach to attack the issue would be very valuable f

Re: org.apache.activemq.broker.region.Queue.doBrowse never returns

I really appreciate your quick reply gary. Thanks. So it seems to me that a possible solution would be trying to create a patch for this, right? Could I create an issue with a tentative patch? -- View this message in context: http://activemq.2283324.n4.nabble.com/org-apache-activemq-broker-re

Re: org.apache.activemq.broker.region.Queue.doBrowse never returns

Hi! thanks for the response. Actually I activated periodic expiry checking on purpose since we have massive message production and this is a way to tame the memory usage. I'll try with the maxBrowsePageSize and maxExpirePageSize settings. Anyway, do you think this infinite while loop is the expec

org.apache.activemq.broker.region.Queue.doBrowse never returns

Version: AMQ 5.9.0 I'm dealing with a strange behavior of org.apache.activemq.broker.region.Queue.expireMessages() of org.apache.activemq.broker.region.Queue.expireMessagesTask. Basically this task stops working after few minutes after broker bootup. I tried to track down the source of the problem

Re: Proxy Connector memory consumption

I added a tentative patch to the issue (AMQ-4889). As long as I can see, the problem was adding ProxyConnection objs into a collection inside ProxyConnector before starting them. -- View this message in context: http://activemq.2283324.n4.nabble.com/Proxy-Connector-memory-consumption-tp46742

RE: Updateclusterclients attributes specified on NIO+SSL transports

Well, I use an embedded broker and the config file is not in a standard activemq xml format. Thus the config entries are slightly different from standard activemq ones:

RE: Updateclusterclients attributes specified on NIO+SSL transports

Well, thank you for the insights about the PublishedAddressPolicy stuff. I completely ignored that! Besides, I'll definitely try with "finite" ip addresses instead of 0.0.0.0 one. Still, I cannot understand why a client initially connected to a ssl connector should switch to tcp just because serve

RE: Updateclusterclients attributes specified on NIO+SSL transports

Well, thank you for the insights about the PublishedAddressPolicy stuff. I completely ignored that! Besides, I'll definitely try with "finite" ip addresses instead of 0.0.0.0 one. Still, I cannot understand why a client initially connected to a ssl connector should switch to tcp just because serve

Updateclusterclients attributes specified on NIO+SSL transports

I'm debugging for days the behavior of NIO+SSL transport against the updateClusterClients, rebalanceClusterClients and updateClusterClientsOnRemove props. I have a broker configured with two different transport conn: NIO and NIO+SSL, something like nio://0.0.0.0:61616 nio+ssl://0.0.0.0:61619

Re: Proxy Connector memory consumption

Ok, issue created: AMQ-4889 I attached to the issue a couple of simple projects to reproduce the issue. Apparently this issue affects the ProxyConnector only, not the standard TransportConnector. -- View this message in context: http://activemq.2283324.n4.nabble.com/Proxy-Connector-memory-con

Re: Proxy Connector memory consumption

Nobody? Is the question so boring? -- View this message in context: http://activemq.2283324.n4.nabble.com/Proxy-Connector-memory-consumption-tp4674255p4674390.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Proxy Connector memory consumption

I configured a ProxyConnector nio+ssl transport. When it is used coupled with an external load balancer (over which I have no control at all) I get a quite annoying behavior: the balancer keeps opening connections towards the proxy connector just to assess its responsiveness. The net effect of this

Re: SOAP over JMS fails with AMQ 5.8.0 and AMQ-4312 patch

I tried with the latest snapshot (apache-activemq-5.9-20130919.101342) and everything worked fine. So I think something is missing in the uploaded patch for AMQ-4312. Does anyone have a clue about what it could be missing from the patch? What AMQ packages could be involved? Maybe I could try a dif

SOAP over JMS fails with AMQ 5.8.0 and AMQ-4312 patch

Once upon a time when we were using AMQ 5.6.0, we run into the https://issues.apache.org/jira/browse/AMQ-4076. For us, the effects of this bug were a failure in CXF over JMS when the envelopes size exceeded a 20KB size (more or less). To solve the problem we upgraded to 5.8.0 and the problem disap

Re: Occasional Null Pointer Exception during NetworkConnector connection again?

It happens when we try to add a third broker to the network and after few seconds we stop the newly introduced broker. This third broker has the same configuration with respect broker 2. matteo -- View this message in context: http://activemq.2283324.n4.nabble.com/Occasional-Null-Pointer-Exce

Occasional Null Pointer Exception during NetworkConnector connection again?

ActiveMQ v 5.8.0 We have a two brokers network with duplex network connector and the following additional properties: Broker 1 - networkConnector: Broker 2 - no network connector specified, Both Broker 1 AND Broker 2 have the following common config entries: Occasionally, we see the followin

Re: Client Failover in a brokers network

Ok, I think I just re-discovered this one: AMQ-4505 What would you suggest? To recompile trunk? Is there a patch that could be applied to 5.8.0 codebase? Thanks -- View this message in context: http://activemq.2283324.n4.nabble.com/Client-Failover-in-a-brokers-network-tp4666899p4666925.html S

Client Failover in a brokers network

I have the following broker topology: NC1 e NC2 are configured with uri="multicast://239.255.2.4" e TTL=5. duplex=false on both NC1 and NC2. Both brokers create a openwire transport connector with nio://0.0.0.0:61616 and discoveryURI="multicast://239.255.2.4". Besides, the following pro

hostname in certificate didn't match exception with Https transport

When I try to connect a remote producer to my broker via a https transport I get the following error: Now I would like to disable this check through the following configuration: but I cannot retrieve the SSLSocketFactory associated with my https transport... I can only retrieve the SslContext fro

Re: Abnormal (?) NIOTransport memory usage

I'm really sorry for the confusion, but despite of what I wrote in my last post, the problem with the NIO+SSL NIOTransport huge memory usage is still there. Unfortunately, the abnormal memory consumption is also triggered by pure SSL transport (broker-side). AMQ version 5.8.0 NMS version 1.5.0.2

Re: Abnormal (?) NIOTransport memory usage

Ok. I managed to fix the "pure ssl transport" problem. And, apparently, the abnormal memory consumption usage with nio+ssl was related to this ssl misconfiguration! I'll try to explain. Until today, I used to configure the SSL context AFTER creating the transports, namely: This apparently works w

Re: Abnormal (?) NIOTransport memory usage

The transport I'm connecting to is a NIO+SSL one. I tried to specify a pure SSL transport at the broker side but I got the following exception But I suspect that this is another story/problem: I have always used a NIO+SSL connector and it is ages since I last tried the pure SSL one. By the way,

Abnormal (?) NIOTransport memory usage

Dear all, I would like to ask you why I'm experiencing a quite strange situation with ActiveMQ 5.8.0. I have a 5.8.0 AMQ broker with the following transport connectors: As soon as I try connecting a CMS client to this broker (using SSL), I got an out of memory error. The generated hprof

Re: Producer gets stuck on a particular PC

Ok, finally I managed to get the producer working. I guess the issue has been triggered by the following operations: - Until yesterday, I run the producer with a default connection id generated by the connection factory; - Now I set the connection id of the producer through the - After the implem

Network of brokers theory of operations

Let us say I start broker1 and as soon as broker1 completes its start-up procedure a consumer C1 starts listening on topic TOPIC1. After that, broker2 starts and a couple of consumers C2 and C3 subscribe to TOPIC1 as well. Broker1 and broker2 form a network of brokers with multicast discovery. Cl