Tim,
Are you aware of ActiveMQ moving towards using a bulkhead pattern?
Thank you.
Vince
On 7/28/21, 10:53 AM, "Vince Cox" wrote:
Tim,
Since they have experienced such an issue with leader election, they are
requesting implementing a bulk head pattern to increase the res
Tim,
Since they have experienced such an issue with leader election, they are
requesting implementing a bulk head pattern to increase the resiliency of
ActiveMQ
Vince
On 7/12/21, 10:27 AM, "Vince Cox" wrote:
Tim,
I understand your point of view completely. I have a cus
use it since they'd never want multiple SQL databases vs. using
a single database for both purposes, and I'd like to understand why that
assumption is a bad one.
Tim
On Sun, Jul 11, 2021, 7:23 PM Vince Cox wrote:
> Using ActiveMQ 5.15.x & 5.16.x
Using ActiveMQ 5.15.x & 5.16.x I have been unable to get both the locking
mechanism and the data on 2 unique data sources (using oracle)? Having failover
issues if they share the connection pool and data source. Is anyone aware of
how to do this? Is this something ActiveMQ should be able to do?
tomorrow my time.
Regards
JB
> Le 25 mai 2021 à 18:03, Vince Cox a écrit :
>
> JB,
>
> My customer has gone this route and ActiveMQ started, however only the
first data source listed (dsmain in your example) was used. Both the messages
and l
tiveMQ version ?
It might inherit the main ds from the persistence adapter. I will check
tomorrow my time.
Regards
JB
> Le 25 mai 2021 à 18:03, Vince Cox a écrit :
>
> JB,
>
> My customer has gone this route and ActiveMQ started, however only the first
> data source listed
f02c053d0429288b508d91f3367fe%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C637575128536001839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Lwm3sFt4A01ljkYDnNEyw4o0msVoW2xK%2BBO24tToKKo%3D&reserved=0>
Regards
JB
>
6.x series.
Thanks,
Matt Pavlovich
> On May 24, 2021, at 9:21 PM, Vince Cox wrote:
>
> Matt,
>
> We have not noticed any locking. Data server from the DB just fine. But,
the leased locker functionality seems to fail over errantly while using the
pool.
549ab95a38969fbcdc08c%7C0%7C0%7C637575128536001839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Lwm3sFt4A01ljkYDnNEyw4o0msVoW2xK%2BBO24tToKKo%3D&reserved=0>
Regards
JB
> Le 24 mai 2021 à 22:42, Vince Cox a écrit :
>
>
on the connection settings. Also,
they’ll need to coordinate with their DB team to provide some indication as to
why the locking is occurring from the DB point of view.
Thanks,
Matt Pavlovich
> On May 24, 2021, at 7:19 PM, Vince Cox wrote:
>
> Thanks for replying so quickly Matt.
>
detail out the use case and rationale for separating the data
store from the locker? On the surface that sounds like creating an extra
runtime coupling with a distributed system— generally that approach creates
more aggregate downtime.
Thanks,
Matt Pavlovich
> On May 24, 2021, at 3:42 PM,
Are there any future plans with ActiveMQ that will provide separate data source
(using JDBC) to handle leader activity and message traffic? We are aware we can
use kahaDB and JDBC, but we’d like to have a separate JDBC sources for our
message store and our lock.
Thank you.
Vince
This e-mail
12 matches
Mail list logo
