Re: Can I connect to a vm URL without a password?
Thanks Tim - I think I’ve got one working now. I wound up casting the result of getConnector() to TransportConnector and then calling getName() - it looks like it has what I need. I’ve got a version running locally now, and it seems to be doing what I’m after. Thanks for all of your help. BTW - let me know if you think this is something the community would like and I’ll put together a PR for it. Thanks Again Quinn > On Mar 25, 2018, at 11:11 PM, Tim Bain wrote: > > Quinn, > > I think you should be able to access the URI to which the connection is > bound by calling > ((TransportConnector)context.getConnector()).getServer().getConnectURI(), > and then you can parse the protocol out of it. But it's not something I've > personally done and I don't have time to try it right now, so this is > purely conjecture based on the documentation plus reading the code. So if > that doesn't work, I apologize, but let me know how it blows up and I can > try to help further. > > Tim > > On Thu, Mar 22, 2018 at 10:22 AM, Quinn Stevenson < > qu...@pronoia-solutions.com> wrote: > >> Thank you Tim - >> >> I was afraid you were going to say that :-) >> >> I was looking at the SimpleAuthenticationPlugin / >> SimpleAuthenticationBroker, and I have an idea how to do this. The one >> thing I’m not sure about is how I can tell when the connection is coming >> via a VM URL - do you have any hints on that? >> >> >>> On Mar 21, 2018, at 7:21 PM, Tim Bain wrote: >>> >>> I'm not sure there's a built-in way to do this without writing any code, >>> but you should be able to write a simple security plugin that allows you >> to >>> allow or deny connections based on their transport and whether they are >>> anonymous. The bottom of http://activemq.apache.org/security.html has >>> details about how to get started. >>> >>> Tim >>> >>> On Wed, Mar 21, 2018, 6:08 PM Quinn Stevenson < >> qu...@pronoia-solutions.com> >>> wrote: >>> I have several components running inside the same JVM as ActiveMQ, and they connect to the broker using a vm URL. Guest access to the broker >> has been disabled for security reasons, but I’d like the embedded >> components to be able to connect to the broker without a username or password. Is there a way to configure ActiveMQ to allow anonymous/guest access for VM connections only? >> >>
Re: [artemis] Getting ClientID over JMX
do you know how to make a pull request? We can merge it really quickly with Pull Requests. On Mon, Mar 26, 2018 at 4:58 PM, Big Puritz wrote: > JIRA Issue with patch created: ARTEMIS-1769 > > > On Sat, Mar 10, 2018 at 10:41 PM, Justin Bertram > wrote: > >> There's a handful of administrative operations on the ActiveMQServerControl >> MBean to get information about connections, sessions, consumers, producers, >> etc., but none of these expose the JMS client ID. If this is a requirement >> for you please open a JIRA [1] which a description of exactly what you're >> looking for. >> >> It would be even better if you could send a pull request to the ActiveMQ >> Artemis GitHub repository with the functionality you're looking for >> (including a test to make sure it works). I believe you'd want to change >> the listSessionsAsJSON(String) and listAllSessionsAsJSON() methods on >> org.apache.activemq.artemis.core.management.impl.ActiveMQServerControlImpl >> to include the JMS client ID. The JMS client ID is stored in the session's >> meta data using >> org.apache.activemq.artemis.api.core.client.ClientSession# >> JMS_SESSION_CLIENT_ID_PROPERTY >> as the key. Integration tests for these methods are in >> org.apache.activemq.artemis.tests.integration.management. >> ActiveMQServerControlTest. >> >> >> Justin >> >> [1] https://issues.apache.org/jira/browse/ARTEMIS >> >> On Sat, Mar 10, 2018 at 12:05 PM, Big Puritz wrote: >> >> > Hello, >> > >> > how can i get the value of the ClientID over JMX assigned to the >> connection >> > / session / consumer / producer? >> > >> > Thanks >> > >> -- Clebert Suconic
Re: [artemis] Getting ClientID over JMX
JIRA Issue with patch created: ARTEMIS-1769 On Sat, Mar 10, 2018 at 10:41 PM, Justin Bertram wrote: > There's a handful of administrative operations on the ActiveMQServerControl > MBean to get information about connections, sessions, consumers, producers, > etc., but none of these expose the JMS client ID. If this is a requirement > for you please open a JIRA [1] which a description of exactly what you're > looking for. > > It would be even better if you could send a pull request to the ActiveMQ > Artemis GitHub repository with the functionality you're looking for > (including a test to make sure it works). I believe you'd want to change > the listSessionsAsJSON(String) and listAllSessionsAsJSON() methods on > org.apache.activemq.artemis.core.management.impl.ActiveMQServerControlImpl > to include the JMS client ID. The JMS client ID is stored in the session's > meta data using > org.apache.activemq.artemis.api.core.client.ClientSession# > JMS_SESSION_CLIENT_ID_PROPERTY > as the key. Integration tests for these methods are in > org.apache.activemq.artemis.tests.integration.management. > ActiveMQServerControlTest. > > > Justin > > [1] https://issues.apache.org/jira/browse/ARTEMIS > > On Sat, Mar 10, 2018 at 12:05 PM, Big Puritz wrote: > > > Hello, > > > > how can i get the value of the ClientID over JMX assigned to the > connection > > / session / consumer / producer? > > > > Thanks > > >
Unreliable NFS exclusive locks on unreliable networks
Hi guys, just wondering if anyone else has tested this and found similar
problems.
I've been testing ActiveMQ in a shared storage master/slave configuration,
using an NFSv4 server for the shared storage. I've tried this both with a
standalone nfs server, and using Amazon's EFS server.
My tests are looking into what happens when the network is unreliable -
specifically, if for some reason the master ActiveMQ broker can't
communicate with the NFS server.
What I've been seeing, in a nutshell, is the following:
- At startup, the Master gets exclusive access to the NFS lock file, and
the Slave doesn't, and it loops waiting for the lock, as expected.
- When I cut the Master off from the NFS server, the NFS server eventually
times out the lock, and the Slave acquires it and starts up. It gets a
pile of journal errors, but it does eventually sort things out and start,
and clients using the failover: protocol start sending messages to the
slace.
- Eventually, the Master notices that it is broken and tries to shut down.
It takes a long time - I get a lot of warnings like:
[KeepAlive Timer] INFO TransportConnection- The connection to
'tcp://10.0.12.209:42150' is taking a long time to shutdown.
... I'm guessing it's trying to gracefully shut down a listener or
something? Anyway, eventually I get a DB failure and it dies.
The problem though, is that the Master re-starts itself - as it should.
And in the meantime I've repaired the connection to the NFS server. So the
master should now try to grab the exclusive lock and fail, and become a
slave instead.
However, this generally doesn't seem to happen. The master restarts, with
no lock errors, and I have two brokers both thinking they own the same
NFS-based database. Not a good situation. (Once, I had a situation where
the master did seem to block waiting for a lock, but I haven't been able to
reproduce that behaviour)
Has anyone else seen this? None of this would affect a situation where the
master broker crashed or was restarted - that should be fine - but it seems
quite unreliable when a network split occurs, at least from our testing so
far.
Note that this may be related to a problem with Java and exclusive file
locks, which I raised the other day on Stack Overflow:
http://stackoverflow.com/questions/38397559/is-there-any-way-to-tell-if-a-java-exclusive-filelock-on-an-nfs-share-is-really
the TL;DR is that the FileLock.isValid() check that is used in
org.apache.activemq.util.LockFile.keepAlive() is pointless - it doesn't
actually check that the lock is still valid, just that no other thread in
the same JVM has killed the lock.
However the LockFile.keepAlive code:
public boolean keepAlive() {
return lock != null && lock.isValid() && file.exists();
}
... should still fail, as file.exists() should fail if the NFS server has
gone away. (though it's possible this will block rather than failing...)
- Korny
--
Kornelis Sietsma korny at my surname dot com http://korny.info
.fnord { display: none !important; }
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Re: Migratiion of Queue data from HornetQ to Artemis 2.x
Your broker.xml didn't set the critical analyzer option as HALT. For some reason you had a condition where your server became non responsive and the critical analyzer logged instead of halting. (as configured to do) it seems your issue was low memory what would make your issue a non issue. On Mon, Mar 26, 2018 at 3:09 AM, dharmendra wrote: > hi Clebert, > > Any finding why this thread dump is occuring all of sudden. > > > > > > - > DKumar > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html -- Clebert Suconic
Re: Disable access to Dead Letter Queue
Based on my current understanding of the management functionality I would expect your configuration to reliably secure the DLQ so I would consider any failure to do so a bug. Please open a JIRA and include a test-case to reproduce the issue. Justin On Wed, Mar 21, 2018 at 1:29 PM, cnadukula wrote: > any update for me on this guys? > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User- > f2341805.html >
Re: [Artemis] Some data isn't delivered using Paho client
Can you work-up a test-case to reproduce the issue? You could easily base this on one of the MQTT examples we ship with the broker. Justin On Thu, Feb 1, 2018 at 5:17 AM, Dustbit wrote: > Hello, > > I work with Raul and we found what was causing the problem. > > Problem and steps to reproduce: > > - Connect subscriber to broker (cleanSession=false) > - Subscribe 3 topics (through 3 different calls using the same client) > - Disconnect subscriber > - Send 50k messages to the broker (broker holds messages as it's queues are > durable) > - Connect subscriber (with same clientId) > - Subscribe the same 3 topics (through 3 different calls using the same > client) > - No pending messages are sent to the subscriber, even though they're in > the > queue > > When disconnecting the subscriber again some message were flushed, but > reconnecting again resulted in the same stale situation. > New messages arriving the broker were being sent just fine to all topics, > only the ones already there were not sent. > > Cause: > If instead of subscribing through 3 different calls for 3 different topics, > we subscribe in 1 call with the 3 topics (as an array) everything works > fine > on reconnect. > > I think there's something wrong on the re-attach/reconnect logic that is > causing this behavior, that's why when I was disconnecting (and > unsubscribing) the 3 topics, when it reached 1 topic only the broker > started > sending the messages. > > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User- > f2341805.html >
Re: [artemis] Naming-Pattern for temporary "reply"-queues and exclusive permissions
What protocol or API are you using for your request-reply work? Off the top of my head I wouldn't expect the auto-create attributes would need to be true in order to create temporary queues. Justin On Thu, Mar 22, 2018 at 11:29 AM, Big Puritz wrote: > Hello, > > as far as i can see, while using the "requst-reply" pattern the broker > creates a temporary "reply"-queue with the name according to the UUID > naming pattern, e.g. ca8f4510-5e58-48e7-a4f0-55abf8a43d8e. > > To be able to create this queues the user is required to have an > appropriate CREATE_NON_DURABLE_QUEUE permission. > > That can be achieved with the following configuration (please correct me if > i'm wrong): > > > ... > true > true > ... > > > >... > > >... > > > > However this configuration makes creation of every non durable queue > possible, not only the temporary one. > > How can I limit the permissions to create temporary queues only? Is there > any possibility to specify the naming-pattern for the temporary queues. > E.g. "temp." or something like this. > > Thanks in advance. >
Question on InactivityMonitor
Hello Team I have one question on inactivity monitor. how wireFormat.maxInactivityDuration value will be set to AbstractInactivityMonitor.connectAttemptTimeout field ? or simply how query parameters provided on url will be converted to set to AbstractInactivityMonitor ? I have checked referances of setConnectAttemptTimeout on inactivitymonitor but not find any clue :( Can anybody please tell me ? -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Re: Older Message Not Consumed(Stay Untouched in queue) Newer Messages consumed
I reported the same problem for 5.13.4. http://activemq.2283324.n4.nabble.com/Message-stuck-in-queue-td4720713.html -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Re: Migratiion of Queue data from HornetQ to Artemis 2.x
hi Clebert, Any finding why this thread dump is occuring all of sudden. - DKumar -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
