Thanks Michael.
On Fri, Dec 8, 2017 at 10:52 AM, Michael André Pearce <
michael.andre.pea...@me.com> wrote:
> Just to clear on my comment much earlier on, it’s my feeling about it
> only. I’m not strongly opinionated thus I didn’t -1 or +1 it, maybe I
> should have +0 it, I personally wouldn’t ch
Note that I'm doing much of this for the first time, and not finding
examples on the website, so I expect there's a good chance I'm missing
something.
Summary of the problem:
* Clients get pinned to a single broker url when attempting to connect,
when using infinite connect attempts.
Backgroun
. I am Typing on the phone now.
>
> On Fri, Dec 8, 2017 at 4:01 PM Arthur Naseef wrote:
>
> > Note that I'm doing much of this for the first time, and not finding
> > examples on the website, so I expect there's a good chance I'm missing
> > something
11:02 PM Arthur Naseef wrote:
>
> > Thanks Clebert. Reconnect-at-any-node sounds very similar - the only
> real
> > difference is the "initial connection" versus reconnect.
> >
>
> Initial connect could always look at other nodes.
>
> >
> > In
gt; On Sun, Dec 10, 2017 at 7:44 AM, Clebert Suconic <
> > clebert.suco...@gmail.com>
> > wrote:
> >
> > > On Sat, Dec 9, 2017 at 11:02 PM Arthur Naseef wrote:
> > >
> > > > Thanks Clebert. Reconnect-at-any-node sounds very similar - the only
> > &
JMS queues automatically load share across consumers. Make sure to set
prefetch size to 1 to get the level of fairness in distribution that you'll
want for this use-case.
For the chat portion, have you looked at a chat-based solution? The
messaging for chat is a specific pattern - point-to-point
+1
On Wed, Dec 13, 2017 at 2:59 PM, Clebert Suconic
wrote:
> I would like to propose making Apollo a read only project.
>
> People can always fork it and maintain it themselves... but as of now
> we haven't had anyone maintaining for the past 2 years.
>
> We would make it read only... and would
+1
Let's do both. Website update and making the repo read-only.
Art
On Wed, Dec 13, 2017 at 9:16 PM, Bruce Snyder
wrote:
> What exactly is the point of this making it read-only? And how exactly do
> you suggest it be deprecated? Given that the vast majority of users
> probably would not see
I like removing it.
One concern comes to mind - this really is a non-backward-compatible
change, right? Do we bump the major version number, or do we ignore
semantic versioning?
I know that can get into a bigger discussion - I'm not trying to open a can
of worms. However, I do think we need to
-store is deprecated was one
> > motivator. Fwiw, there are a couple of issues in mqtt and unit tests as
> > well. A (not so) secret goal I have is to get the Jenkins builds back on
> > green. Contributions appreciated :).
> >
> > Cheers,
> > Hadrian
> >
> >
&
I might be able to make it then. Probably 50/50. That week involves
travel for me.
Art
On Wed, Dec 20, 2017 at 3:49 PM, Clebert Suconic
wrote:
> What about Jan-9th, 3PM EST?
>
> On Tue, Dec 19, 2017 at 8:37 AM, Bruce Snyder
> wrote:
> > Can we schedule something now so that the time is bloc
In the console, can you see the connection for the inactive subscriber?
On Wed, Jan 3, 2018 at 12:30 AM, sonikrish wrote:
> package activeMQ;
>
> import org.eclipse.paho.client.mqttv3.IMqttDeliveryToken;
> import org.eclipse.paho.client.mqttv3.MqttCallback;
> import org.eclipse.paho.client.mqttv
If I'm understanding the discussion well enough (apologies, TLDR) - one
concern with adding this directly into core Artemis is ending up with too
much complexity baked into the main product. Also, Mixing Concerns (i.e.
reduced "separation of concerns").
Having a downstream project that integrates
Thanks Clebert. Looking forward to seeing the video.
Art
On Sat, Jan 27, 2018 at 5:01 PM, Clebert Suconic
wrote:
> I had some technical dificulteis to compile a video. I will try again this
> week.
>
> On Sat, Jan 27, 2018 at 4:53 PM Jiri Danek wrote:
>
> > On Wed, Jan 10, 2018 at 7:11 PM,
The presence of those queues suggests an application is using those
destination names. Deleting those queues won't stop applications from
recreating them.
So first thing is to track down where those queues are being created.
There may be a way to prevent the creation of these odd queue names via
I know how to create a docker image, and do so with a maven build.
And getting an image into a registry isn't too hard. That's the "docker
push" command. I suspect the docker-maven-plugin may be able to do that as
part of a build.
The part I don't know is how it can be published to a central do
Looking at TcpTransport, I can see that it accepts both remoteLocation and
localLocation.
If localLocation is defined, it binds the local end of the socket to that
address.
As for the logic in the factory, I'm still trying to decipher it fully.
Art
On Fri, Mar 16, 2018 at 1:20 PM, Max-Julian P
OK, try a url like this:
tcp://localhost:61616/localhost:56565
You'll find it connects to localhost:61616 and binds to localhost:56565
I don't see any documentation on the website for this feature though.
Art
On Fri, Mar 16, 2018 at 2:27 PM, Arthur Naseef wrote:
> Looking at
Starting at the end and working back. This code is very old (and stable).
I wouldn't touch it unless we proved there was a problem with it.
As for the "auto" transport - I've never used it. I find that the simple
'failover' + 'tcp' works great. I suspect, based on the name, the auto
transport i
If you want to create a PR for just the log message, I would merge it.
Terse code comments that help clarify what it's doing would be welcome as
well. Perhaps a comment that clarifies the format is
://:/:...
Art
On Fri, Mar 16, 2018 at 3:47 PM, Max-Julian Pogner
wrote:
>
>
> Starting at the
There are reasons this can happen normally.
Some questions:
1. Is a network-of-brokers being used?
2. What is the inflight message count for the queue?
3. Are there any consumers active on the queue?
4. Are message groups being used?
5. Are selectors being used?
On Thu, Mar 22, 2018 at 4:31 AM
I pulled down Michael's git repo and browsed it. Here are my initial
impressions:
The Good
* The look-and-feel is a little cleaner than the existing site
* I see a lot of promise with this new layout.
The Bad
* While I believe it is expected at this point, I feel it needs to be said
-- a lot of
's a
> great first example.
>
> Nothing is complete. He is giving us an early preview.
>
> Bruce
>
>> On Thu, Mar 22, 2018 at 11:28 AM, Arthur Naseef wrote:
>>
>> I pulled down Michael's git repo and browsed it. Here are my initial
>> impression
The ActiveMQ WebConsole fills a very important role in the solution.
So here are the questions coming to mind when reading the request for
deprecation:
1. What changed since last opening this question?
2. What problems are being solved by removing it?
3. How will the important functions
gt; I believe Chris is proposing that it be deprecated and disabled by
> default
> >> rather than removed. The problem solved by this is ostensibly that users
> >> would understand it is no longer maintained (i.e. de facto truth) and
> that
> >> there are risks ass
at 2:27 PM, Clebert Suconic
> wrote:
> > This is not about opinions.. it's a fact.. people either fix it.. .or
> > deprecate it! Simple!
> >
> >
> > If no one is fixing it.. it will be deprecated.. I don't think this
> > even requires a voting as this is
I'd like to propose the following approach for the WebConsole:
- AMQ adopts the position that the web console is for internal use only
and that exposing it to third parties is not recommended due to possible
vulnerabilities (I've personally always held this view and made this
recommend
I'm concerned that the KahaDB became corrupted in the first place and
recommend solving that problem. After all, if you end up replicating a
corrupt KahaDB, that won't help much. And even with replication of an
uncorrupt image, recovering when the main store becomes corrupt would lead
to redelive
When working with javax.jms.Message, the typical solution is to detect and
cast to the specific message type.
For example:
if (message instanceof TextMessage) {
TextMessage textMessage = (TextMessage) message;
textMessage.getText();
}
Hope this helps.
Art
On Wed, May 9, 2018 at 1:
Hey Alexander - pull requests can be submitted by anybody via github; no
special permissions needed.
By "create issues" - do you mean on github, or jira? For github, I believe
it's open. For Jira, I would need to research whether non-Apache folks can
create Jira entries, and what it would take t
Just a thought that I hope helps...
Please be careful about serialization and deserialization of objects. Lots
of security issues arise when using object serialization/deserialization in
practice. Also, compatibility issues creep up.
Sending a text format over the wire, such as JSON, is typical
My recommendation is to use the Failover transport and the
TransportListener interface.
To use the failover transport, just use the following syntax for the broker
url:
failover://(*_original_broker_url_*)
For example, with a broker at localhost:61616,
failover://(tcp://localhost:61616), wil
Try turning the broker and client logging up to trace and see what the
logging shows for the message content.
Also, try the following:
- Same test with a Java producer (using plain ActiveMQ libs) instead of the
Scala producer
- Same test with a Java consumer (using plain ActiveMQ libs) instead of
gt;> The main problem is you have multiple threads (3 consumers) at the same
> >> time calling getText() on the text message and there is a race condition
> >> where it will set the content to null during it.
> >>
> >> I created a very simple test case to sho
Sounds like that is getting into details that JMS intends to handle.
At some level, every application is going to need to chose between the
possibility of duplicating a message, or losing a message. There is no way
to 100% avoid both cases at the same time. With that said, ActiveMQ has
duplicate
Ahh, I bet that is a result of using the VM transport. The broker is
likely doing the "beforeMarshal()" call that clears the text just before
the client is calling "getText()" on the same message - or just before
"copy()" is called to make a copy of the message.
Yeah, looking at the code carefull
Just my personal opinion here... If you have all the release artifacts
ready to publish, and it's simply a matter of a recoverable Nexus failure,
then go ahead an re-publish. As long as the integrity of the release is
intact.
Is there a concern with an unrecoverable Nexus failure?
Art
On Fri,
Re-reading through my email backlog, I noticed this.
ActiveMQ already provides that type of persistence and guarantee of
delivery. Any additional implementation seems redundant - unless there are
some mitigating factors.
Art
On Fri, Jun 1, 2018 at 3:24 AM, gerardl wrote:
> Thanks Art. Some g
t; by one thread at a time and copied if necessary which makes sense to me.
> However if adding synchronization does fix the issue then hopefully it will
> at least be a clue as to what the real issue is.
>
> Chris
>
> On Thu, May 31, 2018 at 5:41 PM, Arthur Naseef wrote:
>
>
+1
On Wed, Aug 1, 2018 at 6:59 AM, Johan Edstrom wrote:
> +1 non binding
>
> Sent from my pressure cooker.
>
> > On Aug 1, 2018, at 05:32, Jamie G. wrote:
> >
> > +1 (non-binding)
> >
> > Cheers,
> > Jamie
> > On Tue, Jul 31, 2018 at 1:57 PM Francois Papon
> > wrote:
> >>
> >> +1 (non-binding)
+1
On Fri, Aug 3, 2018 at 4:42 AM, Jamie G. wrote:
> +1 (non-binding)
>
> Cheers,
> Jamie
> On Fri, Aug 3, 2018 at 7:19 AM Jean-Baptiste Onofré
> wrote:
> >
> > +1
> >
> > Regards
> > JB
> >
> > On 03/08/2018 06:18, Francois Papon wrote:
> > > +1 (non-binding)
> > >
> > > Thanks for the release
Thank you Chris. That seems most prudent.
I just looked at the change to the script and found the commit; there may
be a very simple way to fix this:
commit 0036084af6ec930e91927170bdc6cfc1c81b37ff
Author: Alvin Lin
Date: Mon Apr 9 16:53:44 2018 -0700
AMQ-6930 provide options to allow st
; "${ACTIVEMQ_OUT:-/dev/null}" 2>&1 &
It seems the new "ACTIVEMQ_OUT" variable must be defined based on the
commit as-is, making that change non-backward-compatible for anyone with
their own env setup.
Art
On Mon, Aug 6, 2018 at 11:10 AM, Arthur
Try this:
Notice the keyStoreType and trustStoreType attributes.
Art
On Tue, Aug 7, 2018 at 8:09 AM, Justin Bertram wrote:
> I would expect PKCS stores to work fine. Have you tried them and found
> they didn't work?
>
>
> Justin
>
> On Tue, Aug 7, 2018 at 9:59 AM, zollen w
Can we get this commit added to the release? It's currently on the master
branch.
d8c80a98212ee5d73a281483a2f8b3f517465f62
Please let me know what else needs to be done to get it into the release.
Art
On Tue, Aug 7, 2018 at 2:39 PM, Arthur Naseef wrote:
> I found that one issue
> christopher.l.shan...@gmail.com> wrote:
> > >
> > >> I can cancel the vote if you want but I won't be able to re-run a new
> > vote
> > >> for 10 days to 2 weeks. I'm out of the office next week so if I
> start a
> > >&g
The openwire generator is executed by the activemq-client project when the "
openwire-generate" build profile is enabled and the "antrun:run" goal is
executed (according to the comments in the pom):
mvn -P openwire-generate antrun:run
This runs a complex script that appears to ultimately boil do
I don't expect username and password to affect inactivity timeouts.
Inactivity timeouts should only occur when the TCP connection between the
client and broker is somehow excessively slow or stuck (e.g. if packets are
not crossing the network properly).
Versions of the client and server should no
That appears to be the "Apache Portable Runtime" library required by the
ActiveMQ CPP build.
Does the build system have the APR package installed? I believe that's
"yum install apr" for CentOS.
Art
On Wed, Aug 15, 2018 at 10:31 AM, stevent.klingberg <
stevent.klingb...@ge.com> wrote:
> apr-1.
Probably the best approach is the Jolokia endpoint which provides HTTP
(REST-like) access to those values.
If there's a C# compatible means to access those settings via JMX, that
would be good - maybe even preferable.
Art
On Thu, Aug 30, 2018 at 7:00 PM, sridhar.infot...@gmail.com <
sridhar.inf
Looking over the release. I see the fix for AMQ-6954 is working.
The build works when run without any tests. After a few retries, I have
the following tests continually failing:
Tests run: 19, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 173.792
sec <<< FAILURE! - in
org.apache.activemq.br
ogle doc):
https://docs.google.com/document/d/1qRcpqVjfSvPOEZ4vDbTWSOu0PUAnABtvqrOYJSNaaNg/edit?usp=sharing
On Tue, Sep 4, 2018 at 1:41 PM, Arthur Naseef wrote:
> Looking over the release. I see the fix for AMQ-6954 is working.
>
> The build works when run without any tests. After a few retries, I have
> t
+1
Thank you.
On Wed, Oct 24, 2018 at 9:45 AM Daniel Kulp wrote:
> +1
>
> Dan
>
>
> > On Oct 24, 2018, at 10:41 AM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
> >
> > Hi Everyone,
> >
> > I have created the 5.15.7 release and it is ready for a vote.
> >
> > The list of reso
I assume that "filter" here means selectors. If so, my first reaction is
to warn that selectors impose a heavy load on the broker, which can be seen
by monitoring CPU utilization. More subscriptions with more selectors only
adds to the problem. Without selectors or message groups, I have rarely
Are you looking to get queue semantics (competing consumption across
multiple consumers) out of this subscription, or topic semantics (every
consumer gets every message)?
If the later, then you may be able to directly subscribe to the virtual
topic itself, as a regular topic - because it still wor
Improving the existing code is a great goal.
While cleaning up code is nice KahaDB has gotten pretty stable over the
> years and doing a bunch of refactoring just opens it up to new bugs that
> have to be fixed. Fixing bugs is not a problem however I tend to be more
> sensitive to store related c
is
> > > > a very different type of bug than a random web console bug or
> transport
> > > > error that just causes an error with a single client or with a single
> > > > message. Granted the risk of a critical bug being introduced with a
> > > >
heers,
> > >>> Jamie
> > >>> On Thu, Nov 29, 2018 at 8:56 AM Gary Tully
> wrote:
> > >>>>
> > >>>> Hey Arthur,
> > >>>> I am not asserting that they need to be small.
> > >>>> I am pointing out that
I agree. Messaging and Database patterns are very different, with
different optimizations and considerations.
That's why folks often hear me repeat a part of a Jeff Genender's
presentation - "don't use ActiveMQ as a message store".
Messaging is about moving messages as quickly as possible betwe
What is in the library?
Art
On Wed, Jan 30, 2019 at 11:08 AM Clebert Suconic
wrote:
> I thought Since the native project had open scope like I'm proposing,
> it would eventually be useful anywhere that needs a JNI library.
>
> But we can go with activemq-artemis-native. That's fine.
>
> On Wed
Looking at the following file to understand the functionality of the
library, I have a question around the allocation and freeing of iocb's:
activemq-artemis/artemis-native/src/main/c/org_apache_activemq_artemis_jlibaio_LibaioContext.c
Function
Java_org_apache_activemq_artemis_jlibaio_LibaioCont
t
> I foresee being used for other cases where we may need JNI.
>
> On Wed, Jan 30, 2019 at 5:53 PM Arthur Naseef wrote:
>
> > What is in the library?
> >
> > Art
> >
> >
> > On Wed, Jan 30, 2019 at 11:08 AM Clebert Suconic <
> > clebert.suco
t; I have had a few cases where users needed to rebuild it from scratch, and
> bumped into this native issue, which I'm trying to improve here.
> >
> > The native layer build wouldn't have any .so, and the .so would be part
> of the release.
> >
> >
> &g
What are we doing with this thread? Trying to get individual commitments
to putting time into some vague possibility of needed effort in the future?
Just reading this thread is discouraging. I long to be part of a community
that works together to constructively solve problems - real problems. O
> was not looking to attack anyone, if thats what you felt.
>
> Robbie
>
> On Tue, 19 Mar 2019 at 16:49, Arthur Naseef wrote:
> >
> > What are we doing with this thread? Trying to get individual commitments
> > to putting time into some vague possibility of neede
Chatting with Justin about NMS this afternoon, there are some specific
questions that come up. Note the goal here is clarity and updating the
website (thank you Justin for working on the website).
Before jumping into these questions, I want to make clear that I feel
strongly NMS is an important p
It's been a while since I've worked with C++, mangled symbol names and
linking, but I used to be good at it, so I'll help...
When linking the dynamic wrapper library, is the static library being
pulled into the link via "-L... -lactivemq-cpp"? If you can share the
commands used to build, that wou
Sorry Chris, not I. That has been a mystery to me.
I'll poke at the logs briefly and let you know if I have any ideas.
On Thu, Mar 21, 2019 at 3:25 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
> Does anyone know much about how the current website is deployed? There
> seems t
wrapper library:
... -Wl,-Bstatic -lactivemq-cpp -Wl,-Bdynamic ...
Note that I tested a generic dynamic-lib link locally on a mac and the
arguments are a little different; here is what I came up with:
... -Wl,-static -lb -Wl,-dynamic -Wl,-dylib
Art
On Thu, Mar 21, 2019 at 11:55 AM Arthur
move
the SVN repo to GIT, or if a GIT repo of that already exists somewhere else.
Art
On Thu, Mar 21, 2019 at 1:38 PM Arthur Naseef wrote:
> I was looking through that build and trying to find the project that is
> being built, without success.
>
> Can you point me at the build job
es.apache.org/jira/browse/INFRA-18068
>
> But it might be something we need to change (ie the SSL versions are
> mismatched or something) which is why in the other thread I mentioned maybe
> we should just vote and push the new site.
>
> On Thu, Mar 21, 2019 at 3:19 PM Arthur Naseef wr
OK, using an online name demangler, I get the following:
-
_ZN8activemq4core25ActiveMQConnectionFactoryC1ERKN5decaf3net3URIERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESE_
-
activemq::core::ActiveMQConnectionFactory::ActiveMQConnectionFactory(decaf::net::URI
const&, std:
Awesome! Glad I could help.
Art
On Sat, Mar 23, 2019 at 1:16 PM klaus.holst.jacobsen <
klaus.holst.jacob...@gmail.com> wrote:
> Art, thx for the response.
>
> Solved the problem.
> You led me on the way.
>
> I had compiled activemq-cpp on the target system whereas i compiled my
> wrapper libs
Unfortunately, you can't have it both ways with the failover transport as
it cannot know what the application wants.
That is -- either the failover transport tries forever (my preferred
approach), or it fails and stops trying to reconnect after some time.
If you are looking to have individual mes
The error, "bind failed" is often caused by something else listening on the
same port.
Double-check that the port is free. Also double-check the IP address being
bound is valid (0.0.0.0, 127.0.0.1, or a valid IP address on the host).
Art
On Mon, May 20, 2019 at 9:43 AM saddaypally
wrote:
> H
Looking for clarification here. Our projects can depend on LGPL'ed
dependencies, right? Here is my understanding...
LGPL is not GPL, so using it as a library in our project should not force
the license on our software - i.e. we can still release under the Apache
License. We do need to include a
ils would be called out in the LICENCE file, not NOTICE)
>
> Robbie
>
>> On Fri, 7 Jun 2019 at 00:21, Arthur Naseef wrote:
>>
>> Looking for clarification here. Our projects can depend on LGPL'ed
>> dependencies, right? Here is my understanding...
>>
Try 'netstat -an'
It appears something else is already using that port.
On Sat, Jul 27, 2019 at 8:02 AM balan.karuppasamy <
balan.karuppas...@cognizant.com> wrote:
> Hello,
>
> In *conf/activemq.xml* , we have below configuration to connect with remote
> host and port.
>
>
>
> uri="tcp:
While it is possible to improve throughput with batching acks in
transactions, I would recommend to check some other things first. Also
note that transactions can introduce other issues, as I have experienced.
Here are things I recommend to try (forgive me if these have already been
tried):
-
the consumer side.
> > - the message volume your working with
> > When I set to the queue to persistent the throughput on the producer side
> > is 50k msg per second, non persistent its 250k msg per second. The
> consumer
> > side throughput is much slowe
Did you get any feedback on this?
Here are thoughts that come to mind...
The src/main/java/... structure is used by (and "encouraged" by) Maven.
Would the C# sources be built as part of the maven build process? If so,
how do we ensure folks can build the Java sources even when they don't have
th
I would be comfortable to use a maven profile that is disabled by default
together with the plugin to do the C# build.
Any concerns with that approach?
Art
P.S. Apologies if I missed something from your messages Michael - the
spacing on my screen is a mess (looks like lost newlines).
On Tue, A
You should not see any problems with mixing versions. With that said,
please test before rolling out to production. In our history, we have had
a couple of unintentional version-mismatch issues arise, so they are very
rare, but not impossible.
Art
On Thu, Apr 30, 2020 at 4:04 AM goutamknit wr
-release.html
--
Arthur Naseef
I'm building now. Don't know how quickly it'll get done, so I won't be
surprised if the vote is closed before then.
There is an error in making the activemq-client bundle - any thoughts on
this?
[INFO] --- maven-bundle-plugin:2.3.7:bundle (default-bundle) @
activemq-client ---
java.lang.ArrayIn
repared the
> update to maven-bundle-plugin 4.2.1 allowing us to build using JDK 11
> (targeted for ActiveMQ 5.17.0).
>
> This warning also exists on activemq-5.15.x branch for very very long time.
>
> So, no blocker, and I already fix that.
>
> Regards
> JB
>
> &
I'm just catching up on this thread and didn't read it all thoroughly, so
forgive me if I missed anything.
The idea of using Virtual Topics to meet the JMS 2.0 "named subscriptions"
feature sounds like a good approach.
One question that raises - removal of the queue so ensure it doesn't end up
ab
To clarify, the subject says "move to" which sounds at first like "remove
and replace" - but that's not the intent, right? Just talking about adding
the JakartaEE API and keeping JMS 2.0, correct?
If it's just adding a new API, I have no strong feelings either way.
Art
On Tue, Sep 22, 2020 at
I'm running the build on an Ubuntu system and getting 4 test failures. I
retried 1 and it repeated.
I'll look at the failures more tomorrow. Here are the errors from the test
I retried:
[ERROR]
testStartBrokerUsingXmlConfig1[activemq-leveldb-replicating.xml](org.apache.activemq.config.BrokerXml
gt;
> My bad, I will fix that.
>
> Thanks !
> Regards
> JB
>
> > Le 1 déc. 2020 à 05:00, Arthur Naseef a écrit :
> >
> > I'm running the build on an Ubuntu system and getting 4 test failures. I
> > retried 1 and it repeated.
> >
> > I
So it looks like my build only had 2 test failures. The first we discussed
already. The second is as follows:
[INFO] Running
org.apache.activemq.broker.scheduler.memory.InMemeoryJmsSchedulerTest
[ERROR] Tests run: 8, Failures: 1, Errors: 1, Skipped: 0, Time elapsed:
41.993 s <<< FAILURE! - in
or
Could this have been broken all this time?
Haven't dug into the second problem yet.
Art
On Tue, Dec 1, 2020 at 1:03 PM Arthur Naseef wrote:
> So it looks like my build only had 2 test failures. The first we
> discussed already. The second is
Dec 1, 2020 at 1:48 PM Arthur Naseef wrote:
> Looks like I'm finding 2 problems with the InMemeoryJmsSchedulerTest:
>
>
>1. The ClassCastException in one test, and
>2. "Didn't receive the message" problem in the other.
>
>
> Digging into the C
- the build often fails on Jenkins due to flaky tests
> >
> > So, I started to improve the situation, but it takes sometime and I
> don’t think we should hold releases for non accurate/flaky tests.
> >
> > Thanks again for your feedback, I’m moving forward on release (5.1
t;
> > So, I started to improve the situation, but it takes sometime and I
> don’t think we should hold releases for non accurate/flaky tests.
> >
> > Thanks again for your feedback, I’m moving forward on release (5.15.14
> take #2) and improving the build/tests.
> >
>
I have started to run the build after updating the tag.
Thank you JB.
Art
On Fri, Dec 4, 2020 at 1:20 PM Jamie G. wrote:
> +1
>
> Cheers,
> Jamie
>
> On Fri, Dec 4, 2020 at 9:11 AM Jean-Baptiste Onofre
> wrote:
> >
> > +1 (binding)
> >
> > Regards
> > JB
> >
> > > Le 3 déc. 2020 à 06:03, Jea
Hey JB, I am interested here.
I know many approaches to replication have been tried - with AMQ 5 as well
as Artemis. For example, "LevelDB replicated storage" and "Pure Master
Slave" (where the active broker copied updates to the passive brokers) in
AMQ 5. So I'm curious how the problem is getti
I keep seeing mention of having multiple variations of docker images using
different base images and some thoughts come to mind.
Here are my thoughts:
- Docker staged builds make it easy to copy specific contents from one
base image into a new one, leaving behind unwanted content (e.g. O/S
TLDR; my take here - we discussed making Artemis a TLP long ago, and we
chose this path.
I see the naming can be confusing. And of course, there's the fact that
AMQ 5 is kinda stuck on major version number 5, but we have lived with that
up until now without significant problems.
Was there some o
Art
On Fri, Mar 19, 2021 at 3:28 PM Arthur Naseef wrote:
> TLDR; my take here - we discussed making Artemis a TLP long ago, and we
> chose this path.
>
> I see the naming can be confusing. And of course, there's the fact that
> AMQ 5 is kinda stuck on major version numbe
1 - 100 of 430 matches
Mail list logo