[GitHub] sullis commented on issue #1: projects using ActiveMQ: jms-testkit

[GitBox]

sullis commented on issue #1: projects using ActiveMQ:  jms-testkit
URL: https://github.com/apache/activemq-website/pull/1#issuecomment-452179396
 
 
   [jms-testkit] provides a concise Scala API. The API was designed 
specifically for writing unit tests.
   
   => setting up an in-memory broker is 1 line: **val broker = JmsBroker()**
   => setting up an in-memory queue is 1 line: **val queue = JmsQueue()**
   => publishing a message is 1 line: **queue.publishMessage("hello")**
   => inspecting the contents of the queue is 1 line: **queue.toSeq**
   
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] activemq-artemis pull request #2491: ARTEMIS-2217 remove state on clean MQTT...

[onlyMIT]

Github user onlyMIT commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/2491#discussion_r245879352
  
--- Diff: 
artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTSession.java
 ---
@@ -117,14 +118,11 @@ boolean getStopped() {
}
 
boolean isClean() {
-  return isClean;
+  return clean;
}
 
-   void setIsClean(boolean isClean) throws Exception {
-  this.isClean = isClean;
-  if (isClean) {
- clean();
-  }
+   void setClean(boolean clean) throws Exception {
+  this.clean = clean;
--- End diff --

It is necessary to call the "clean()" method to clean up old session 
information when creating a connection.
If it is not cleaned up, when the cleanSession of the last MQTT consumer is 
false, and the cleanSession of the connected MQTT consumer is true, the message 
in the old queue will be consumed, which is actually not allowed.
I think this is why calling "clean()" in the "setIsClean(boolean isClean)" 
method


---

[GitHub] activemq-artemis pull request #2491: ARTEMIS-2217 remove state on clean MQTT...

[onlyMIT]

Github user onlyMIT commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/2491#discussion_r245878622
  
--- Diff: 
artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTSession.java
 ---
@@ -117,14 +118,11 @@ boolean getStopped() {
}
 
boolean isClean() {
-  return isClean;
+  return clean;
}
 
-   void setIsClean(boolean isClean) throws Exception {
-  this.isClean = isClean;
-  if (isClean) {
- clean();
-  }
+   void setClean(boolean clean) throws Exception {
+  this.clean = clean;
--- End diff --

It is necessary to call the "clean()" method to clean up old session 
information when creating a connection.
If it is not cleaned up, when the cleanSession of the last MQTT consumer is 
false, and the cleanSession of the connected MQTT consumer is true, the message 
in the old queue will be consumed, which is actually not allowed.  
I think this is why calling "clean()" in the "setIsClean(boolean isClean)" 
method


---

Re: [PROPOSAL] Migrate to gitbox on January, 9th

[Jean-Baptiste Onofré]

Hi Clebert,

no, the current PRs are still valid and we will be able to merge it
without problem.

Regards
JB

On 07/01/2019 21:09, Clebert Suconic wrote:
> I forgot to ask this on the other thread. Will that affect any of the
> pending Pull Requests on the various projects?
> 
> This shouldn't affect your date. I just want to understand if we need
> to do anything about them.
> 
> On Mon, Jan 7, 2019 at 2:54 PM Jean-Baptiste Onofré  wrote:
>>
>> Hi,
>>
>> as mentioned in the other thread, and in order to give visibility to
>> everyone, I would like to do the move to gitbox on January, 9th.
>>
>> Nothing change: I already the migration on several other projects
>> without problem.
>>
>> Just after the migration, I will update scm section in the pom and
>> update Jenkins.
>>
>> From a committer perspective, the only thing to change is to update git
>> remote to gitbox.
>>
>> So, without objection, I will do the move on January, 9th (or if you
>> think we can do it before, please let me know as I'm ready).
>>
>> Thanks,
>> Regards
>> JB
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
> 
> 
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

[GitHub] activemq-artemis issue #2491: ARTEMIS-2217 remove state on clean MQTT sessio...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/2491
  
IMO this should replace #2485.


---

[GitHub] activemq-artemis issue #2485: ARTEMIS-2217 ‘MQTTSessionState’ in the ‘...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/2485
  
After looking at writing a test for this I thought the solution here was 
not very intuitive so I opened #2491 to address this problem (with a test).


---

[GitHub] activemq-artemis pull request #2491: ARTEMIS-2217 remove state on clean MQTT...

[jbertram]

GitHub user jbertram opened a pull request:

https://github.com/apache/activemq-artemis/pull/2491

ARTEMIS-2217 remove state on clean MQTT session disconnect



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-2217

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/2491.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2491


commit a4d0cf9ab42dd5076b78fb47e3425d11c917db53
Author: Justin Bertram 
Date:   2018-12-29T08:53:04Z

ARTEMIS-2217 remove state on clean MQTT session disconnect




---

[GitHub] activemq-artemis issue #2485: ARTEMIS-2217 ‘MQTTSessionState’ in the ‘...

[onlyMIT]

Github user onlyMIT commented on the issue:

https://github.com/apache/activemq-artemis/pull/2485
  
@jbertram  Nice! Really need more specific test 


---

[GitHub] activemq-artemis issue #2489: ARTEMIS-2220 Fix PageCursorStressTest::testSim...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/2489
  
@franz1981 LGTM then :) merge...merge...merge


---

[GitHub] activemq-artemis issue #2490: V2 196

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/2490
  
@franz1981 great thanks a million :)


---

Re: [PROPOSAL] Migrate to gitbox on January, 9th

[Clebert Suconic]

I forgot to ask this on the other thread. Will that affect any of the
pending Pull Requests on the various projects?

This shouldn't affect your date. I just want to understand if we need
to do anything about them.

On Mon, Jan 7, 2019 at 2:54 PM Jean-Baptiste Onofré  wrote:
>
> Hi,
>
> as mentioned in the other thread, and in order to give visibility to
> everyone, I would like to do the move to gitbox on January, 9th.
>
> Nothing change: I already the migration on several other projects
> without problem.
>
> Just after the migration, I will update scm section in the pom and
> update Jenkins.
>
> From a committer perspective, the only thing to change is to update git
> remote to gitbox.
>
> So, without objection, I will do the move on January, 9th (or if you
> think we can do it before, please let me know as I'm ready).
>
> Thanks,
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com



-- 
Clebert Suconic

[GitHub] activemq-artemis issue #2484: ARTEMIS-2216 Use a specific executor for pageS...

[franz1981]

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2484
  
Yes if @qihongxu agree to give an hand :P re this pr probably make sense to 
include at least the second commit of my PR that was unrelated to the new cache 
impl and was just avoiding an unnecessary query that was always performed...


---

[GitHub] activemq-artemis issue #2490: V2 196

[franz1981]

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2490
  
@mochaelandrepearce sadly haven't had much time today to look into it :( 
Tomorrow I have already scheduled some time in the morning to take a look 
into this


---

[PROPOSAL] Migrate to gitbox on January, 9th

[Jean-Baptiste Onofré]

Hi,

as mentioned in the other thread, and in order to give visibility to
everyone, I would like to do the move to gitbox on January, 9th.

Nothing change: I already the migration on several other projects
without problem.

Just after the migration, I will update scm section in the pom and
update Jenkins.

>From a committer perspective, the only thing to change is to update git
remote to gitbox.

So, without objection, I will do the move on January, 9th (or if you
think we can do it before, please let me know as I'm ready).

Thanks,
Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

[GitHub] activemq-artemis pull request #2467: ARTEMIS-2205 Performance improvements o...

[clebertsuconic]

Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/2467#discussion_r245777806
  
--- Diff: 
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/AMQPConnectionContext.java
 ---
@@ -359,59 +371,77 @@ public boolean flowControl(ReadyListener 
readyListener) {
 
@Override
public void onRemoteOpen(Connection connection) throws Exception {
-  lock();
+  handler.requireHandler();
   try {
- try {
-initInternal();
- } catch (Exception e) {
-log.error("Error init connection", e);
- }
- if (!validateConnection(connection)) {
-connection.close();
- } else {
-connection.setContext(AMQPConnectionContext.this);
-connection.setContainer(containerId);
-connection.setProperties(connectionProperties);
-
connection.setOfferedCapabilities(getConnectionCapabilitiesOffered());
-connection.open();
- }
-  } finally {
- unlock();
+ initInternal();
+  } catch (Exception e) {
+ log.error("Error init connection", e);
+  }
+  if (!validateConnection(connection)) {
+ connection.close();
+  } else {
+ connection.setContext(AMQPConnectionContext.this);
+ connection.setContainer(containerId);
+ connection.setProperties(connectionProperties);
+ 
connection.setOfferedCapabilities(getConnectionCapabilitiesOffered());
+ connection.open();
   }
   initialise();
 
- /*
- * This can be null which is in effect an empty map, also we 
really don't need to check this for in bound connections
- * but its here in case we add support for outbound connections.
- * */
+  /*
+  * This can be null which is in effect an empty map, also we really 
don't need to check this for in bound connections
+  * but its here in case we add support for outbound connections.
+  * */
   if (connection.getRemoteProperties() == null || 
!connection.getRemoteProperties().containsKey(CONNECTION_OPEN_FAILED)) {
  long nextKeepAliveTime = handler.tick(true);
  if (nextKeepAliveTime != 0 && scheduledPool != null) {
-scheduledPool.schedule(new Runnable() {
-   @Override
-   public void run() {
-  Long rescheduleAt = handler.tick(false);
-  if (rescheduleAt == null) {
- // this mean tick could not acquire a lock, we will 
just retry in 10 milliseconds.
- scheduledPool.schedule(this, 10, 
TimeUnit.MILLISECONDS);
-  } else if (rescheduleAt != 0) {
- scheduledPool.schedule(this, rescheduleAt - 
TimeUnit.NANOSECONDS.toMillis(System.nanoTime()), TimeUnit.MILLISECONDS);
-  }
-   }
-}, (nextKeepAliveTime - 
TimeUnit.NANOSECONDS.toMillis(System.nanoTime())), TimeUnit.MILLISECONDS);
+scheduledPool.schedule(new ScheduleRunnable(), 
(nextKeepAliveTime - TimeUnit.NANOSECONDS.toMillis(System.nanoTime())), 
TimeUnit.MILLISECONDS);
  }
   }
}
 
+   class TickerRunnable implements Runnable {
+
+  final ScheduleRunnable scheduleRunnable;
+
+  TickerRunnable(ScheduleRunnable scheduleRunnable) {
+ this.scheduleRunnable = scheduleRunnable;
+  }
+
+  @Override
+  public void run() {
+ try {
+Long rescheduleAt = handler.tick(false);
+if (rescheduleAt == null) {
+   // this mean tick could not acquire a lock, we will just 
retry in 10 milliseconds.
+   scheduledPool.schedule(scheduleRunnable, 10, 
TimeUnit.MILLISECONDS);
+} else if (rescheduleAt != 0) {
+   scheduledPool.schedule(scheduleRunnable, rescheduleAt - 
TimeUnit.NANOSECONDS.toMillis(System.nanoTime()), TimeUnit.MILLISECONDS);
+}
+ } catch (Exception e) {
+log.warn(e.getMessage(), e);
+ }
--- End diff --

I'm removing the catch here. I don't think we need to use specific loggers 
on generic handlers like this though. it was a generic handler.. but it's being 
removed.


---

[GitHub] activemq-artemis issue #2490: V2 196

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/2490
  
@franz1981 did you get a chance to look, do you think this is better than 
original solution? 

Am keen to get this feature into the next release cut.


---

[GitHub] activemq-artemis issue #2484: ARTEMIS-2216 Use a specific executor for pageS...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/2484
  
@franz1981 i think well have to do some more real world testing with it 
(difference between a isolated bench and a full e2e test), with @qihongxu help 
hopefully, it might be something odd that by releasing some performance it 
causes an odd bottleneck somewhere else.

Are you ok, if once full CI passes we merge as is, and continue this on a 
separate pr?


---

Re: [PROPOSAL] Move to gitbox.apache.org

[Clebert Suconic]

No objections.   I want to make a release right after this.  Just need to
know the timing and I can send the heads up after this.

On Mon, Jan 7, 2019 at 1:09 PM Robbie Gemmell 
wrote:

> Infra wanted consensus on the list to be referenced in the request
> JIRA raised to volunteer for migration, so a specific lazy-consensus
> statement would be good, e.g "I'll raise the request for migration
> on/at  if no discussion arises to prompt a change", that way its
> clearly stated for Infra to reference and is generally known by
> everyone when the request process will happen.
>
> The mandated coordinated migrations were said to begin from Wednesday
> (9th), so its probably good to request by then.
>
> Robbie
>
> On Mon, 7 Jan 2019 at 16:49, Jean-Baptiste Onofré  wrote:
> >
> > Hi,
> >
> > I'm ready to do the move.
> >
> > No objection ?
> >
> > Regards
> > JB
> >
> > On 07/01/2019 17:30, Justin Bertram wrote:
> > > Where are we on this? Has anything actually happened yet?
> > >
> > >
> > > Justin
> > >
> > > On Fri, Dec 14, 2018 at 9:22 AM Robbie Gemmell <
> robbie.gemm...@gmail.com>
> > > wrote:
> > >
> > >> For what its worth, I've now been through migration of the various
> > >> Qpid repositories to the Gitbox service, it was very straightforward.
> > >>
> > >> I proposed we migrate shortly after replying below, raised the JIRA
> > >> request yesterday afternoon, Infra did the migrations during the night
> > >> (for me at least), and I then updated the various metadata and links
> > >> in the repos and the website content/build bits today.
> > >>
> > >> Robbie
> > >>
> > >> On Mon, 10 Dec 2018 at 15:31, Robbie Gemmell <
> robbie.gemm...@gmail.com>
> > >> wrote:
> > >>>
> > >>> I agree a formal vote isnt needed but a documented consensus on the
> > >>> mailing list is required in order to be included in the initial
> > >>> voluntary moves, which seems to be what Jean-Baptiste is proposing,
> so
> > >>> it does at minimum need this discussion and probably a direct lazy
> > >>> consensus statement on the matter.
> > >>>
> > >>> I'd echo your comment about being fine with it any time so long as
> > >>> noone is planning an imminent release.
> > >>>
> > >>> Robbie
> > >>>
> > >>> On Fri, 7 Dec 2018 at 17:14, Daniel Kulp  wrote:
> > 
> > 
> >  You don’t need a vote… It’s going to happen one way or another by
> Feb
> > >> 7.
> > 
> >  The only issue is weather to be pro-active and do it now or wait a
> > >> little bit.  If we have releases imminent, I’d say wait till
> after the
> > >> release.   Otherwise, I’m OK at any time.
> > 
> >  Dan
> > 
> > 
> > 
> > > On Dec 7, 2018, at 12:03 PM, Jean-Baptiste Onofré  >
> > >> wrote:
> > >
> > > Hi all,
> > >
> > > Our repositories are currently located on git-wip-us.apache.org.
> > >
> > > This service will be decommissioned in the coming month.
> > >
> > > I'm proposing to move our repositories to gitbox.apache.org.
> > >
> > > I'm volunteer to start a vote, and if OK, I will deal with the
> infra.
> > >
> > > Thoughts ?
> > >
> > > Regards
> > > JB
> > > --
> > > Jean-Baptiste Onofré
> > > jbono...@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> > 
> >  --
> >  Daniel Kulp
> >  dk...@apache.org  -
> http://dankulp.com/blog <
> > >> http://dankulp.com/blog>
> >  Talend Community Coder - http://talend.com <
> http://coders.talend.com/>
> > >>
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>
-- 
Clebert Suconic

[GitHub] activemq-artemis issue #2484: ARTEMIS-2216 Use a specific executor for pageS...

[franz1981]

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2484
  
@michaelandrepearce I would like first to trigger a CI job of some kind, 
maybe @clebertsuconic can help with his superbox (just this time) to get an 
answer sooner?

Re the cache I was thinking already to send another PR, but I have verified 
that is virtually impossible that's the reason of the consumer slow-down. These 
are the numbers of a the bench comparing it with the original version:
```
Benchmark   (size)  (type)   Mode  Cnt  Score   
   Error  Units
CacheBench.getMessage1  32 chunked  thrpt   10  150039261.251 ± 
12504804.694  ops/s
CacheBench.getMessage1  32  linkedlist  thrpt   10   31776755.611 ±  
1405838.635  ops/s
CacheBench.getMessage11024 chunked  thrpt   10   31433127.788 ±  
3902498.303  ops/s
CacheBench.getMessage11024  linkedlist  thrpt   102638404.341 ±   
119171.758  ops/s
CacheBench.getMessage1  102400 chunked  thrpt   10 344799.911 ±
27267.965  ops/s
CacheBench.getMessage1  102400  linkedlist  thrpt   10  20020.925 ±
 5392.418  ops/s
CacheBench.getMessage3  32 chunked  thrpt   10  384605640.192 ± 
35164543.632  ops/s
CacheBench.getMessage3  32  linkedlist  thrpt   10   14124979.510 ±  
2875341.272  ops/s
CacheBench.getMessage31024 chunked  thrpt   10   90418506.375 ±  
4593688.556  ops/s
CacheBench.getMessage31024  linkedlist  thrpt   101562687.000 ±
91433.926  ops/s
CacheBench.getMessage3  102400 chunked  thrpt   10 978575.016 ±
44800.161  ops/s
CacheBench.getMessage3  102400  linkedlist  thrpt   10  21614.717 ±
 5344.742  ops/s
```
Where `getMessage1` is `LivePageCacheImpl::getMessage` called @ random 
positions by 1 thread and 
`getMessage3` is `LivePageCacheImpl::getMessage` called @ random positions 
by 3 threads.
`chunked` is the version and `linkedlist` the original version: the 
difference is quite large and the new version just scale linearly...


---

[GitHub] activemq-artemis issue #2484: ARTEMIS-2216 Use a specific executor for pageS...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/2484
  
@franz1981 based on this, shall we merge this pr as is which is quite 
impressive result at a combined 49.4k.

And then work on livepagecache changes separately? 





---

Re: [PROPOSAL] Move to gitbox.apache.org

[Robbie Gemmell]

Infra wanted consensus on the list to be referenced in the request
JIRA raised to volunteer for migration, so a specific lazy-consensus
statement would be good, e.g "I'll raise the request for migration
on/at  if no discussion arises to prompt a change", that way its
clearly stated for Infra to reference and is generally known by
everyone when the request process will happen.

The mandated coordinated migrations were said to begin from Wednesday
(9th), so its probably good to request by then.

Robbie

On Mon, 7 Jan 2019 at 16:49, Jean-Baptiste Onofré  wrote:
>
> Hi,
>
> I'm ready to do the move.
>
> No objection ?
>
> Regards
> JB
>
> On 07/01/2019 17:30, Justin Bertram wrote:
> > Where are we on this? Has anything actually happened yet?
> >
> >
> > Justin
> >
> > On Fri, Dec 14, 2018 at 9:22 AM Robbie Gemmell 
> > wrote:
> >
> >> For what its worth, I've now been through migration of the various
> >> Qpid repositories to the Gitbox service, it was very straightforward.
> >>
> >> I proposed we migrate shortly after replying below, raised the JIRA
> >> request yesterday afternoon, Infra did the migrations during the night
> >> (for me at least), and I then updated the various metadata and links
> >> in the repos and the website content/build bits today.
> >>
> >> Robbie
> >>
> >> On Mon, 10 Dec 2018 at 15:31, Robbie Gemmell 
> >> wrote:
> >>>
> >>> I agree a formal vote isnt needed but a documented consensus on the
> >>> mailing list is required in order to be included in the initial
> >>> voluntary moves, which seems to be what Jean-Baptiste is proposing, so
> >>> it does at minimum need this discussion and probably a direct lazy
> >>> consensus statement on the matter.
> >>>
> >>> I'd echo your comment about being fine with it any time so long as
> >>> noone is planning an imminent release.
> >>>
> >>> Robbie
> >>>
> >>> On Fri, 7 Dec 2018 at 17:14, Daniel Kulp  wrote:
> 
> 
>  You don’t need a vote… It’s going to happen one way or another by Feb
> >> 7.
> 
>  The only issue is weather to be pro-active and do it now or wait a
> >> little bit.  If we have releases imminent, I’d say wait till after the
> >> release.   Otherwise, I’m OK at any time.
> 
>  Dan
> 
> 
> 
> > On Dec 7, 2018, at 12:03 PM, Jean-Baptiste Onofré 
> >> wrote:
> >
> > Hi all,
> >
> > Our repositories are currently located on git-wip-us.apache.org.
> >
> > This service will be decommissioned in the coming month.
> >
> > I'm proposing to move our repositories to gitbox.apache.org.
> >
> > I'm volunteer to start a vote, and if OK, I will deal with the infra.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> 
>  --
>  Daniel Kulp
>  dk...@apache.org  - http://dankulp.com/blog <
> >> http://dankulp.com/blog>
>  Talend Community Coder - http://talend.com 
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [PROPOSAL] Move to gitbox.apache.org

[Jamie G.]

+1 please go ahead :)
(non-binding)

On Mon, Jan 7, 2019 at 1:19 PM Jean-Baptiste Onofré  wrote:
>
> Hi,
>
> I'm ready to do the move.
>
> No objection ?
>
> Regards
> JB
>
> On 07/01/2019 17:30, Justin Bertram wrote:
> > Where are we on this? Has anything actually happened yet?
> >
> >
> > Justin
> >
> > On Fri, Dec 14, 2018 at 9:22 AM Robbie Gemmell 
> > wrote:
> >
> >> For what its worth, I've now been through migration of the various
> >> Qpid repositories to the Gitbox service, it was very straightforward.
> >>
> >> I proposed we migrate shortly after replying below, raised the JIRA
> >> request yesterday afternoon, Infra did the migrations during the night
> >> (for me at least), and I then updated the various metadata and links
> >> in the repos and the website content/build bits today.
> >>
> >> Robbie
> >>
> >> On Mon, 10 Dec 2018 at 15:31, Robbie Gemmell 
> >> wrote:
> >>>
> >>> I agree a formal vote isnt needed but a documented consensus on the
> >>> mailing list is required in order to be included in the initial
> >>> voluntary moves, which seems to be what Jean-Baptiste is proposing, so
> >>> it does at minimum need this discussion and probably a direct lazy
> >>> consensus statement on the matter.
> >>>
> >>> I'd echo your comment about being fine with it any time so long as
> >>> noone is planning an imminent release.
> >>>
> >>> Robbie
> >>>
> >>> On Fri, 7 Dec 2018 at 17:14, Daniel Kulp  wrote:
> 
> 
>  You don’t need a vote… It’s going to happen one way or another by Feb
> >> 7.
> 
>  The only issue is weather to be pro-active and do it now or wait a
> >> little bit.  If we have releases imminent, I’d say wait till after the
> >> release.   Otherwise, I’m OK at any time.
> 
>  Dan
> 
> 
> 
> > On Dec 7, 2018, at 12:03 PM, Jean-Baptiste Onofré 
> >> wrote:
> >
> > Hi all,
> >
> > Our repositories are currently located on git-wip-us.apache.org.
> >
> > This service will be decommissioned in the coming month.
> >
> > I'm proposing to move our repositories to gitbox.apache.org.
> >
> > I'm volunteer to start a vote, and if OK, I will deal with the infra.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> 
>  --
>  Daniel Kulp
>  dk...@apache.org  - http://dankulp.com/blog <
> >> http://dankulp.com/blog>
>  Talend Community Coder - http://talend.com 
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

[GitHub] jbertram commented on issue #1: projects using ActiveMQ: jms-testkit

[GitBox]

jbertram commented on issue #1: projects using ActiveMQ:  jms-testkit
URL: https://github.com/apache/activemq-website/pull/1#issuecomment-452005514
 
 
   Even after looking at the linked project I can't easily determine what it's 
actually for.  Both the ActiveMQ 5.x and ActiveMQ Artemis brokers are easy to 
use "in memory" so I don't understand why the "jms-testkit" would be necessary. 
Please elaborate on what this project is and why it's useful.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: [PROPOSAL] Move to gitbox.apache.org

[Jean-Baptiste Onofré]

Hi,

I'm ready to do the move.

No objection ?

Regards
JB

On 07/01/2019 17:30, Justin Bertram wrote:
> Where are we on this? Has anything actually happened yet?
> 
> 
> Justin
> 
> On Fri, Dec 14, 2018 at 9:22 AM Robbie Gemmell 
> wrote:
> 
>> For what its worth, I've now been through migration of the various
>> Qpid repositories to the Gitbox service, it was very straightforward.
>>
>> I proposed we migrate shortly after replying below, raised the JIRA
>> request yesterday afternoon, Infra did the migrations during the night
>> (for me at least), and I then updated the various metadata and links
>> in the repos and the website content/build bits today.
>>
>> Robbie
>>
>> On Mon, 10 Dec 2018 at 15:31, Robbie Gemmell 
>> wrote:
>>>
>>> I agree a formal vote isnt needed but a documented consensus on the
>>> mailing list is required in order to be included in the initial
>>> voluntary moves, which seems to be what Jean-Baptiste is proposing, so
>>> it does at minimum need this discussion and probably a direct lazy
>>> consensus statement on the matter.
>>>
>>> I'd echo your comment about being fine with it any time so long as
>>> noone is planning an imminent release.
>>>
>>> Robbie
>>>
>>> On Fri, 7 Dec 2018 at 17:14, Daniel Kulp  wrote:


 You don’t need a vote… It’s going to happen one way or another by Feb
>> 7.

 The only issue is weather to be pro-active and do it now or wait a
>> little bit.  If we have releases imminent, I’d say wait till after the
>> release.   Otherwise, I’m OK at any time.

 Dan



> On Dec 7, 2018, at 12:03 PM, Jean-Baptiste Onofré 
>> wrote:
>
> Hi all,
>
> Our repositories are currently located on git-wip-us.apache.org.
>
> This service will be decommissioned in the coming month.
>
> I'm proposing to move our repositories to gitbox.apache.org.
>
> I'm volunteer to start a vote, and if OK, I will deal with the infra.
>
> Thoughts ?
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

 --
 Daniel Kulp
 dk...@apache.org  - http://dankulp.com/blog <
>> http://dankulp.com/blog>
 Talend Community Coder - http://talend.com 
>>
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [PROPOSAL] Move to gitbox.apache.org

[Justin Bertram]

Where are we on this? Has anything actually happened yet?


Justin

On Fri, Dec 14, 2018 at 9:22 AM Robbie Gemmell 
wrote:

> For what its worth, I've now been through migration of the various
> Qpid repositories to the Gitbox service, it was very straightforward.
>
> I proposed we migrate shortly after replying below, raised the JIRA
> request yesterday afternoon, Infra did the migrations during the night
> (for me at least), and I then updated the various metadata and links
> in the repos and the website content/build bits today.
>
> Robbie
>
> On Mon, 10 Dec 2018 at 15:31, Robbie Gemmell 
> wrote:
> >
> > I agree a formal vote isnt needed but a documented consensus on the
> > mailing list is required in order to be included in the initial
> > voluntary moves, which seems to be what Jean-Baptiste is proposing, so
> > it does at minimum need this discussion and probably a direct lazy
> > consensus statement on the matter.
> >
> > I'd echo your comment about being fine with it any time so long as
> > noone is planning an imminent release.
> >
> > Robbie
> >
> > On Fri, 7 Dec 2018 at 17:14, Daniel Kulp  wrote:
> > >
> > >
> > > You don’t need a vote… It’s going to happen one way or another by Feb
> 7.
> > >
> > > The only issue is weather to be pro-active and do it now or wait a
> little bit.  If we have releases imminent, I’d say wait till after the
> release.   Otherwise, I’m OK at any time.
> > >
> > > Dan
> > >
> > >
> > >
> > > > On Dec 7, 2018, at 12:03 PM, Jean-Baptiste Onofré 
> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > Our repositories are currently located on git-wip-us.apache.org.
> > > >
> > > > This service will be decommissioned in the coming month.
> > > >
> > > > I'm proposing to move our repositories to gitbox.apache.org.
> > > >
> > > > I'm volunteer to start a vote, and if OK, I will deal with the infra.
> > > >
> > > > Thoughts ?
> > > >
> > > > Regards
> > > > JB
> > > > --
> > > > Jean-Baptiste Onofré
> > > > jbono...@apache.org
> > > > http://blog.nanthrax.net
> > > > Talend - http://www.talend.com
> > >
> > > --
> > > Daniel Kulp
> > > dk...@apache.org  - http://dankulp.com/blog <
> http://dankulp.com/blog>
> > > Talend Community Coder - http://talend.com 
>

[GitHub] activemq-artemis issue #2485: ARTEMIS-2217 ‘MQTTSessionState’ in the ‘...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/2485
  
I'm going to look at writing a test for this.


---

[GitHub] activemq-artemis issue #2484: ARTEMIS-2216 Use a specific executor for pageS...

[franz1981]

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2484
  
> A possible explanation might be that in our case consumers were reading 
old pages while producers were writing new pages. There is no intersection 
between these two groups such as a common page being writing by both of 
them.

So why it the consumer side is being slowed down? 
I need to check, but I remember that consumers were querying the live page 
cache, but I could be wrong.


---

[GitHub] activemq-artemis issue #2484: ARTEMIS-2216 Use a specific executor for pageS...

[franz1981]

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2484
  
@qihongxu Sorry to ask twice, but I haven't understood if `Ver no lock & 
new livePageCache` was making uses of this pr 
https://github.com/qihongxu/activemq-artemis/pull/1 


---

[GitHub] activemq-artemis issue #2469: ARTEMIS-2221 avoid unnecessary Bindings instan...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/2469
  
@clebertsuconic, done.


---

[GitHub] activemq-artemis pull request #2475: ARTEMIS-2144 - tx begin failure in ra d...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/2475


---

[GitHub] activemq-artemis issue #2469: NO-JIRA avoid unnecessary Bindings instance cr...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/2469
  
I think this warrants a JIRA.


---

[GitHub] activemq-artemis issue #2489: ARTEMIS-2220 Fix PageCursorStressTest::testSim...

[franz1981]

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2489
  
@michaelandrepearce Already done! I was thinking exactly the same!


---

[GitHub] activemq-artemis issue #2484: ARTEMIS-2216 Use a specific executor for pageS...

[franz1981]

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2484
  
@qihongxu ping! :) I'm too curious :)


---

[GitHub] activemq-artemis issue #2489: ARTEMIS-2220 Fix PageCursorStressTest::testSim...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/2489
  
@franz1981 why not fix up FakeQueue to correctly set it


---

[GitHub] activemq-artemis issue #2490: V2 196

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/2490
  
@franz1981 just ignore class comments, theyre the originals still, ill need 
to change, but wanted to get to you quickly so you have chance to look over. If 
you think this is better ill make final tidyup bits, such as class comments and 
replace the real PR's branch. 


---

[GitHub] activemq-artemis issue #2490: V2 196

[franz1981]

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2490
  
@michaelandrepearce Nice! Will take a look today or max tomorrow :+1: 


---

[GitHub] activemq-artemis pull request #2490: V2 196

[michaelandrepearce]

GitHub user michaelandrepearce opened a pull request:

https://github.com/apache/activemq-artemis/pull/2490

V2 196

@franz1981 an alternative so we don't have to have a copy of 
CopyOnWriteArrayList, it does mean on add or remove consumer we have to invoke 
toArray which causes a copy, but this is not on hot path, so i think we should 
be good, and avoids us having to clone a jvm class.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/michaelandrepearce/activemq-artemis V2-196

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/2490.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2490


commit d731ffe7288cb857fef1b97deff4b7dc18aeb6d7
Author: Michael André Pearce 
Date:   2018-12-31T13:22:02Z

ARTEMIS-196 Implement Consumer Priority

Add consumer priority support
Includes refactor of consumer iterating in QueueImpl to its own logical 
class, to be able to implement.
Add OpenWire JMS Test - taken from ActiveMQ5
Add Core JMS Test
Add AMQP Test
Add Docs

commit b0c775840fc98b5d3f5f3485802de3270c614d9a
Author: Michael André Pearce 
Date:   2019-01-05T09:48:24Z

Extract




---

[GitHub] activemq-artemis issue #2484: ARTEMIS-2216 Use a specific executor for pageS...

[franz1981]

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2484
  
@qihongxu 

> Ver no lock & new livePageCache

Is making use of the last 2 commits I have sent as a PR to your repository?
It sould be way lot faster then `Ver no lock`


---

[GitHub] activemq-artemis issue #2484: ARTEMIS-2216 Use a specific executor for pageS...

[qihongxu]

Github user qihongxu commented on the issue:

https://github.com/apache/activemq-artemis/pull/2484
  
@michaelandrepearce @franz1981 
After we ran tests on both version (one with no lock and the other with new 
LivePageCache & no lock ), the result chart is as below.

  | Send | In Total
-- | -- | --
Ver Original | 30k/12.5k | 32.5k
Ver Modified checkDepage | 31.1k/11.3k | 42.4k
Ver Modified hasNext | 23.8k/23.5k | 47.3k
Ver no lock | **22.9k/26.5k** | **49.4k**
Ver no lock & new livePageCache | **24.5k/22k** | **46.5k**

Tests are implemented with same conditions before. Clients consumed and 
produced on the same queue with 10 million messages in it.
All version are based on Artemis-2214, which cache something in PagedRef.




---