Re: [VOTE] ActiveMQ Artemis 2.23.1

2022-06-19 Thread Benjamin Graf
Hi JB,

I tried to run on the latest Karaf 4.2.16 but starting distro is failing 
because it misses java.beans package to resolve. Maybe more java.* packages 
hiding.

Regards
Benjamin

Am 19. Juni 2022 19:05:37 MESZ schrieb "Jean-Baptiste Onofré" 
:
>Hi Benjamin
>
>are you sure it's really an issue ? If the framework exports the
>java.* packages, artemis bundle should work fine.
>
>Can you elaborate your issue ?
>
>Regards
>JB
>
>On Sun, Jun 19, 2022 at 6:43 PM Benjamin Graf  wrote:
>>
>> Hi,
>>
>> OSGi bundles are not playing well because of update to
>> maven-bundle-plugin > 5.1.4 see
>> https://lists.apache.org/thread/9nl55sbry0bwdqo7cp8651f5vonx8wnt how to fix.
>>
>> Regards,
>>
>> Benjamin
>>
>> On 14.06.2022 22:58, Clebert Suconic wrote:
>> > I would like to propose an Apache ActiveMQ Artemis 2.23.1 release
>> >
>> > This is a small release following up where I added a fix for the following 
>> > bug:
>> >
>> > https://issues.apache.org/jira/browse/ARTEMIS-3856 - Failed to change
>> > channel state to ReadyForWriting :
>> > java.util.ConcurrentModificationException
>> >
>> >
>> >
>> > The release notes is here:
>> > https://activemq.apache.org/components/artemis/download/release-notes-2.23.1
>> >
>> > The commit report is here:
>> > https://activemq.apache.org/components/artemis/download/commit-report-2.23.1
>> >
>> > Source and binary distributions can be found here:
>> > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.23.1
>> >
>> > The Maven repository is here:
>> > https://repository.apache.org/content/repositories/orgapacheactivemq-1254
>> >
>> > In case you want to give it a try with the maven repo on examples:
>> > https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html
>> >
>> >
>> > The source tag:
>> > https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.23.1
>> >
>> > I will update the website after the vote has passed.
>> >
>> >
>> >
>> > [ ] +1 approve this release
>> > [ ] +0 no opinion
>> > [ ] -1 disapprove (and reason why)
>> >
>> >
>> > Here is my +1 Binding vote.
>> >  From - Wed Jun 15 20:30:13 2022
>> > X-Mozilla-Status: 0001
>> > X-Mozilla-Status2: 
>> > Return-Path: 
>> > Authentication-Results:  gmx.net; dkim=fail header.i=@gmail.com
>> > Received: from mxout1-ec2-va.apache.org ([3.227.148.255]) by mx-ha.gmx.net
>> >   (mxgmx016 [212.227.15.9]) with ESMTPS (Nemesis) id 
>> > 1N3JkO-1nbdHW2MN8-010NlF
>> >   for ; Wed, 15 Jun 2022 00:14:24 +0200
>> > Received: from mail.apache.org (mailroute1-lw-us.apache.org 
>> > [207.244.88.153])
>> >   by mxout1-ec2-va.apache.org (ASF Mail Server at 
>> > mxout1-ec2-va.apache.org) with SMTP id B4DD840210
>> >   for ; Tue, 14 Jun 2022 19:44:04 + (UTC)
>> > Received: (qmail 83602 invoked by uid 500); 14 Jun 2022 19:44:04 -
>> > Mailing-List: contact dev-h...@activemq.apache.org; run by ezmlm
>> > Precedence: bulk
>> > List-Help: <mailto:dev-h...@activemq.apache.org>
>> > List-Unsubscribe: <mailto:dev-unsubscr...@activemq.apache.org>
>> > List-Post: <mailto:dev@activemq.apache.org>
>> > List-Id: 
>> > Reply-To: dev@activemq.apache.org
>> > Delivered-To: mailing list dev@activemq.apache.org
>> > Received: (qmail 83590 invoked by uid 99); 14 Jun 2022 19:44:04 -
>> > Received: from spamproc1-he-de.apache.org (HELO 
>> > spamproc1-he-de.apache.org) (116.203.196.100)
>> >  by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jun 2022 19:44:04 
>> > +
>> > Received: from localhost (localhost [127.0.0.1])
>> >   by spamproc1-he-de.apache.org (ASF Mail Server at 
>> > spamproc1-he-de.apache.org) with ESMTP id B2FB61FF3D2
>> >   for ; Tue, 14 Jun 2022 19:44:03 + (UTC)
>> > X-Virus-Scanned: Debian amavisd-new at spamproc1-he-de.apache.org
>> > X-Spam-Flag: NO
>> > X-Spam-Score: -0.009
>> > X-Spam-Level:
>> > X-Spam-Status: No, score=-0.009 tagged_above=-999 required=6.31
>> >   tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
>> >   DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_MSPIKE_H3=0.001,
>> >   RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_

Re: [VOTE] ActiveMQ Artemis 2.23.1

2022-06-19 Thread Benjamin Graf

Hi,

OSGi bundles are not playing well because of update to 
maven-bundle-plugin > 5.1.4 see 
https://lists.apache.org/thread/9nl55sbry0bwdqo7cp8651f5vonx8wnt how to fix.


Regards,

Benjamin

On 14.06.2022 22:58, Clebert Suconic wrote:

I would like to propose an Apache ActiveMQ Artemis 2.23.1 release

This is a small release following up where I added a fix for the following bug:

https://issues.apache.org/jira/browse/ARTEMIS-3856 - Failed to change
channel state to ReadyForWriting :
java.util.ConcurrentModificationException



The release notes is here:
https://activemq.apache.org/components/artemis/download/release-notes-2.23.1

The commit report is here:
https://activemq.apache.org/components/artemis/download/commit-report-2.23.1

Source and binary distributions can be found here:
https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.23.1

The Maven repository is here:
https://repository.apache.org/content/repositories/orgapacheactivemq-1254

In case you want to give it a try with the maven repo on examples:
https://activemq.apache.org/components/artemis/documentation/hacking-guide/validating-releases.html


The source tag:
https://gitbox.apache.org/repos/asf/activemq-artemis.git;a=tag;h=refs/tags/2.23.1

I will update the website after the vote has passed.



[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here is my +1 Binding vote.
 From - Wed Jun 15 20:30:13 2022
X-Mozilla-Status: 0001
X-Mozilla-Status2: 
Return-Path: 
Authentication-Results:  gmx.net; dkim=fail header.i=@gmail.com
Received: from mxout1-ec2-va.apache.org ([3.227.148.255]) by mx-ha.gmx.net
  (mxgmx016 [212.227.15.9]) with ESMTPS (Nemesis) id 1N3JkO-1nbdHW2MN8-010NlF
  for ; Wed, 15 Jun 2022 00:14:24 +0200
Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153])
by mxout1-ec2-va.apache.org (ASF Mail Server at 
mxout1-ec2-va.apache.org) with SMTP id B4DD840210
for ; Tue, 14 Jun 2022 19:44:04 + (UTC)
Received: (qmail 83602 invoked by uid 500); 14 Jun 2022 19:44:04 -
Mailing-List: contact dev-h...@activemq.apache.org; run by ezmlm
Precedence: bulk
List-Help: 
List-Unsubscribe: 
List-Post: 
List-Id: 
Reply-To: dev@activemq.apache.org
Delivered-To: mailing list dev@activemq.apache.org
Received: (qmail 83590 invoked by uid 99); 14 Jun 2022 19:44:04 -
Received: from spamproc1-he-de.apache.org (HELO spamproc1-he-de.apache.org) 
(116.203.196.100)
 by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jun 2022 19:44:04 +
Received: from localhost (localhost [127.0.0.1])
by spamproc1-he-de.apache.org (ASF Mail Server at 
spamproc1-he-de.apache.org) with ESMTP id B2FB61FF3D2
for ; Tue, 14 Jun 2022 19:44:03 + (UTC)
X-Virus-Scanned: Debian amavisd-new at spamproc1-he-de.apache.org
X-Spam-Flag: NO
X-Spam-Score: -0.009
X-Spam-Level:
X-Spam-Status: No, score=-0.009 tagged_above=-999 required=6.31
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_MSPIKE_H3=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01]
autolearn=disabled
Received: from mx1-ec2-va.apache.org ([116.203.227.195])
by localhost (spamproc1-he-de.apache.org [116.203.196.100]) 
(amavisd-new, port 10024)
with ESMTP id PI-yg-FiMBZH for ;
Tue, 14 Jun 2022 19:44:03 + (UTC)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.214.177; 
helo=mail-pl1-f177.google.com; envelope-from=h4v...@gmail.com; 
receiver=
Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com 
[209.85.214.177])
by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) 
with ESMTPS id C683BBC77D
for ; Tue, 14 Jun 2022 19:44:02 + (UTC)
Received: by mail-pl1-f177.google.com with SMTP id r1so8571881plo.10
 for ; Tue, 14 Jun 2022 12:44:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=+h2ejVbCwroBP8xTGNhOEWuZMbRFgRaR2JHNuBlgA68=;
 b=RJy8faDKXjEq90Ynrp0/EMDp1mEWfla+SzhlJRQu5zCSma1xS2yW9+v+HOzuuyLerN
  /r5ukEp3myPrztrZdTtNWhlXLthSe7fGNKNFBieo+5Xq+IynNieTbYGR7ATMK+uD7Bqq
  m/OWDWqQNOmpZVKc04bV3vZ4y2Dw8jO29xAWxVjkxkHvjFmUA5kxslFrlrW7UZksAnLv
  /IozL4lliT4wdw5xUzisJ5AgPVJwwlPyjyD+fg4adHuECMzDK35MLUKgI2+oyy2ZdMAd
  UA1OYZVsyuNYOk1y3gsGk8OW93RP8WPxOSMo8xV6mwJSyL0Rl9n6untBIMPPBb+oRHN/
  lKlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
  :message-id:subject:to;
 bh=+h2ejVbCwroBP8xTGNhOEWuZMbRFgRaR2JHNuBlgA68=;
 

Aw: Re: ActiveMQ 5.16.4 and 5.17.0 releases

2022-01-26 Thread Benjamin Graf
Hi,
 
just a little look in the future. What about JMS 3.0 API. I just read that 
Spring Boot has dropped support for ActiveMQ Classic broker because of missing 
JMS 3.0 feature. This might affect many users by the end of this year.
 
Regards,
Benjamin

Gesendet: Dienstag, 25. Januar 2022 um 21:53 Uhr
Von: "Matt Pavlovich" 
An: dev@activemq.apache.org
Betreff: Re: ActiveMQ 5.16.4 and 5.17.0 releases
No prob, thanks!

> On Jan 25, 2022, at 1:22 PM, Christopher Shannon 
>  wrote:
>
> Also, sorry about the delay on the review. I know you tagged me on it a
> couple months ago (I got the email for it). I meant to take a look earlier
> but I got distracted with stuff at work and then the holidays last month so
> forgot about it until JB mentioned doing the release coming up. At least
> it's better to review it now before the vote gets called :)
>
> Anyways, even with the delay I still want to make sure it's properly
> reviewed as it's the foundation of the JMS 2.0 changes. It would be good to
> make sure it's compliant and makes sense before we merge it and release it.
>
> I tagged Tim and Robbie on the PR to take a look and get any feedback.
>
> On Tue, Jan 25, 2022 at 1:54 PM Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
>> I was mostly referring to trying to add in any new commits (not that
>> existing PR) that had big changes (like you said shared subscriptions,
>> etc). Small stuff should be ok and we already had discussed using
>> Unsupported exceptions for most things as the way to go for the first pass.
>> That existing PR looked ok to me when I first took a look. I would probably
>> want someone like Tim or Robbie to take a look as they have a lot more
>> experience with the JMS 2.0 stuff from having to make QPID compliant.
>>
>>
>> On Tue, Jan 25, 2022 at 12:16 PM Matt Pavlovich 
>> wrote:
>>
>>> Hi Christain-
>>>
>>> The first impl PR has been out there for almost 2 months now. Push back
>>> on that PR would be frustrating ;-)
>>>
>>> Please give this a look over: https://github.com/apache/activemq/pull/729
>>>
>>> The next round should be out this week so they are available for review
>>> for 3 - 7 days (or more) before the release. Overall the general
>>> implementation tasks are pretty straight forward— its just not a ton of
>>> code. Big things like shared subscription probably not in for 5.17.0..
>>> smaller things like getting body as a class, delivery delay, and the
>>> CLIENT_ACK callback handling aren’t too crazy.
>>>
>>> I agree from an announcement perspective we work on the language.. JMS
>>> 2.0 support is in-progress and X and Y is what is supported as of release
>>> Z.
>>>
>>> I’ve got a webpage tracking details here that we can also use in release
>>> notes:
>>> https://activemq.apache.org/jms2[https://activemq.apache.org/jms2]
>>>
>>> As we get closer, I’ll update the web page to drop the RC1 indications.
>>> Sounds like JB is targeting a straight-up 5.17.0.
>>>
>>> Thanks,
>>> -Matt Pavlovich
>>>
 On Jan 25, 2022, at 10:05 AM, Christopher Shannon <
>>> christopher.l.shan...@gmail.com> wrote:

 I would say less is better if trying to do the release soon, don't want
>>> to
 rush anything at the last minute. Seems like there is a lot of JMS 2.0
 stuff still outstanding and a lot of back and forth on it so I would
>>> expect
 some pushback depending on what goes into it if it isn't spec compliant,
 etc.

 And again we can't call it a JMS 2.0 implementation in terms of a
>>> feature
 as we are not actually supporting JMS 2.0 if all the operations are just
 UOE. There's no actual functionality being provided other than
>>> supporting
 the Jar (which people can already do)

 On Tue, Jan 25, 2022 at 10:36 AM Matt Pavlovich 
>>> wrote:

> Echoing JB.. no JMS 2.0 API in 5.16.x.
>
> For 5.17.0, the changes for JMS 2.0 API with UOE, and Camel removal
> pre-req are merged into main. The first pass of implemented methods is
> sitting in PR (I’ll merge this week). I originally thought that we’d
>>> need
> more time for JMS 2.0 implementation, but I expect to have most
> functionality in place for the 5.17.0 release.
>
> -Matt Pavlovich
>
>> On Jan 24, 2022, at 8:32 AM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>>
>> The plan is still just to use the Unsupported exceptions for the JMS
>>> 2.0
>> api right?
>>
>> Also, I was having some issues building a test 2.17.0 version as the
>>> test
>> modules have been moved out of the main modules section in the pom.xml
> and
>> moved under a profile called full.test. This is a problem because you
> can't
>> build the project at all the first time. The way to fix it is to still
>> include the modules to be compiled and built all the time but only run
> the
>> tests when the profile is set (so only activate the surefire plugin
>>> when
>> the profile is 

Aw: [DISCUSS] Commits report

2018-05-17 Thread Benjamin Graf
Hi Clebert,
 
this really gives a good overview what happened!
 
big +1
 
Regards
Benjamin
 

Gesendet: Donnerstag, 17. Mai 2018 um 04:52 Uhr
Von: "Clebert Suconic" 
An: dev@activemq.apache.org
Betreff: [DISCUSS] Commits report
Before someone asks on the VOTE Thread.. I wanted to point out that I
made a small project to parse git commit and generate a report.

I have ran the report on top of artemis and I'm adding a commit report
here that can be useful at least on the voter's thread:

https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.6.0/artemis-2.6.0.html



I think it would be useful to have this one on top of the release
report as well. If nobody opposes I would like to add it to the next
release report.

The report generator current lives on my github page but it could be
moved somewhere else if someone bothers about being on my github fork:

https://github.com/clebertsuconic/git-release-report[https://github.com/clebertsuconic/git-release-report]

--
Clebert Suconic


Use Apache ActiveMQ Artemis JDBC Persistence for production

2018-03-20 Thread Benjamin Graf
Hi Clemens,

I would still call it experimental. IMHO ARTEMIS-545 still needs to be
addressed especially for EAP where DS pools are managed.

@all: Does performance test cases exist for JDBC backend like for
regular journal?

Regards,

Benjamin

Am 20.03.2018 um 16:54 schrieb Andy Taylor:
> If your using EAP I would raise this thru the Red Hat support channels.
>
> On 20 March 2018 at 09:26, swclhard  wrote:
>
>> Hi all,
>>
>> So does anybody know about the state of JDBC persistence for Artemis? Is it
>> still experimental like written in the documentation?
>>
>> We have analyzed EAP 7.1 with Artemis. Here we have explicit support only
>> for Oracle12C and no warning in the documentation.
>>
>> Best Regards
>> Clemens
>>
>>
>>
>> --
>> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-
>> f2368404.html
>>






signature.asc
Description: OpenPGP digital signature


[jira] [Created] (AMQ-5344) Replace bundle dependencies with connector feature

2014-09-07 Thread Benjamin Graf (JIRA)
Benjamin Graf created AMQ-5344:
--

 Summary: Replace bundle dependencies with connector feature
 Key: AMQ-5344
 URL: https://issues.apache.org/jira/browse/AMQ-5344
 Project: ActiveMQ
  Issue Type: Improvement
  Components: OSGi/Karaf
Affects Versions: 5.10.0
Reporter: Benjamin Graf
Priority: Minor


Replace:
bundle 
dependency=truemvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/1.0.0/bundle
  bundle 
dependency=truemvn:org.apache.geronimo.specs/geronimo-j2ee-connector_1.5_spec/2.0.0/bundle
with connector feature from karaf to avoid several transaction managers to get 
active.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (AMQ-5247) Implementation forces to set plaintext user and password for activemq.jmx.user/password

2014-06-25 Thread Benjamin Graf (JIRA)
Benjamin Graf created AMQ-5247:
--

 Summary: Implementation forces to set plaintext user and password 
for activemq.jmx.user/password
 Key: AMQ-5247
 URL: https://issues.apache.org/jira/browse/AMQ-5247
 Project: ActiveMQ
  Issue Type: Improvement
  Components: OSGi/Karaf
Affects Versions: 5.10.0
Reporter: Benjamin Graf


Actually karaf based distributions like ServiceMix have user/password for 
activemq commands in plaintext files. It is recommended to crypt credential 
information in karaf but there is no possibility to do for activemq.jmx.*. In 
my opinion activemq-karaf should explicitly set user/password by using realm 
from internal API.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (AMQ-5224) XA pooled connection factories are not recoverable

2014-06-12 Thread Benjamin Graf (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-5224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14029128#comment-14029128
 ] 

Benjamin Graf commented on AMQ-5224:


Reason for recovery working with ActiveMQ pool might be a different usage than 
implemented in Aries TX JMS



e.g.
bean id=internalConnectionFactory 
class=org.apache.activemq.ActiveMQXAConnectionFactory
   argument value=tcp://localhost:61616 /
   property name=userName value=admin /
   property name=password value=admin /
/bean

bean id=connectionFactory 
class=org.apache.activemq.jms.pool.JcaPooledConnectionFactory
 init-method=start destroy-method=stop
   property name=connectionFactory ref=internalConnectionFactory/
   property name=transactionManager ref=transactionManager/
   property name=name value=activemq /
/bean

bean id=resourceManager 
class=org.apache.activemq.jms.pool.GenericResourceManager 
 init-method=recoverResource
   property name=connectionFactory ref=internalConnectionFactory/
   property name=transactionManager ref=transactionManager/
   property name=resourceName value=activemq /
   property name=userName value=admin /
   property name=password value=admin /
/bean

 XA pooled connection factories are not recoverable
 --

 Key: AMQ-5224
 URL: https://issues.apache.org/jira/browse/AMQ-5224
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.9.1, 5.10.0
Reporter: Guillaume Nodet

 PooledConnectionFactory#setConnectionFactory hides the XAConnectionFactory 
 interface which is used by the resource manager.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (AMQ-5223) activemq-jms-pool is missing OSGi metadata

2014-06-12 Thread Benjamin Graf (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14029130#comment-14029130
 ] 

Benjamin Graf commented on AMQ-5223:


activemq-jms-pool is part of the activemq-osgi bundle. That might be the reason 
the artifact doesn't has OSGi metadata itself.

 activemq-jms-pool is missing OSGi metadata
 --

 Key: AMQ-5223
 URL: https://issues.apache.org/jira/browse/AMQ-5223
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.9.1, 5.10.0
Reporter: Guillaume Nodet

 Adding packagingbundepackaging fixes the issue



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Comment Edited] (AMQ-5223) activemq-jms-pool is missing OSGi metadata

2014-06-12 Thread Benjamin Graf (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14029130#comment-14029130
 ] 

Benjamin Graf edited comment on AMQ-5223 at 6/12/14 1:26 PM:
-

activemq-jms-pool is part of the activemq-osgi bundle. That might be the reason 
the artifact doesn't has OSGi metadata itself. Since this pool is generic it 
should be usable without ActiveMQ broker/client independently.


was (Author: graben):
activemq-jms-pool is part of the activemq-osgi bundle. That might be the reason 
the artifact doesn't has OSGi metadata itself.

 activemq-jms-pool is missing OSGi metadata
 --

 Key: AMQ-5223
 URL: https://issues.apache.org/jira/browse/AMQ-5223
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.9.1, 5.10.0
Reporter: Guillaume Nodet

 Adding packagingbundepackaging fixes the issue



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (AMQ-5189) Rollback on XASession when closing back to pool

2014-05-29 Thread Benjamin Graf (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMQ-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Graf updated AMQ-5189:
---

Attachment: vcs-diff962688386413870521.patch

 Rollback on XASession when closing back to pool
 ---

 Key: AMQ-5189
 URL: https://issues.apache.org/jira/browse/AMQ-5189
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-pool
Affects Versions: 5.7.0, 5.8.0, 5.9.0, 5.9.1
 Environment: Windows, UNIX
Reporter: Benjamin Graf
 Attachments: vcs-diff962688386413870521.patch


 If you have a pool of XASession under load (heavy load might be necessary) I 
 register sometimes following Exception Cannot rollback() inside an 
 XASession in afterCompletion synchronisation. After some analysis and 
 patching with logging I recognized that the session object is returned back 
 to pool before setting the xa flag back to false. This leads to the effect 
 that this session gets be used again by another thread while the earlier one 
 switches the xa flag to false.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (AMQ-5189) Rollback on XASession when closing back to pool

2014-05-29 Thread Benjamin Graf (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14012155#comment-14012155
 ] 

Benjamin Graf commented on AMQ-5189:


Patch suggestion

 Rollback on XASession when closing back to pool
 ---

 Key: AMQ-5189
 URL: https://issues.apache.org/jira/browse/AMQ-5189
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-pool
Affects Versions: 5.7.0, 5.8.0, 5.9.0, 5.9.1
 Environment: Windows, UNIX
Reporter: Benjamin Graf
 Attachments: vcs-diff962688386413870521.patch


 If you have a pool of XASession under load (heavy load might be necessary) I 
 register sometimes following Exception Cannot rollback() inside an 
 XASession in afterCompletion synchronisation. After some analysis and 
 patching with logging I recognized that the session object is returned back 
 to pool before setting the xa flag back to false. This leads to the effect 
 that this session gets be used again by another thread while the earlier one 
 switches the xa flag to false.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (AMQ-5189) Rollback on XASession when closing back to pool

2014-05-27 Thread Benjamin Graf (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009517#comment-14009517
 ] 

Benjamin Graf commented on AMQ-5189:


Any feedback on my comment?

 Rollback on XASession when closing back to pool
 ---

 Key: AMQ-5189
 URL: https://issues.apache.org/jira/browse/AMQ-5189
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-pool
Affects Versions: 5.7.0, 5.8.0, 5.9.0, 5.9.1
 Environment: Windows, UNIX
Reporter: Benjamin Graf

 If you have a pool of XASession under load (heavy load might be necessary) I 
 register sometimes following Exception Cannot rollback() inside an 
 XASession in afterCompletion synchronisation. After some analysis and 
 patching with logging I recognized that the session object is returned back 
 to pool before setting the xa flag back to false. This leads to the effect 
 that this session gets be used again by another thread while the earlier one 
 switches the xa flag to false.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (AMQ-5189) Rollback on XASession when closing back to pool

2014-05-19 Thread Benjamin Graf (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002100#comment-14002100
 ] 

Benjamin Graf commented on AMQ-5189:


Since this problem is not deterministic its quite hard to deliver a test case. 
But if you look at the code you can see that this problem does still exist in 
trunk code.
Look at XaConnectionPool line 106 where the close operation on the 
PooledSession object is invoked which returns itself back into the pool in line 
152. But the Synchronization object of XaConnectionPool does still change 
values after that in line 107 and 108 while the pool object might be used again 
in another thread. So it is obvious that a collition can occured!

 Rollback on XASession when closing back to pool
 ---

 Key: AMQ-5189
 URL: https://issues.apache.org/jira/browse/AMQ-5189
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-pool
Affects Versions: 5.7.0, 5.8.0, 5.9.0, 5.9.1
 Environment: Windows, UNIX
Reporter: Benjamin Graf

 If you have a pool of XASession under load (heavy load might be necessary) I 
 register sometimes following Exception Cannot rollback() inside an 
 XASession in afterCompletion synchronisation. After some analysis and 
 patching with logging I recognized that the session object is returned back 
 to pool before setting the xa flag back to false. This leads to the effect 
 that this session gets be used again by another thread while the earlier one 
 switches the xa flag to false.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (AMQ-5189) Rollback on XASession when closing back to pool

2014-05-17 Thread Benjamin Graf (JIRA)

 [ 
https://issues.apache.org/jira/browse/AMQ-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Graf updated AMQ-5189:
---

Affects Version/s: 5.8.0
   5.9.0
   5.9.1

 Rollback on XASession when closing back to pool
 ---

 Key: AMQ-5189
 URL: https://issues.apache.org/jira/browse/AMQ-5189
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-pool
Affects Versions: 5.7.0, 5.8.0, 5.9.0, 5.9.1
 Environment: Windows, UNIX
Reporter: Benjamin Graf

 If you have a pool of XASession under load (heavy load might be necessary) I 
 register sometimes following Exception Cannot rollback() inside an 
 XASession in afterCompletion synchronisation. After some analysis and 
 patching with logging I recognized that the session object is returned back 
 to pool before setting the xa flag back to false. This leads to the effect 
 that this session gets be used again by another thread while the earlier one 
 switches the xa flag to false.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (AMQ-5189) Rollback on XASession when closing back to pool

2014-05-17 Thread Benjamin Graf (JIRA)

[ 
https://issues.apache.org/jira/browse/AMQ-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000709#comment-14000709
 ] 

Benjamin Graf commented on AMQ-5189:


A solution might be to register a PooledSessionEventListener in XA 
synchronisation which does the ignore and xa flagging onSessionClosed.

 Rollback on XASession when closing back to pool
 ---

 Key: AMQ-5189
 URL: https://issues.apache.org/jira/browse/AMQ-5189
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-pool
Affects Versions: 5.7.0, 5.8.0, 5.9.0, 5.9.1
 Environment: Windows, UNIX
Reporter: Benjamin Graf

 If you have a pool of XASession under load (heavy load might be necessary) I 
 register sometimes following Exception Cannot rollback() inside an 
 XASession in afterCompletion synchronisation. After some analysis and 
 patching with logging I recognized that the session object is returned back 
 to pool before setting the xa flag back to false. This leads to the effect 
 that this session gets be used again by another thread while the earlier one 
 switches the xa flag to false.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Created] (AMQ-5189) Rollback on XASession when closing back to pool

2014-05-16 Thread Benjamin Graf (JIRA)
Benjamin Graf created AMQ-5189:
--

 Summary: Rollback on XASession when closing back to pool
 Key: AMQ-5189
 URL: https://issues.apache.org/jira/browse/AMQ-5189
 Project: ActiveMQ
  Issue Type: Bug
  Components: activemq-pool
Affects Versions: 5.7.0
 Environment: Windows, UNIX
Reporter: Benjamin Graf


If you have a pool of XASession under load (heavy load might be necessary) I 
register sometimes following Exception Cannot rollback() inside an XASession 
in afterCompletion synchronisation. After some analysis and patching with 
logging I recognized that the session object is returned back to pool before 
setting the xa flag back to false. This leads to the effect that this session 
gets be used again by another thread while the earlier one switches the xa flag 
to false.



--
This message was sent by Atlassian JIRA
(v6.2#6252)