Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/2401
@mtaylor I agree, having percentages is better, and will work for our use
case.
---
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/2401
@michaelandrepearce @mtaylor Ok, just to make sure I understand this, what
we have today:
```
-1
```
would be equivalent to:
```
#
-1
```
Which
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/2401
The use case is covered in
https://issues.apache.org/jira/browse/ARTEMIS-1710
In a cloud-setting, we need to:
a) Have the broker derive (global) limits based on things like
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/2401
As a user, I think the first alternative is the clearest, it explicitly
states the intention and does not change any existing behavior (i.e. auto tune
-1 which we already rely on). In our
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/1955
@jbertram Added/extended the connection tests. I think CI is failing on
something unrelated but please check.
---
GitHub user lulf opened a pull request:
https://github.com/apache/activemq-artemis/pull/1955
Artemis 1748
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/lulf/activemq-artemis ARTEMIS-1748
Alternatively you can review and apply
GitHub user lulf opened a pull request:
https://github.com/apache/activemq-artemis/pull/1768
Use same name for SslHandler as acceptor
See https://issues.apache.org/jira/browse/ARTEMIS-1598
You can merge this pull request into a Git repository by running:
$ git pull https
GitHub user lulf opened a pull request:
https://github.com/apache/activemq-artemis/pull/1280
Don't set routing type if null
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/lulf/activemq-artemis ARTEMIS-1173
Alternativel
GitHub user lulf opened a pull request:
https://github.com/apache/activemq-artemis/pull/1018
ARTEMIS-908: Replace lock by CAS to avoid potential deadlock
The deadlock can happen if the Runnable acquires a lock.
You can merge this pull request into a Git repository by running
GitHub user lulf opened a pull request:
https://github.com/apache/activemq-artemis/pull/1016
ARTEMIS-908: Ensure that connection lock is held when flushing
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/EnMasseProject/activemq
GitHub user lulf opened a pull request:
https://github.com/apache/activemq-artemis/pull/947
ARTEMIS-908: Hold connection lock when issuing credits
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/EnMasseProject/activemq-artemis
GitHub user lulf opened a pull request:
https://github.com/apache/activemq-artemis/pull/882
ARTEMIS-814: Support specifying connection properties
We would like to be able to specify connection properties for outgoing
connections in EnMasse.
You can merge this pull request into a
GitHub user lulf opened a pull request:
https://github.com/apache/activemq-artemis/pull/876
ARTEMIS-814: Refactor client connection and allow adding custom event
handlers
@mtaylor This includes the refactoring and two important additions:
* addEventHandler method on
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/867
@clebertsuconic I'm not able to reproduce the issue. Both with and without
skipTests=true works for me. From the jenkins test run it looks like it timed
out, and I'm not able to fin
GitHub user lulf opened a pull request:
https://github.com/apache/activemq-artemis/pull/867
ARTEMIS-824: Add management routines for connector services
This adds management operations for creating and destroying connector
services at run time. This feature is needed when building a
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/855
@clebertsuconic Added, thanks.
I actually started out trying both the current 'integrated' approach and
using vertx-proton. I decided to go down the current path based aft
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/855
@clebertsuconic In EnMasse(messaging-as-a-service), we use artemis for
addresses that require store-and-forward semantics. Today, in order to have the
broker connected to the router network
GitHub user lulf opened a pull request:
https://github.com/apache/activemq-artemis/pull/855
Support outgoing AMQP connections
@mtaylor This is the initial version. The first commit is something that I
was surprised that was not there, so let me know if it's bad. Without it, I
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/726
@clebertsuconic Great, thanks!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user lulf closed the pull request at:
https://github.com/apache/activemq-artemis/pull/726
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user lulf commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/726#discussion_r76062794
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/jgroups/JChannelManager.java
---
@@ -34,7 +34,7
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/726
i - Created jira: https://issues.apache.org/jira/browse/ARTEMIS-697
ii - I think the test would have to trigger the jgroupsfile path, in which
case it would have to use the network. Unless
Github user lulf commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/726#discussion_r76041070
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/jgroups/JChannelManager.java
---
@@ -34,7 +34,7
Github user lulf closed the pull request at:
https://github.com/apache/activemq-artemis/pull/725
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/725
Closing this as https://github.com/apache/activemq-artemis/pull/727 fixes
my issue.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/726
@belaban Ok, thanks anyway.
I've updated the PR with a fix that is working for me now. I imagine that
ideally broadcast and discovery should not create two channels, and maybe
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/726
@belaban It looks that discovery and broadcast groups create different
channels that will be given different addresses rather using the same channel.
It actually looks like it is running two
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/726
@belaban Actually, now I see that my original fix doesn't work either. From
debugging I see that it ignores messages sent by itself, but it still receives
broadcasts from someone
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/726
@belaban I was a bit too quick when testing this, sorry. Setting
DONT_LOOPBACK doesn't work after all. My jgroups config us using TCP unicast,
in which case its unclear to me fro
Github user lulf commented on the issue:
https://github.com/apache/activemq-artemis/pull/726
@belaban Originally, I used loopback=false in the jgroups config, but that
didn't seem to have the desired effect. Setting the flag on the message works
though, thanks!
Update
GitHub user lulf opened a pull request:
https://github.com/apache/activemq-artemis/pull/726
Ignore jgroup messages coming from itself
In our broker.xml we have a broadcast group, a discovery group and a core
bridge referring to the discovery group to discover other brokers. It
Github user lulf commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/725#discussion_r75256140
--- Diff:
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/ActiveMQServerControlImpl.java
---
@@ -1983,6 +1983,12
GitHub user lulf opened a pull request:
https://github.com/apache/activemq-artemis/pull/725
Add forceShutdown core management operation
This is a proposal of an operation to shutdown not just the artemis server
but the JVM itself. This feature would allow us to avoid creating a
GitHub user lulf opened a pull request:
https://github.com/apache/activemq-artemis/pull/699
Use correct syntax for filter in bridge example
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/lulf/activemq-artemis
lulf/typo-in
34 matches
Mail list logo
