The use case you are trying to achieve is probably best done by using a
transaction instead of individual acknowledgements. If you call rollback
on the session then the message would be available to be redelivered to
another consumer.
On Tue, Jun 9, 2015 at 3:50 AM, spamtrap
, Christopher Shannon
christopher.l.shan...@gmail.com wrote:
The use case you are trying to achieve is probably best done by
using a
transaction instead of individual acknowledgements. If you call
rollback
on the session then the message would be available to be
redelivered to
another
I'm glad that helped. At a quick glance your new code looks pretty good.
The important thing was being able to only send the message to the next
broker so that your broker filter doesn't get called in an infinite loop
and your new code does this. Your new code is also much more efficient
than
to see if it works and if it doesn't have any problems with
it.
And we don't know if it worths the update. But as we are having this
incident we need to think about it.
El 09/06/2015 01:33, Christopher Shannon
christopher.l.shan...@gmail.com
escribió:
The count shouldn't
.
Tim
On Sun, Jun 21, 2015 at 6:40 PM, Christopher Shannon
christopher.l.shan...@gmail.com wrote:
Right, you will continue to receive messages if you process them. The
prefetch size is used as an optimization and doesn't have anything to do
with message acknowledgement. The broker
Right, you will continue to receive messages if you process them. The
prefetch size is used as an optimization and doesn't have anything to do
with message acknowledgement. The broker will always try and keep your
prefetch full on your client so you can quickly consume messages. As you
process
Usually, if you think you might need to rollback a message you should just
want to handle that message in onMessage. What is the reason to share
messages between threads? Is it just to be able to consume more than one
message at a time? If so I would encourage you to just start multiple
.
The question is valid though, @Kevin, what exactly are you trying to
achieve?
Cheers,
Hadrian
On 06/21/2015 09:14 PM, Christopher Shannon wrote:
Usually, if you think you might need to rollback a message you should just
want to handle that message in onMessage. What is the reason to share
Did you set the broker name of the master and slaves to be different? This
is usually the cause of this error. You can set the broker name on the
BrokerService class or from xml you can set it on the broker element.
On Wed, Jun 24, 2015 at 2:26 AM, softwbc soft...@163.com wrote:
ActiveMQ
There should be a nested exception that displays what the real error is.
The BrokerStoppedException is the result of another error and it is hard to
tell what is going on without the real exception causing the issues. Is
there any more to the stack trace?
On Fri, Jun 19, 2015 at 6:36 AM, pubudu
Hi,
It's generally not recommended to use a pool of connections when using a
listener container. Pooled connections are mostly useful for Message
producers. In fact if you look at the documentation for the
DefaultMessageListenerContainer (which is the parent of
that indicated whether this setup included a
container...
Tim
On Jun 26, 2015 10:34 AM, Christopher Shannon
christopher.l.shan...@gmail.com wrote:
Hi,
It's generally not recommended to use a pool of connections when using a
listener container. Pooled connections are mostly useful for Message
Yeah unfortunately it doesn't look possible right now. I pulled up the
source and did some digging and I don't see any current way to specify and
encrypted value. If you want, you can go ahead and put a ticket in on Jira
and I (or someone else) can take a look at it.
On Thu, Jun 18, 2015 at
Anything that goes in activemq.xml can be encrypted because of Spring
support (see http://activemq.apache.org/encrypted-passwords.html)
Unfortunately, I do not believe there is a way to encrypt a password in
the login.config file however.
There is also newer way to use LDAP that you could try
, 2015 at 6:44 AM, spam trap
nospam.1.friedbad...@spamgourmet.com wrote:
On Tue, 9 Jun 2015 10:31:02 -0400, Christopher Shannon
christopher.l.shan...@gmail.com wrote:
OK. Thanks.
Now I am looking at the case where we want messages to be redelivered
to the same consumer (assume there is only one
The ManagedRegionBroker keeps track of subscriptions. Inside that broker
class it keeps track of queueSubscribers and topicSubscribers. The maps
store SubscriptionView objects and they have a method called
getMessageCountAwaitingAcknowledgement() that you could use.
ManagedRegionBroker will be
...@spamgourmet.com wrote:
On Wed, 10 Jun 2015 12:32:00 -0400, Christopher Shannon
christopher.l.shan...@gmail.com wrote:
OK. I've tried this. However when I create the new consumer object,
nothing is consumed and I notice that there are no messages in the
queue to consume.
Any ideas why
No problem, let me know if you have any more questions.
Chris
On Tue, Jun 16, 2015 at 9:13 AM, ALi osat...@gmail.com wrote:
Thank you very nice explanation I will try in this manner
://ActiveMQ.Advisory.Consumer.Queue.TEST.Q,
JMSPriority=0}
perhaps the headers are twice (i dont remember my last editiion) and i dont
see the user in this log (guest)
the username in jmx is null
On Tue, Jun 16, 2015 at 1:42 PM, Christopher Shannon
christopher.l.shan...@gmail.com wrote:
Advisory messages delivered
With individual acknowledgement, if you don't acknowledge the message it
will be kept on the broker and tracked until you either acknowledge it or
close the consumer. If you close the consumer it should be redelivered to
another consumer.
With transactions you need to explicitly call commit or
I'm not entirely sure why it's giving that error, but it could be related
to your version of maven. Just out of curiosity, why are you trying to
build a version that is so old? Would it be possible to upgrade to a more
modern version of ActiveMQ?
On Tue, Jun 16, 2015 at 2:02 PM, bbuzzard
That is an error that was fixed in later versions of ActiveMQ. ActiveMQ
5.8.0 should work because the interface methods in MapContainer have been
changed to fix that error. It has to do with the compiler checking type
erasure and it seems that maybe the newer compilers are stricter about
that.
}, readOnlyProperties = true, readOnlyBody =
true, droppable = false}
20150617-08-33-20
it seems that connection messages arent printable
On Tue, Jun 16, 2015 at 4:00 PM, Christopher Shannon
christopher.l.shan...@gmail.com wrote:
No problem, let me know if you have any
... the connectioninfo is not in the
advisory of connection (perhaps it must be in the connection if i make a
filter but i wanted to do it by configuration just to log the user that
connects to a topic/queue)
On Wed, Jun 17, 2015 at 1:23 PM, Christopher Shannon
christopher.l.shan...@gmail.com wrote
Advisory messages delivered to ActiveMQ.Advisory.Connection will contain a
ConnectionInfo object as part of the data structure field of the message.
That object will contain the user name used for the new connection.
Passwords will always be cleared, however.
On Tue, Jun 16, 2015 at 5:41 AM, ALi
You can't use JDK 8 to build a version that old, try using JDK 6. JDK 7
support was added in ActiveMQ 5.7.0 and JDK 8 support was added in ActiveMQ
5.10.0
On Fri, Jun 12, 2015 at 11:54 AM, bbuzzard billy.buzz...@bnsflogistics.com
wrote:
Yes I know there are newer versions, but I'm trying to
Minor correction...the version in master is 5.12-SNAPSHOT
On Tue, Jun 30, 2015 at 10:39 PM, Christopher Shannon
christopher.l.shan...@gmail.com wrote:
Is the full stack trace in a log file that you could paste? It would make
it easier to track down where the out of bounds exception happened
I don't think there is enough information here to really solve the issue.
The EOFException just means that the clients have been disconnected but it
doesn't say why. It could be a number of reasons including network issues
causing the disconnect or exceptions on message receive, etc. Can you try
The serviceTransportException method only logs what you see. A code change
would be needed to add extra information to the log like connection id.
On Tue, Jun 30, 2015 at 6:17 AM, bansalp bpradee...@gmail.com wrote:
Hi,
I am using ActiveMQ 5.11.1 and getting this error quite often (more as
Does the producer stop sending messages or is the producer still sending
and the Consumer is hung?
If the producer is blocked and waiting it could be flow control kicking on:
http://activemq.apache.org/producer-flow-control.html
On Thu, Aug 20, 2015 at 11:37 AM, Richard Sinek
I just downloaded the release from the apache site and I verified the md5
signature as d04620cbd9912ebfd85c3b4d736ac214
Can you try it again and see if it works for you now?
On Mon, Aug 3, 2015 at 10:10 PM, andrewhelicopter
andrew.mo...@petcircle.com.au wrote:
Hello,
So I've tried to
There is some information here on an old thread:
http://activemq.2283324.n4.nabble.com/Upgrade-from-5-5-1-to-5-9-td4680777.html
On Fri, Jul 31, 2015 at 8:26 AM, geekcoder ravi.chakravar...@gmail.com
wrote:
Hi All,
Planning to a do a upgrade from 5.5.1 to 5.10.2 for our client.
Would like
that problem would
manifest as something visible from within the broker like what Mark has
described, only from the outside when examining the file system.
Tim
On Mon, Jul 27, 2015 at 3:06 PM, Christopher Shannon
christopher.l.shan...@gmail.com wrote:
If you are using KahaDB you might
I don't know the exactly details of your use case but this seems reasonable
to me as long as you account for the fact that messages could still be lost
or not received in a timely matter even if there isn't a broker restart or
lost connection. An example where a message could be lost is if the
You don't need a getter to call a setter with spring injection. Your
problem is your attempting to call a protected setter. Change your
redeliverPolicyMap configuration to:
bean id=redeliveryPolicyMap
class=org.apache.activemq.broker.region.policy.RedeliveryPolicyMap
property
The easiest way to figure out dependencies is probably to just look at the
parent pom that ActiveMQ is using. Here it is on github for 5.11.1
https://github.com/apache/activemq/blob/863e8a5d1ba38f262bdbec4484d704fba8e4f695/pom.xml
Your specific issue is that you have mismatched versions of
I've been thinking about how to improve the speed of builds as well and I
think the biggest thing is just getting the tests to run in parallel,
regardless of whether or not some form of continuous integration is used.
Maven supports parallel tests but it would be more work than just splitting
up
This is a known issue: https://issues.apache.org/jira/browse/AMQ-5356
It has to do with the Jetty version that is being used not playing nicely
with JDK 8. 5.12.0 is going out soon but I plan on upgrading Jetty to a
newer version to fix this problem soon. Probably version 5.13.0. (or maybe
a
If you are using KahaDB you might be running into a limitation of mixing
destinations with fast message rates vs slow message rates. Gary wrote a
good blog post about it here:
http://blog.garytully.com/2011/11/activemq-multiple-kahadb-instances.html
Take a look at that and see if it helps you.
Tim, you are correct. This is an issue with multiple web servers. The
only solution is to upgrade to a newer version of the application/web
server that is having the issue or to downgrade to Java 7. Jetty 7 and 8
also have this problem but Jetty 9 should work, for example.
On Sat, Jul 25, 2015
You need to configure a custom JobSchedulerStore outside the persistence
adapter. You can use the setJobSchedulerStore method in BrokerService or
do this in xml with something like the following:
broker brokerName=static-broker1 dataDirectory=${activemq.data}
persistent=true
I don't have an exact release date but 5.12 is in the process of being
wrapped up right now so it should be released soon.
On Thu, Jul 23, 2015 at 2:39 AM, khandelwalanuj khandelwal.anu...@gmail.com
wrote:
Hi,
I just want to know about ActiveMQ-5.12 release date. It has a very
important fix
First, with your clients, did you call start on the connection? It's a
common mistake and easy forget to do but I'm guessing you did that since it
worked with an embedded broker.
Second, are you connecting with your MessageListener before publishing your
messages or after? Your message consumer
To elaborate on the thread dump, it would be good to know the specific
thread that is using the CPU usage. If using linux, you can run top -H
and that will show you the PID of each of the individual threads. You can
then find the PID with the highest cpu usage and convert it to hex. Then
look
;wireFormat.maxInactivityDuration=0/
/transportConnectors
On Tue, Jul 14, 2015 at 10:37 AM, Jason Vas Dias jason.vas.d...@gmail.com
wrote:
On 14/07/2015, Christopher Shannon christopher.l.shan...@gmail.com
wrote:
The useInactivityMonitor option appears to have been added in 5.3.0
It's difficult to track down the cause based on what you have provided
because unfortunately the full stack trace is missing for the
ArrayIndexOutOfBoundsException. The broker needs to be updated to log the
full stack trace which I can update. I can let you know when the latest
snapshot has that
of the ArrayIndexOutOfBoundsException that you are getting.
On Tue, Jul 14, 2015 at 9:42 AM, Christopher Shannon
christopher.l.shan...@gmail.com wrote:
It's difficult to track down the cause based on what you have provided
because unfortunately the full stack trace is missing
The useInactivityMonitor option appears to have been added in 5.3.0 and
maxInactivityDuration even earlier than that.
You can set the properties on your connection string in the client.
For example:
tcp://localhost:61616?transport.useInactivityMonitor=falsewireformat.
maxInactivityDuration=0
I believe that the expiration task should go ahead and mark the message as
acknowledged if it is expired for each subscription which should mean that
message would no longer prevent a file from being garbage collected. One
thing you can do is you can turn on debug logging for KahaDB to try and
Nevermind, I just double checked the expiration task. It will only browse
up to 400 messages, but expired messages are not counted in that number so
that probably isn't the issue.
On Mon, Oct 26, 2015 at 12:35 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
>
How fast are messages being sent to the topic? By default, the expire
messages task only pages in the max browse page size (which defaults to 400
messages) before stopping. So one thing to check would be if your incoming
message rate is faster than the broker can keep up with expiration.
On
is
described here: http://activemq.apache.org/per-destination-policies.html
On Tue, Nov 10, 2015 at 12:31 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
> Yes, you can listen to the advisory messages for DLQ'd messages. An
> advisory will be sent when a message is
Yes, you can listen to the advisory messages for DLQ'd messages. An
advisory will be sent when a message is moved to DLQ and the advisory will
contain a copy of the message.
The advisory topics to listen on are ActiveMQ.Advisory.MessageDLQd.Queue
and ActiveMQ.Advisory.MessageDLQd.Topic
Take a
This was solved here https://issues.apache.org/jira/browse/AMQ-6038
The problem was commons pool was updated to a new version.
On Wed, Nov 11, 2015 at 9:25 AM, Tim Bain wrote:
> Clearly DBCP isn't on the classpath and the solution is to get it in the
> classpath; the
Hi everyone,
Apache ActiveMQ 5.12.1 has now been released.
This release contains a number of improvements and bug fixes found since
the 5.12.0 release.
A list of issues fixed in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12333269
Which version of the broker and client are you using? If you are using an
older version of the broker or the client you could try updating to newer
versions to see if the problem still exists.
If you are using the newest versions, are you able to reproduce this issue
in a unit test or test case?
Yeah, I got this message last week as well. As you said it seems to be
fine and I continue to get messages.
On Thu, Jul 9, 2015 at 9:40 AM, Tim Bain tb...@alumni.duke.edu wrote:
OK, then I won't bug my email provider about it. Thanks for the
confirmation.
On Thu, Jul 9, 2015 at 7:34 AM,
If you are using JDK 8u31 or greater, SSLv3 is disabled by default. The
typical way to disable a cipher is to use the addExcludeProtocols method on
the ssl context factory, such as:
sslContextFactory.addExcludeProtocols(SSLv3);
I'm not sure if there is an easy way to do this with a websocket
Tim, I think you are referring to this fix here:
https://issues.apache.org/jira/browse/AMQ-4832
Looks like it was done in 5.9.1 and later.
There's also been some other fixes and improvements done in this area
recently so I would definitely recommend upgrading to a more recent version
and giving
You should just use wss://myurl:61616 for your URL. I don't believe you
need the stomp+wss at the end.
On Wed, Aug 26, 2015 at 9:01 PM, ArturoBelano lauraerinm...@gmail.com
wrote:
I configured and restarted activemq according to the documentation to allow
ssl, wss and stomp+ssl (abbrevated
Yeah I can take a look at getting that into 5.13 or 5.12.1. It's kind of a
pain to do because the module is instantiated using reflection so it isn't
as simple as just using the spring encryptor that's already there but I can
figure out something to get the password encryption to work.
On Mon,
What do you mean by "test message from supplier to consumer is 12000"? A
lot of things factor in to the performance of ActiveMQ such as message
size, persistent/non-persistent messages, disk speed, message selectors,
number of consumers and producers, etc. 3000 mps is a reasonable speed
The class can't be found because it isn't part of dbcp 2.
org.apache.commons.dbcp.BasicDataSource is the package for dbcp 1.x not 2.x
Take a look at:
https://commons.apache.org/proper/commons-dbcp/apidocs/org/apache/commons/dbcp2/BasicDataSource.html
You should be using
OpenWire v11 was introduced in 5.12.0.
Can you try using a 5.11.1 client with a 5.12.0 broker? I'm curious to see
if the error still exists if the OpenWire version falls back to v10.
On Sat, Sep 12, 2015 at 11:14 AM, Tim Bain wrote:
> The interesting line in the stack
Your problem is you are always creating a new consumer in your consume()
method but never closing it. So the consumer is sticking around and
hanging onto messages in prefetch. You either need to reuse your message
consumer (call receive() on the same open consumer after rollback because
it's
; > - Prefetch is an issue because you shouldn’t assume it’s going to be
> sent
> > > to a specific connection unless prefetch is 0…
> > >
> > > - The redelivered message is always sent back to the consumer that
> > > originally consumed the message , if it’s sti
I think you can also configure the heart beat in the connect frame of a
STOMP session by setting the heart-beat header.
https://stomp.github.io/stomp-specification-1.1.html#Heart-beating
On Mon, Sep 28, 2015 at 12:14 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
>
There is no option to compact KahaDB. The current solution for the problem
of journal files not being cleaned up is to use multi kahadb. Gary has a
good post about it here
http://blog.garytully.com/2011/11/activemq-multiple-kahadb-instances.html
There's a couple open tickets to add compaction
Yes you can use heartbeats and it gets configured by using the inactivity
monitor settings. There was also a bug just fixed for it in 5.12.0:
https://issues.apache.org/jira/browse/AMQ-5155
To configure this on the server side you just need to set the inactivity
monitor for the timeout period you
What is the exact error message that you are getting? Is there a stack
trace?
On Mon, Sep 21, 2015 at 2:10 PM, neelam wrote:
> Hi All,
>
> I have a requirement where I need to monitor active MQ events. For this I
> have created two Java clients, 1st where I publish the
Another option is to use a mirrored queue to monitor the messages:
http://activemq.apache.org/mirrored-queues.html
On Tue, Oct 6, 2015 at 12:34 AM, Tim Bain wrote:
> Do you have control over the consumer? Can you force it to disconnect
> (e.g. by stopping the client
The auto transport should work but only if the activemq-broker jar is on
the classpath. It would just use OpenWire.
On Mon, Oct 5, 2015 at 9:50 AM, wrote:
> Ill keep you posted as to how the duplex works with ssl...
>
> Regards,
>
> Barry
>
>
> -Original
This is a feature I'd eventually like to get added. There is talk on the
dev list of creating a new sub project for message store related utilities
between ActiveMQ 5.x and Artemis and this is something I think would be
useful to put in there if/when that project gets started.
On Tue, Dec 8,
For a long time OpenWire version 6 was used. With 5.12, that was increased
to the latest version, OpenWire version 11. For KahaDB, on start up the
store should check the index and detect the version as being older and
fallback if using an old store. However, it's probably safest to set the
There was some talk in another thread on the dev list about a possible
donation of AMQC. I had mentioned this in that same thread but if the
project does get donated I would think making it into a separate ActiveMQ
sub project would be best. Then it could support both ActiveMQ 5.x and
eventually
There was some discussion about donating stomp.js to ActiveMQ here:
http://activemq.2283324.n4.nabble.com/Code-donation-for-stomp-js-td4694260.html
I don't think anything ever came of it though.
On Thu, Dec 3, 2015 at 9:47 AM, Basmajian, Raffi
wrote:
> This is really
Hi everyone,
Apache ActiveMQ 5.13.0 has now been released.
This release contains a number of resolved issues and new features since
the 5.12.1 release.
A list of issues resolved in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12329848
ActiveMQ 5.13.0 has been upgraded to the latest Jetty 9.2.x version. It
has been released and will be formally announced as soon as the binaries
are mirrored everywhere (by tomorrow).
On Thu, Dec 3, 2015 at 11:31 AM, A.Marchand wrote:
> In fact, the password never
Yup, this is correct. commons-dbcp was upgraded to commons-dbcp2
On Tue, Dec 15, 2015 at 10:52 AM, Kai B wrote:
> ActiveMQ seems to come with commonc-dbcp2, so you should use
> org.apache.commons.dbcp2.BasicDataSource as your datasource:
>
>
Did this used to work in an older version of ActiveMQ, such as 5.12.1? If
so, you can open up a JIRA and I will take a look.
It's possible there is a regression here because a lot of changes were made
when the upgrade was done from Jetty 8 to Jetty 9.2 since there are API
incompatibilities
Also, this fix will be included in 5.12.2 as well when that is released.
On Wed, Dec 9, 2015 at 5:41 AM, Dejan Bosanac wrote:
> Hi Tim, yes, it prevents untrusted classes deserializing inside the broker,
> including when you want to look at them in the web console.
>
>
I would try a newer ActiveMQ version before putting in a JIRA. There were
some fixes in newer versions that are related to message browsing.
On Sun, Dec 20, 2015 at 10:44 AM, Tim Bain wrote:
> The behavior you describe sounds like a bug to me. Since no one responded
>
This is the way KahaDB currently works. There is no way to keep around the
durable subscriptions (other than the index) because then KahaDB would
never be able to GC any files. The main way I can think of to fix this
would be to do some sort of compaction, as Tim pointed out in the comments
of
Multi-KahaDB already separates destinations (if configured that way) into
their own KahaDB store, so I'm not really sure what you mean by separate
durable subscriptions. If a topic has a bunch of offline durables and that
topic is configured to have its own KahaDB instance then it would not
Claus is right, open up a Jira and I or someone else can take a look at
this. I don't know if there will be enough time to put this in before
5.13.0 because I plan on starting the release Monday for that and I'd want
to make sure all the tests run and there would be no unintended issues by
making
gt; > for ActiveMQ..
> >
> > Many thanks in advance.
> >
> > Cheers,
> > David
> >
> > On Sat, Nov 28, 2015 at 1:25 AM, Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> >> Claus is right, open up
Hi Everyone,
Apache ActiveMQ 5.12.2 has been released.
This release contains a number of improvements and bug fixes found since
the 5.12.1 release.
A list of issues fixed in this release is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210=12333874
The
Yes, the buffer was changed to a direct byte buffer for performance
reasons. This was done in https://issues.apache.org/jira/browse/AMQ-6184
I think the best thing you can do for now is to keep increasing the size
and see if it stabilizes. You mentioned that you could see it using 10g
under
If you need JMS 2.0 support you should take a look at Artemis which already
supports it. https://activemq.apache.org/artemis/
On Mon, Jun 6, 2016 at 2:50 PM, stephan.praetsch <
stephan.praet...@googlemail.com> wrote:
> Hi there,
>
> I'd like Unit-Test with the embedded broker for ActiveMQ as
You can also try setting this compiler flag: -XX:-OmitStackTraceInFastThrow
and seeing if that will show the inner stack trace as it might be an
optimization to hide it because log4j should usually log the inner stack
trace.
>From Oracle:
"The compiler in the server VM now provides correct stack
The garbage collection process which determines which files can be garbage
collected is done in the MessageDatabase class that is part of KahaDB. If
you turn on trace logging for
org.apache.activemq.store.kahadb.MessageDatabase then your log file will
spit out a ton of information about the gc
There could be a bug in this case with displaying the name, based on your
description. You could file a Jira but the web console doesn't get much
attention anymore so you might want to see if you can track down the issue
if you have time. Contributions are always welcome if you can figure out
the
Right, there is no inheritance between policies or merging semantics as Tim
pointed out. So if you define a new policy then you need to re-apply all
the settings you want to the new policy as well.
On Fri, Jun 17, 2016 at 9:09 AM, Johan Carlquist wrote:
> Thanks for your reply.
>
The link you have is from version 5.8 and the dependencies have changed
since then. Your best bet is to use a tool like Maven or Gradle and to
declare a dependency on activemq-client to build your application so that
it will pull in all of the correct jars needed transitively. The
dependencies
-core:jar:1.3:test
[INFO] \- org.slf4j:slf4j-log4j12:jar:1.7.13:test
[INFO]\- log4j:log4j:jar:1.2.17:runtime
[INFO]
On Fri, Jun 17, 2016 at 12:28 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
>
FYI, I'm hoping to do a 5.13.1 release in a week or 2 (if everything goes
well and no blockers pop up), at which point you can upgrade to hopefully
solve this issue. 5.14.0 probably won't be out for a while yet.
On Fri, Jan 15, 2016 at 9:13 AM, Tim Bain wrote:
> Another
That 6.0.0-SNAPSHOT has been renamed to Artemis and is located here
https://activemq.apache.org/artemis/ . The latest build off of the current
5.x broker is 5.14-SNAPSHOT.
On Mon, Jan 18, 2016 at 7:10 AM, Sands, Gary wrote:
>
>
That's because Jetty moved the Jaas related classes into a new artifact:
https://repo1.maven.org/maven2/org/eclipse/jetty/jetty-jaas/9.2.13.v20150730/jetty-jaas-9.2.13.v20150730.pom
On Wed, Feb 3, 2016 at 5:09 PM, aanto wrote:
> ActiveMQ 5.13 seems to have an Upgraded Jetty
In JMS a message consumer is tied to a specific destination so what do you
mean by having each consumer receive messages from multiple queues?
On Fri, Feb 5, 2016 at 5:27 AM, Mayank Natani wrote:
> [ Not sure if it is right place to ask :| ]
> I am modelling my queues such
There isn't a specific announcement mailing list. Announcements regarding
releases are typically mailed to the users and the developers list.
On Mon, Feb 8, 2016 at 5:19 AM, Samuel-Succeed <
samuel.odonn...@succeed.co.uk> wrote:
> Hey All,
>
> Sorry if this question has been asked before.
>
> I
1 - 100 of 258 matches
Mail list logo