Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1777
@michaelandrepearce
Looking at the changes via Github it seems clean and effective and I admit
I'm a fan of using the "right" collection when needed, but I want to use some
time
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1757
@michaelandrepearce
> What else you think we need do to merge all this? Be good to get it in,
before we crack on with the next thing tbh.
I will love to provide some basic
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1753
I've changed the last few bits and these are some results:
```
THIS PR:
DIRECT:
Throughput writeUTF = 2352 ops/ms
Throughput readUTF = 2123 ops/ms
HEAP:
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
This is what security settings are for e.g. you can set for address A users
can only create non-durable queues. If a client try to create a durable queue
they will get security
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1753
@michaelandrepearce
> is it worth adding the code to handle the offheap now also, just while
its fresh in your mind, and then it be more complete feature
Agree :) I've
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
I created the ARTEMIS issue as a followup to this
https://issues.apache.org/jira/browse/ARTEMIS-1582. We actually have the
use-case that for certain namespaces we want to dictate all
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1753
@franz1981 looks good, ill look to merge this afternoon, just to confirm no
more bits right?
---
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@jostbg from the sounds of that ticket, what you hit was a bug thats been
fixed, the AMQP client should be able to request a durable or non durable
queue, and the AMQP JMS
Yes. And JDBC the pluggable interface point, JDBC is the api. This is just as
ConnectorService is the pluggable interface that’s a feature.
Either we have some provided implementations of the pluggable interfaces that
exist within artemis or none at all.
I really see this as no different. I’m
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
I also don't see much of a difference if a client tries to send a message
to a pre-created non-durable queue and but expects the queue to be durable over
he a message sends to an
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@jostbg there is implications especially for JMS users, basically if a
client requests a shared subscription, it should not marry up to a durable
shared subscription or vice
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@michaelandrepearce What if the first client does not subscribe to any
address but only sends an AMQP message to an address (either a queue or topic
via QPid JMS). Based on what criterias
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
JMS Queue is durable by spec.
---
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
The problem is, that at least when using AMQP the client cannot control if
a durable or non-durable queue is created. The broker always auto-creates
durable queues. We discussed that at
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@jostbg it can, look at the AMQP JMS client, when via JMS you make a
shared subscription, or a shared durable subscription. if the
On the Artemis side look at
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
@stanlyDoge as said earlier for this PR, if it is to go forwards id like to
see
- setting values should be enums, to cater for alternative way round so
people can make
Github user jostbg commented on the issue:
https://github.com/apache/activemq-artemis/pull/1775
I am not trying to annoying or anything, but how is a non-durable queue -
that is auto created the moment the first client tries to use it (in whatever
way) - less JMS compliant than a
My two cents is about consistency of either we do provide integrations with
other products out the box or not.
If the arguments of people not wanting to add Kafka clients to the class path
for ability to link Artemis with Kafka, because it means having to maintain it
(see it’s thread for all
We already have jdnc as a feature.
On Sun, Jan 14, 2018 at 2:47 PM Michael André Pearce <
michael.andre.pea...@me.com> wrote:
> My two cents is about consistency of either we do provide integrations
> with other products out the box or not.
>
> If the arguments of people not wanting to add Kafka
That’s different. We are not implementing JDBC here.
We can still provide a pluggavle interface and have the feature you wrote
plugging into artemis. Even adding examples with dependencies towards it.
I think it was agreed back then.
That’s a different discussion from here though.
On Sun,
Well it kind of is.
are we then saying if a third party lib in this case Derby DB implements an
interface that artemis provides in this case JDBC in the other case
ConnectorService we are happy to depend on it and ship it with artemis?
I really don’t want to upset or annoy you but at the same
21 matches
Mail list logo
