and forward.
>
> I know there are issues with durable subs needing to be pinned to a
> given broker, but I think the router can quickly get smarter about
> using link names for routing decisions.
>
> What were the other challenges have you encountered?
>
> /gary
>
ticket in case it can be of any help to the devs.
On Thu, Mar 28, 2019 at 12:56 PM Dan Langford wrote:
> I happen to be working on this issue with Mr. Pyle. Is there anybody out
> there successfully working with Artemis colocated backups and scale-down
> that are able to recover a fa
we are using Artemis 2.8.1 and we have 2 nodes in a cluster (Jgroup, TCP
ping, load balancing=On Demand). we build each queue and address on each
node and put address settings and security settings on each node (via the
jolokia http api). the two nodes are behind a single vip so each incoming
conne
e examples in the
> artemis source here
> https://github.com/SethPyle376/colocated-scaledown-problem
>
> I've tested this situation with both replication and shared-store and the
> problem persists. Any help would be great, we need colocated scaledown
> failback working correctly.
>
--
Dan Langford
801.683.0213
http://google.com/profiles/danlangford
specifically
about transactions so I am hopeful that the fix will address even our
current issues.
Since our users are now focusing on this again I will probably build from
master to test the fix
On Tue, Sep 11, 2018 at 4:46 PM Dan Langford wrote:
> Thank you guys so much!
> On Tue, Sep 11, 2018 a
Thank you guys so much!
On Tue, Sep 11, 2018 at 2:50 PM Timothy Bish wrote:
> On 08/30/2018 07:10 PM, Dan Langford wrote:
> > thanks for looking into this. what is the proper way to force for
> testing a
> > redelivery that goes back to the broker without transactions? its
&
g to be because its using recover() which the client
> performs locally.
>
> Robbie
>
> On Wed, 29 Aug 2018 at 06:23, Dan Langford wrote:
> >
> > ok i wrote 3 test files. I don't know the best way to get them to you
> > easily. hopefully
me the
erroneous null character in the message transfer from the broker:
https://lists.apache.org/
thread.html/b1fd9c09a1f66f5529601a8651fbb96585c011b22bbd84e07c4f23b1@%3Cusers.qpid.apache.org%3E
thank you so much for your time
On Tue, Aug 14, 2018 at 1:19 PM Timothy Bish wrote:
> On 08/13
thank you very much for your work on this. i really appreciate it.
On Thu, Aug 23, 2018 at 12:26 PM Clebert Suconic
wrote:
> > what is the timeline on a 2.6.3 or 2.7.0 release?
> >
>
>
> I was supposed to release it next week based on my HEADS up. I'm
> working on some extensive QA and dev at th
pshot of master or 2.6.x (after I merge it of
> > course). Let me know if you need help buildling it.
> >
> > On Wed, Jul 25, 2018 at 5:17 PM, Dan Langford
> wrote:
> >> Michael for the win!
> >> @Clebert im not opposed to coding up a test case it is jus
some of my users are attempting a pattern to deduplicate messages based on
a time window instead of a fixed amount of space (a duplicate id cache)
so far the concept has been working very well. So they send their AMQP
messages (qpid-jms-client) into a Last Value Queue with an appropriate
identifie
ple I will do it early next week.
>
>
> In a perfect world, if you did it .. it would be great :)
>
>
> On Wed, Jul 25, 2018 at 1:40 PM, Dan Langford
> wrote:
> > i tried 2.6.2 this morning to see if that was an improvement from 2.5.0 i
> > tried a few month
e, we can try
> fixing it.
> >
> >
> > What about this idea? that would help you migrate into 2.6.x or master.
> >
> > On Tue, Jul 24, 2018 at 7:25 PM, Clebert Suconic
> > wrote:
> >> On Fri, Jul 20, 2018 at 4:47 PM, Dan Langford
> wrote:
&g
thread?
On Sat, Jul 21, 2018 at 2:34 PM Dan Langford wrote:
> I am to blame for introducing the confusion across threads. Sorry
>
> I know that when I am on 2.1.0 and I have Queues and address settings
> defined via the API at runtime (so they are not defined in the broker.xml)
&
t;> Delete the first line from export.xml (errant logging makes it into the
> >> output). Then start the new instance and run this from the new
> instance's
> >> "bin" directory:
> >>
> >> ./artemis data imp --input /path/to/export.xml
&
oker instance and copy your address-settings, etc.
> over.
>
>
> Justin
>
> On Tue, May 15, 2018 at 3:51 PM, Dan Langford
> wrote:
>
> > i have been heads down for a few weeks with a couple big production
> deploys
> > and unable to come back to this until now
gMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >> at java.lang.reflect.Method.invoke(Method.java:498)
> >> at
> org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:129)
> >> at org.apache.activemq.artemis.boot.Artemis.main(Artemis.ja
jira for that
Thanks
On Thu, Jul 19, 2018 at 5:46 PM Clebert Suconic
wrote:
> There is an issue I remember where the journal would have some dirt that
> was fixed on 2.3/0.
>
> I would ipgrade to 2.6.2.
>
> On Thu, Jul 19, 2018 at 6:34 PM Dan Langford
> wrote:
>
> > w
so my server startup times and failover times are growing pretty big. but i
dont really know where to start looking.
here is a snippet of some logs to show you the time stamps:
08:11:31,801 INFO [org.apache.activemq.artemis.integration.bootstrap]
AMQ101000: Starting ActiveMQ Artemis Server
08:1
upgrade from 2.1 to 2.2 suprised no one
> > else has seen it though including ourselves (we upgraded a long while
> back
> > and don't remember such issue), can you raise a Jira for this.
> >
> >
> >
> >
> > Sent from my Samsung Galaxy smartphone
as an option we would consider switching. a broker
side option would be ideal.
thanks
dan langford
t-value queue and we use the
message expiration as a delivery time and we could "update" the message
expiration time as needed using last-value features.
thanks
dan langford
we are running 2.1.0 and i tried to upgrade to 2.5.0 and ran into some
problems. in an attempt to isolate the problem i rolled things back and
just attempted to upgrade to 2.2.0. The startup exception i saw on both
2.5.0 and 2.2.0 are quite similar.
2.5.0
ERROR [org.apache.activemq.artemis.c
ess here?
>
>
> Justin
>
> On Thu, Sep 21, 2017 at 3:51 PM, Dan Langford
> wrote:
>
> > a quick note and then i will work on providing a more reproducible use
> set
> > of artifacts.
> >
> > > How did you test that?
> >
> > Three things i
Here is what I am doing but my setup is a little different. I happen to be
using ActiveMQ Artemis. I am also in Master/Slave mode and behind a load
balancer. In ActiveMQ Artemis the slave will stop listening on the
necessary ports (5671 for me). My load balancer (which is not ELB) is
configured to
a quick note and then i will work on providing a more reproducible use set
of artifacts.
> How did you test that?
Three things i notice. 1) in the JMX console (viewed via Hawtio/jolokia
api in 2.1, and the skinned version of such in the new 2.3 console [very
nice BTW]) the slave will typically N
Quick Summary: If I make any change at all to the slave broker.xml file the
"configuration reload" feature takes effect and starts/enables the
acceptors on the Slave. This causes the slave to stop backing up the master
and start accepting its own connections. also address and security settings
that
Oh great this is good news. Good in that I'm not crazy and completely inept
and you guys are aware of the situation. I'll make a jira ticket here in a
bit. From our point of view a message is a message is a message while it's
in Artemis and amqp vs core is just a distinction on how one might get a
clustered the QPID libs / AMQP1.0 is all working
great against the artemis broker.
Thanks your your time and consideration.
Dan Langford
29 matches
Mail list logo