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
> 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 the moment.. but I should
make it by next week.
re.pearce
> >> wrote:
> >>
> >>> Clebert im able to recreate this and also worked out in code why this
> >>> happens. Ill try catch you on irc tomorrow or friday.
> >>>
> >>> Sent from my Samsung Galaxy smartphone.
> >>> --
t;>> happens. Ill try catch you on irc tomorrow or friday.
>>>
>>> Sent from my Samsung Galaxy smartphone.
>>> Original message From: Clebert Suconic <
>>> clebert.suco...@gmail.com> Date: 25/07/2018 20:20 (GMT+00:00) To:
>>> users@active
Galaxy smartphone.
>> Original message ----From: Clebert Suconic <
>> clebert.suco...@gmail.com> Date: 25/07/2018 20:20 (GMT+00:00) To:
>> users@activemq.apache.org Subject: Re: [artemis 2.1.0] taking 30+ minutes
>> to boot & failover
>> Yes.. it
users@activemq.apache.org Subject: Re: [artemis 2.1.0] taking 30+ minutes
> to boot & failover
> Yes.. it should include it.
>
>
> Do you have an example of the API you used with 2.1?
>
>
> I can't write a compatibility test this week.. but if you provide me
> the exampl
Subject: Re: [artemis 2.1.0] taking 30+ minutes to
boot & failover
Yes.. it should include it.
Do you have an example of the API you used with 2.1?
I can't write a compatibility test this week.. but if you provide me
the example I will do it early next week.
In a perfect world, if you
Yes.. it should include it.
Do you have an example of the API you used with 2.1?
I can't write a compatibility test this week.. but if you provide me
the example 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
i tried 2.6.2 this morning to see if that was an improvement from 2.5.0 i
tried a few months ago. unfortunately there was not. it may have failed
much faster than 2.5.0 i dont recall the timing specifics but the error is
the same
11:15:50,853 ERROR [org.apache.activemq.artemis.core.server]
@Dan: what about this:
you provide us a code path that could generate the incompatibility in 2.1.0...
an ultimate deal would be if you produced a compatibility test with
2.1.0 you add some code that will generate the journal with 2.1.0,
and then consume the messages on master (or 2.6.x)...
@dan take a look at the compatibility tests in master.. We're help to
help if you don't understand anything.. it's using ClassLoaders and
Groovy so you can produce stuff with a combination of clients and
servers on 2.1.0 and consume on the current version.
On Wed, Jul 25, 2018 at 12:04 PM,
On Fri, Jul 20, 2018 at 4:47 PM, Dan Langford wrote:
> Thank you that was very helpful. we actually do have an address settings
> entry for each queue. there could be a better pattern for us. but currently
> our automated system for creating queues creates an address setting at the
> same time. i
Thank you that was very helpful. we actually do have an address settings
entry for each queue. there could be a better pattern for us. but currently
our automated system for creating queues creates an address setting at the
same time. i will look into improved patterns.
as far as upgrading goes.
If you do not want to upgrade for any reason export the journal. Cleani
uo. Edit the text and remove the garbage (you will see) manually. Delete
all data and te import.
(Make a backup to be safe of course)
But I still recommend the upgrade.
On Fri, Jul 20, 2018 at 10:54 AM Clebert Suconic
The address setting is the garbage I was talking about. Upgrade to the
latest broker and there will be a cleanup done at the load before it
starts.
I highly recommend upgrade.
On Fri, Jul 20, 2018 at 10:05 AM Justin Bertram wrote:
> Analyzing thread dumps like this is pretty simple. I
Analyzing thread dumps like this is pretty simple. I generally just scroll
through and look for long stack-traces with lots of calls from
org.apache.activemq.artemis. In your case every single thread dump has a
thread doing something like this:
"main" #1 prio=5 os_prio=0 tid=0x7f902800eb20
Dang I can’t easily upgrade past 2.1.0 because of the config-delete-queues
deserialization bug introduced in 2.2.0. Unless that bug was squashed in
2.6+. I don’t think I made a jira for it (vacation and work load) but we
discussed it back in April. I should go confirm that bug on 2.6 and make a
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:
> would you be willing to help me translate these thread dumps?
>
> i attached a Zip file with some thread dumps in them. i
The first place I would start is grabbing thread dumps every so often to
see what the broker is actually doing during the 30+ minutes.
Justin
On Fri, Jul 6, 2018 at 11:34 AM, Dan Langford wrote:
> so my server startup times and failover times are growing pretty big. but i
> dont really know
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
20 matches
Mail list logo
