Hi Rob,
thanks for pointing to this.
I updated docs a bit to reflect the changes introduced by
https://issues.apache.org/jira/browse/AMQ-3791
https://cwiki.apache.org/confluence/display/ACTIVEMQ/Cached+LDAP+Authorization+Module
There's certainly more that can be added so any contribution is we
Hi Rob,
unfortunately ldap network connector is not used much and so there
were no much development on it.
Alternatively, you can check http://fuse.fusesource.org/mq/docs/mq-fabric.html
which uses ZooKeeper for broker discovery.
Regards
--
Dejan Bosanac
--
Red Hat, Inc.
Fus
Hi,
My broker is running SSL only, with a 'simple' transportConnector:
When trying to run a java-client:
Exception in thread "main" javax.jms.JMSException: Could not create Transport.
Reason: java.io.IOException: Could not load resource:
/opt/activemq/conf/client.ts
at
o
I just ran your tests.
Actually, this doesn't seem to be the case of the consumers not going away.
Looks like the connection wasn't properly cleaned up on the broker's side
after the kill -9. Let me try with the trunk and see if there's anything
different before I dig deeper to see why it wasn't cl
Is the client truststore in that location? /opt/activemq/conf/client.ts
I think there was some issues with packaging activemq 5.7 and some of the
client keystores might have been missing.
You'll have to copy from the 5.6.0 version
On Tue, Dec 11, 2012 at 7:05 AM, Geurt Schimmel <
gschim...@sc
you are looking at the need for a writeTimeoutFilter or inactivityMonitor
or OS level tcp keepAlive to detect a half closed socket as the result of
an abortive close of the client.
On 11 December 2012 14:36, Christian Posta wrote:
> I just ran your tests.
> Actually, this doesn't seem to be the
Created key- and truststores for a number of brokers, so not using the packaged
.ks and .ts files.
Tried different truststores in different locations, tried a path to a
truststore that didn't exist, just to see what happens. In all cases, the same
error. Apparently, the point where the keystore
Did you try to use the sslContext element to set your store information withint
he broker configuration file?
Here is a link http://activemq.apache.org/how-do-i-use-ssl.html.
>
> From: Geurt Schimmel
>To: "users@activemq.apache.org"
>Sent: Tuesday, December 1
All brokers run SSL as the only communication-protocol and intercommunicate
over SSL.
-Original Message-
From: Claudio Corsi [mailto:clco...@yahoo.com]
Sent: Tuesday, December 11, 2012 5:17 PM
To: users@activemq.apache.org
Subject: Re: SSL: could not load resource
Did you try to use the
I do not doubt that you are using ssl but are you setting up the configuration
using the sslContext element within the configuration file?
This allow you to set the key and trust store files and their required
passwords.
for instance,
You can also use the technique where you scra
Our broker has been configured with
We are experiencing the problem with the above setting.
Also, the broker occasionally logs the following:
WARN Transport -Async error occured: java.lang.IllegalStateException: Cannot
remove a consumer from a connection that had not been registered: ID: xxx
So here's what's happening...
There are actually three (3) connections being created:
1.. by your ProducerWithConsumer.java
1.. by the Spring DMLC
1.. by your explicit code in SpringConsumerWithReply (which you use to
produce to the temp destination).
So the connection that I saw laying around w
Thanks, yes this is true that there is an open connection to a temp queue
from the the SpringConsumerWithReply service. This is probably a common
scenario where one deploys a service process which services requests from
clients which can disappear at any time. Cleaning up unused/dead connections
wo
Thanks, your reply seems consistent with what I am seeing in the heap dump
(see heapAnalyzer screenshot attached to the initial post). I am still
unclear how are the dead messages cleaned up (if ever). I ran a new scenario
where I had 4 SpringConsumerWithReply processes and a single
ProducerWithRep
Disabling the keystore-code in the source and setting the values at runtime
fixes the problem, so don't think the problem is in the broker-configuration:
Snippet of Producer.java:
import javax.jms.Connection;
import javax.jms.Destination;
import javax.jms.MessageProducer;
im
No, that's not expected behavior. I ran your tests as you described and I
do see memory being consumed and churned, but it all eventually gets
collected by the GC.
Is your heap the 10G heap you mentioned originally? If you can get me the
heapdump, I'll gladly take a look for you. Let me know and I
16 matches
Mail list logo
