[jira] [Work stopped] (AMQNET-327) Upgrade solution to VisualStudio 2015
[ https://issues.apache.org/jira/browse/AMQNET-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQNET-327 stopped by Jim Gomes. > Upgrade solution to VisualStudio 2015 > - > > Key: AMQNET-327 > URL: https://issues.apache.org/jira/browse/AMQNET-327 > Project: ActiveMQ .Net > Issue Type: Task > Components: ActiveMQ, EMS, MSMQ, NMS, Stomp, WCF >Reporter: Jim Gomes >Assignee: Jim Gomes > Labels: net-2.0, net-3.5, net-4.0, vs2010 > Fix For: 1.8.0 > > Original Estimate: 72h > Time Spent: 2.5h > Remaining Estimate: 66h > > The solution files should be upgraded to VisualStudio 2015. At the same > time, now projects will be created to target specific .NET versions. The > existing projects will be renamed to XXX-net2.0.csproj or XXX-net3.5.csproj, > as appropriate. For example, the vs2008-nms.csproj will be renamed to > vs2015-nms-net2.0.csproj. It will then be duplicated to > vs2015-nms-net4.0.csproj to target the .NET 4.0 framework. Other platform > specific versions can be created on an as-needed basis. These individual > project files will all be included in the single vs2015-nms.sln file. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-750) Artemis Windows Service Fails to Start
[
https://issues.apache.org/jira/browse/ARTEMIS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15526888#comment-15526888
]
Jim Gomes commented on ARTEMIS-750:
---
Considering that ActiveMQ 5.x launcher uses the JAVA_HOME variable, I would say
that it's better to use that instead of relying on the path. Here's the
relevant part from the launcher:
{code}
if "%JAVA_HOME%" == "" goto noJavaHome
if not exist "%JAVA_HOME%\bin\java.exe" goto noJavaHome
if "%_JAVACMD%" == "" set _JAVACMD=%JAVA_HOME%\bin\java.exe
{code}
> Artemis Windows Service Fails to Start
> --
>
> Key: ARTEMIS-750
> URL: https://issues.apache.org/jira/browse/ARTEMIS-750
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Assignee: Justin Bertram
>Priority: Blocker
> Labels: service, windows
> Fix For: 1.5.0
>
> Attachments: errorstartingservice-screenshot.png
>
>
> After installing Artemis as a service successfully using the following
> command-line:
> {{artemis-service install}}
> the service returns an error when I try to start it.
> # Go to the Services control panel
> # select the Artemis service entry
> # right click to bring up the context menu
> # click the Start menu item.
> It looks like it tries to start, but then an error dialog is displayed (see
> attached image). When the service error log is checked, no error is logged.
> The following is logged:
> {noformat}
> 2016-09-23 12:53:32 - Starting java "-Xbootclasspath/a:C:\Program
> Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar"
> -XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M
> -Xmx1024M -classpath "C:\Program
> Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar"
> "-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0"
> -Dartemis.instance=C:\ProgramData\Apache\AMQ
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager
> -Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties
> -Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config
> org.apache.activemq.artemis.boot.Artemis run
> 2016-09-23 12:53:32 - Started 2576
> {noformat}
> When launched from the command-line (not using the service wrapper), Artemis
> will launch and run just fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-749) Version Number Does Not Display for Windows Service
[
https://issues.apache.org/jira/browse/ARTEMIS-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15523724#comment-15523724
]
Jim Gomes commented on ARTEMIS-749:
---
Agreed that those have different semantics. However, if this hostname is
strictly for display, it can be confused for a version number and not an IP
address. I understand that this is just a simple substitution of the ${host}
variable, so the 0.0.0.0 will be carried through. I'm just pointing out that
it is ambiguous in this case. The only reason to address it would be to cut
down on support issues such as this, so it's really minor. I feel like I've
wasted dev resources because I logged the bug.
> Version Number Does Not Display for Windows Service
> ---
>
> Key: ARTEMIS-749
> URL: https://issues.apache.org/jira/browse/ARTEMIS-749
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Minor
> Labels: easyfix, windows
> Fix For: 1.5.0
>
> Attachments: serviceinfo-screenshot.png
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When the Artemis service is registered using
> {{artemis-service install}}
> the registered service name does not display the embedded version number
> correctly. Instead, it displays 0.0.0.0. Please see attached screenshot
> showing the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-749) Version Number Does Not Display for Windows Service
[
https://issues.apache.org/jira/browse/ARTEMIS-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15523674#comment-15523674
]
Jim Gomes commented on ARTEMIS-749:
---
I see. Thank you. From just having zeros, it wasn't clear that was a host IP
address. It looked like a version number (Major.Minor.Rev.Build). This is very
minor, but a potential to avoid that confusion would be to use "localhost" as
the instance name instead of "0.0.0.0". Or perhaps "127.0.0.1".
> Version Number Does Not Display for Windows Service
> ---
>
> Key: ARTEMIS-749
> URL: https://issues.apache.org/jira/browse/ARTEMIS-749
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Minor
> Labels: easyfix, windows
> Fix For: 1.5.0
>
> Attachments: serviceinfo-screenshot.png
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When the Artemis service is registered using
> {{artemis-service install}}
> the registered service name does not display the embedded version number
> correctly. Instead, it displays 0.0.0.0. Please see attached screenshot
> showing the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-750) Artemis Windows Service Fails to Start
[
https://issues.apache.org/jira/browse/ARTEMIS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15517786#comment-15517786
]
Jim Gomes commented on ARTEMIS-750:
---
Yes. If I modify the {{artemis-service.xml}} file to use my JAVA_HOME instance,
it will work. I changed the following line:
{code}
%JAVA_HOME%\bin\java
{code}
> Artemis Windows Service Fails to Start
> --
>
> Key: ARTEMIS-750
> URL: https://issues.apache.org/jira/browse/ARTEMIS-750
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Blocker
> Labels: service, windows
> Fix For: 1.5.0
>
> Attachments: errorstartingservice-screenshot.png
>
>
> After installing Artemis as a service successfully using the following
> command-line:
> {{artemis-service install}}
> the service returns an error when I try to start it.
> # Go to the Services control panel
> # select the Artemis service entry
> # right click to bring up the context menu
> # click the Start menu item.
> It looks like it tries to start, but then an error dialog is displayed (see
> attached image). When the service error log is checked, no error is logged.
> The following is logged:
> {noformat}
> 2016-09-23 12:53:32 - Starting java "-Xbootclasspath/a:C:\Program
> Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar"
> -XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M
> -Xmx1024M -classpath "C:\Program
> Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar"
> "-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0"
> -Dartemis.instance=C:\ProgramData\Apache\AMQ
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager
> -Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties
> -Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config
> org.apache.activemq.artemis.boot.Artemis run
> 2016-09-23 12:53:32 - Started 2576
> {noformat}
> When launched from the command-line (not using the service wrapper), Artemis
> will launch and run just fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ARTEMIS-750) Artemis Windows Service Fails to Start
[
https://issues.apache.org/jira/browse/ARTEMIS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15517764#comment-15517764
]
Jim Gomes edited comment on ARTEMIS-750 at 9/23/16 10:44 PM:
-
This could be my environment being messed up. When I manually run that
command-line from the artemis-service.log, I get a Registry key value error:
{noformat}
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.8', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
{noformat}
This is a little strange, since Artemis will run just fine. Let me fix my
environment settings first.
Update: I think I see the difference. If I explicitly use my JAVA_HOME defined
instance (which is Java 1.8), then it will work. So, I run the following
command-line (assuming all of the parameters from the log output on the command
line):
{noformat}
"%java_home%\bin\java" "-Xbootclasspath/a:C:\Proga"
{noformat}
and it will run.
was (Author: jgomes):
This could be my environment being messed up. When I manually run that
command-line from the artemis-service.log, I get a Registry key value error:
{noformat}
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.8', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
{noformat}
This is a little strange, since Artemis will run just fine. Let me fix my
environment settings first.
> Artemis Windows Service Fails to Start
> --
>
> Key: ARTEMIS-750
> URL: https://issues.apache.org/jira/browse/ARTEMIS-750
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Blocker
> Labels: service, windows
> Fix For: 1.5.0
>
> Attachments: errorstartingservice-screenshot.png
>
>
> After installing Artemis as a service successfully using the following
> command-line:
> {{artemis-service install}}
> the service returns an error when I try to start it.
> # Go to the Services control panel
> # select the Artemis service entry
> # right click to bring up the context menu
> # click the Start menu item.
> It looks like it tries to start, but then an error dialog is displayed (see
> attached image). When the service error log is checked, no error is logged.
> The following is logged:
> {noformat}
> 2016-09-23 12:53:32 - Starting java "-Xbootclasspath/a:C:\Program
> Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar"
> -XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M
> -Xmx1024M -classpath "C:\Program
> Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar"
> "-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0"
> -Dartemis.instance=C:\ProgramData\Apache\AMQ
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager
> -Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties
> -Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config
> org.apache.activemq.artemis.boot.Artemis run
> 2016-09-23 12:53:32 - Started 2576
> {noformat}
> When launched from the command-line (not using the service wrapper), Artemis
> will launch and run just fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-750) Artemis Windows Service Fails to Start
[
https://issues.apache.org/jira/browse/ARTEMIS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15517764#comment-15517764
]
Jim Gomes commented on ARTEMIS-750:
---
This could be my environment being messed up. When I manually run that
command-line from the artemis-service.log, I get a Registry key value error:
{noformat}
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.8', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
{noformat}
This is a little strange, since Artemis will run just fine. Let me fix my
environment settings first.
> Artemis Windows Service Fails to Start
> --
>
> Key: ARTEMIS-750
> URL: https://issues.apache.org/jira/browse/ARTEMIS-750
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Blocker
> Labels: service, windows
> Fix For: 1.5.0
>
> Attachments: errorstartingservice-screenshot.png
>
>
> After installing Artemis as a service successfully using the following
> command-line:
> {{artemis-service install}}
> the service returns an error when I try to start it.
> # Go to the Services control panel
> # select the Artemis service entry
> # right click to bring up the context menu
> # click the Start menu item.
> It looks like it tries to start, but then an error dialog is displayed (see
> attached image). When the service error log is checked, no error is logged.
> The following is logged:
> {noformat}
> 2016-09-23 12:53:32 - Starting java "-Xbootclasspath/a:C:\Program
> Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar"
> -XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M
> -Xmx1024M -classpath "C:\Program
> Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar"
> "-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0"
> -Dartemis.instance=C:\ProgramData\Apache\AMQ
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager
> -Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties
> -Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config
> org.apache.activemq.artemis.boot.Artemis run
> 2016-09-23 12:53:32 - Started 2576
> {noformat}
> When launched from the command-line (not using the service wrapper), Artemis
> will launch and run just fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ARTEMIS-750) Artemis Windows Service Fails to Start
[
https://issues.apache.org/jira/browse/ARTEMIS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15517746#comment-15517746
]
Jim Gomes edited comment on ARTEMIS-750 at 9/23/16 10:30 PM:
-
I can give it a try. I'll look at that file to begin with. Any pointers on
where to look are appreciated, as I'm not familiar with the service wrapper
strategy that Artemis is using.
was (Author: jgomes):
I can give it a try. I'll look at that file to begin with. Any pointers how
where to look are appreciated, as I'm not familiar with the service wrapper
strategy that Artemis is using.
> Artemis Windows Service Fails to Start
> --
>
> Key: ARTEMIS-750
> URL: https://issues.apache.org/jira/browse/ARTEMIS-750
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Blocker
> Labels: service, windows
> Fix For: 1.5.0
>
> Attachments: errorstartingservice-screenshot.png
>
>
> After installing Artemis as a service successfully using the following
> command-line:
> {{artemis-service install}}
> the service returns an error when I try to start it.
> # Go to the Services control panel
> # select the Artemis service entry
> # right click to bring up the context menu
> # click the Start menu item.
> It looks like it tries to start, but then an error dialog is displayed (see
> attached image). When the service error log is checked, no error is logged.
> The following is logged:
> {noformat}
> 2016-09-23 12:53:32 - Starting java "-Xbootclasspath/a:C:\Program
> Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar"
> -XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M
> -Xmx1024M -classpath "C:\Program
> Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar"
> "-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0"
> -Dartemis.instance=C:\ProgramData\Apache\AMQ
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager
> -Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties
> -Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config
> org.apache.activemq.artemis.boot.Artemis run
> 2016-09-23 12:53:32 - Started 2576
> {noformat}
> When launched from the command-line (not using the service wrapper), Artemis
> will launch and run just fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-750) Artemis Windows Service Fails to Start
Jim Gomes created ARTEMIS-750:
-
Summary: Artemis Windows Service Fails to Start
Key: ARTEMIS-750
URL: https://issues.apache.org/jira/browse/ARTEMIS-750
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 1.4.0
Environment: Windows 10 Anniversary Edition, 64-bit
Reporter: Jim Gomes
Priority: Blocker
Fix For: 1.5.0
After installing Artemis as a service successfully using the following
command-line:
{{artemis-service install}}
the service returns an error when I try to start it.
# Go to the Services control panel
# select the Artemis service entry
# right click to bring up the context menu
# click the Start menu item.
It looks like it tries to start, but then an error dialog is displayed (see
attached image). When the service error log is checked, no error is logged.
The following is logged:
{noformat}
2016-09-23 12:53:32 - Starting java "-Xbootclasspath/a:C:\Program
Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar"
-XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M
-Xmx1024M -classpath "C:\Program
Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar"
"-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0"
-Dartemis.instance=C:\ProgramData\Apache\AMQ
-Djava.util.logging.manager=org.jboss.logmanager.LogManager
-Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties
-Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config
org.apache.activemq.artemis.boot.Artemis run
2016-09-23 12:53:32 - Started 2576
{noformat}
When launched from the command-line (not using the service wrapper), Artemis
will launch and run just fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-750) Artemis Windows Service Fails to Start
[
https://issues.apache.org/jira/browse/ARTEMIS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes updated ARTEMIS-750:
--
Attachment: errorstartingservice-screenshot.png
> Artemis Windows Service Fails to Start
> --
>
> Key: ARTEMIS-750
> URL: https://issues.apache.org/jira/browse/ARTEMIS-750
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Blocker
> Labels: service, windows
> Fix For: 1.5.0
>
> Attachments: errorstartingservice-screenshot.png
>
>
> After installing Artemis as a service successfully using the following
> command-line:
> {{artemis-service install}}
> the service returns an error when I try to start it.
> # Go to the Services control panel
> # select the Artemis service entry
> # right click to bring up the context menu
> # click the Start menu item.
> It looks like it tries to start, but then an error dialog is displayed (see
> attached image). When the service error log is checked, no error is logged.
> The following is logged:
> {noformat}
> 2016-09-23 12:53:32 - Starting java "-Xbootclasspath/a:C:\Program
> Files\Apache\apache-artemis-1.4.0\lib\jboss-logmanager-2.0.3.Final.jar"
> -XX:+UseParallelGC -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -Xms512M
> -Xmx1024M -classpath "C:\Program
> Files\Apache\apache-artemis-1.4.0\lib\artemis-boot.jar"
> "-Dartemis.home=C:\Program Files\Apache\apache-artemis-1.4.0"
> -Dartemis.instance=C:\ProgramData\Apache\AMQ
> -Djava.util.logging.manager=org.jboss.logmanager.LogManager
> -Dlogging.configuration=file:C:\ProgramData\Apache\AMQ\etc\logging.properties
> -Djava.security.auth.login.config=C:\ProgramData\Apache\AMQ\etc\login.config
> org.apache.activemq.artemis.boot.Artemis run
> 2016-09-23 12:53:32 - Started 2576
> {noformat}
> When launched from the command-line (not using the service wrapper), Artemis
> will launch and run just fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-749) Version Number Does Not Display for Windows Service
[
https://issues.apache.org/jira/browse/ARTEMIS-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15517400#comment-15517400
]
Jim Gomes commented on ARTEMIS-749:
---
This is using the shipping version of the binaries. I did not build them myself.
> Version Number Does Not Display for Windows Service
> ---
>
> Key: ARTEMIS-749
> URL: https://issues.apache.org/jira/browse/ARTEMIS-749
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Minor
> Labels: easyfix, windows
> Fix For: 1.5.0
>
> Attachments: serviceinfo-screenshot.png
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When the Artemis service is registered using
> {{artemis-service install}}
> the registered service name does not display the embedded version number
> correctly. Instead, it displays 0.0.0.0. Please see attached screenshot
> showing the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-749) Version Number Does Not Display for Windows Service
[
https://issues.apache.org/jira/browse/ARTEMIS-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes updated ARTEMIS-749:
--
Attachment: serviceinfo-screenshot.png
> Version Number Does Not Display for Windows Service
> ---
>
> Key: ARTEMIS-749
> URL: https://issues.apache.org/jira/browse/ARTEMIS-749
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Windows 10 Anniversary Edition, 64-bit
>Reporter: Jim Gomes
>Priority: Minor
> Labels: easyfix, windows
> Fix For: 1.5.0
>
> Attachments: serviceinfo-screenshot.png
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When the Artemis service is registered using
> {{artemis-service install}}
> the registered service name does not display the embedded version number
> correctly. Instead, it displays 0.0.0.0. Please see attached screenshot
> showing the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-749) Version Number Does Not Display for Windows Service
Jim Gomes created ARTEMIS-749:
-
Summary: Version Number Does Not Display for Windows Service
Key: ARTEMIS-749
URL: https://issues.apache.org/jira/browse/ARTEMIS-749
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 1.4.0
Environment: Windows 10 Anniversary Edition, 64-bit
Reporter: Jim Gomes
Priority: Minor
Fix For: 1.5.0
When the Artemis service is registered using
{{artemis-service install}}
the registered service name does not display the embedded version number
correctly. Instead, it displays 0.0.0.0. Please see attached screenshot
showing the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-732) Spurious message while loading native libraries in certain envs.
[
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15496516#comment-15496516
]
Jim Gomes commented on ARTEMIS-732:
---
Yes, changing the script so the 32-bit libraries don't get loaded into the
64-bit runtime makes this error message go away.
> Spurious message while loading native libraries in certain envs.
>
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
>Priority: Blocker
> Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Some systems will throw the following message when loading the wrong bit
> alignment:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard
> now.
> It's highly recommended that you fix the library with 'execstack -c
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path
> and the 64-bit library path, but it doesn't actually work. The script should
> deal with it accordingly to only have the proper 32-bit or 64-bit. All that
> is necessary is to modify the library path to be platform specific, and the
> error condition is resolved. I have attached modified script files
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-732) Need a 64-bit specific launching script
[
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15494988#comment-15494988
]
Jim Gomes commented on ARTEMIS-732:
---
I had put that in the Environment field of the Details section of the original
bug report. Do you need more than that? I'll add one additional clarification
in case you need it. My Linux distro is Stretch (all latest updates applied),
but I don't think that matters.
> Need a 64-bit specific launching script
> ---
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
> Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The artemis launching script located in the bin folder needs to be split into
> two separate scripts: one for 32-bit, and one for 64-bit. The current script
> attempts (but fails) to be run-time adaptive. However, when running on a
> 64-bit environment, the following error is always displayed when it is run:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard
> now.
> It's highly recommended that you fix the library with 'execstack -c
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path
> and the 64-bit library path, but it doesn't actually work. The script should
> be split into two separate scripts, one for 32-bit and one for 64-bit. All
> that is necessary is to modify the library path to be platform specific, and
> the error condition is resolved. I have attached modified script files
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-732) Need a 64-bit specific launching script
[
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes updated ARTEMIS-732:
--
Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102 (was: Debian
Linux 64-bit, OpenJDK 1.8.0.102)
> Need a 64-bit specific launching script
> ---
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit (Stretch), OpenJDK 1.8.0.102
>Reporter: Jim Gomes
> Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The artemis launching script located in the bin folder needs to be split into
> two separate scripts: one for 32-bit, and one for 64-bit. The current script
> attempts (but fails) to be run-time adaptive. However, when running on a
> 64-bit environment, the following error is always displayed when it is run:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard
> now.
> It's highly recommended that you fix the library with 'execstack -c
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path
> and the 64-bit library path, but it doesn't actually work. The script should
> be split into two separate scripts, one for 32-bit and one for 64-bit. All
> that is necessary is to modify the library path to be platform specific, and
> the error condition is resolved. I have attached modified script files
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-732) Need a 64-bit specific launching script
[
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15492181#comment-15492181
]
Jim Gomes commented on ARTEMIS-732:
---
I agree that a single adaptive script would be preferable.
> Need a 64-bit specific launching script
> ---
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit, OpenJDK 1.8.0.102
>Reporter: Jim Gomes
> Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The artemis launching script located in the bin folder needs to be split into
> two separate scripts: one for 32-bit, and one for 64-bit. The current script
> attempts (but fails) to be run-time adaptive. However, when running on a
> 64-bit environment, the following error is always displayed when it is run:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard
> now.
> It's highly recommended that you fix the library with 'execstack -c
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path
> and the 64-bit library path, but it doesn't actually work. The script should
> be split into two separate scripts, one for 32-bit and one for 64-bit. All
> that is necessary is to modify the library path to be platform specific, and
> the error condition is resolved. I have attached modified script files
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-732) Need a 64-bit specific launching script
[
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15492102#comment-15492102
]
Jim Gomes commented on ARTEMIS-732:
---
I would fix it because it doesn't work. You can see the output included in the
bug report. Having a notice reported like that is an issue. If these are
benign, it is not obvious. When something says "highly recommended", I tend to
take the advice. To me, it looks like I'm waiting for memory corruption to
happen during runtime. By fixing the library path, the correct libraries get
loaded, and the error goes away completely.
> Need a 64-bit specific launching script
> ---
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit, OpenJDK 1.8.0.102
>Reporter: Jim Gomes
> Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The artemis launching script located in the bin folder needs to be split into
> two separate scripts: one for 32-bit, and one for 64-bit. The current script
> attempts (but fails) to be run-time adaptive. However, when running on a
> 64-bit environment, the following error is always displayed when it is run:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard
> now.
> It's highly recommended that you fix the library with 'execstack -c
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path
> and the 64-bit library path, but it doesn't actually work. The script should
> be split into two separate scripts, one for 32-bit and one for 64-bit. All
> that is necessary is to modify the library path to be platform specific, and
> the error condition is resolved. I have attached modified script files
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARTEMIS-732) Need a 64-bit specific launching script
[
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15488610#comment-15488610
]
Jim Gomes commented on ARTEMIS-732:
---
This issue also seems to carry over into the Artemis instance script as well.
When a new broker instance is created, the *{{artemis}}* script that is created
needs to be 64-bit compatible with a correct {{-Djava.library.path}} set. As it
is, I have to manually fix up the generated script. I'm not sure where the
template is for that script, or I would offer a patch for it.
> Need a 64-bit specific launching script
> ---
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit, OpenJDK 1.8.0.102
>Reporter: Jim Gomes
> Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The artemis launching script located in the bin folder needs to be split into
> two separate scripts: one for 32-bit, and one for 64-bit. The current script
> attempts (but fails) to be run-time adaptive. However, when running on a
> 64-bit environment, the following error is always displayed when it is run:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard
> now.
> It's highly recommended that you fix the library with 'execstack -c
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path
> and the 64-bit library path, but it doesn't actually work. The script should
> be split into two separate scripts, one for 32-bit and one for 64-bit. All
> that is necessary is to modify the library path to be platform specific, and
> the error condition is resolved. I have attached modified script files
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARTEMIS-732) Need a 64-bit specific launching script
[
https://issues.apache.org/jira/browse/ARTEMIS-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes updated ARTEMIS-732:
--
Attachment: artemis64
artemis
Attaching modified scripts.
> Need a 64-bit specific launching script
> ---
>
> Key: ARTEMIS-732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-732
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.4.0
> Environment: Debian Linux 64-bit, OpenJDK 1.8.0.102
>Reporter: Jim Gomes
> Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: artemis, artemis64
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The artemis launching script located in the bin folder needs to be split into
> two separate scripts: one for 32-bit, and one for 64-bit. The current script
> attempts (but fails) to be run-time adaptive. However, when running on a
> 64-bit environment, the following error is always displayed when it is run:
> {noformat}
> OpenJDK 64-Bit Server VM warning: You have loaded library
> /home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
> which might have disabled stack guard. The VM will try to fix the stack guard
> now.
> It's highly recommended that you fix the library with 'execstack -c
> ', or link it with '-z noexecstack'
> {noformat}
> The problem is with the {{exec}} command-line, specifically the
> {{-Djava.library.path}} parameter. It combines both the 32-bit library path
> and the 64-bit library path, but it doesn't actually work. The script should
> be split into two separate scripts, one for 32-bit and one for 64-bit. All
> that is necessary is to modify the library path to be platform specific, and
> the error condition is resolved. I have attached modified script files
> (*{{artemis}}* and *{{artemis64}}*) that can be used depending on the
> run-time environment. Here are the key differences between the two scripts:
> {code:title=32-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"}}
> {code}
> {code:title=64-bit version}
> exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
> -classpath "$CLASSPATH" \
> -Dartemis.home="$ARTEMIS_HOME" \
> -Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
> $DEBUG_ARGS \
> org.apache.activemq.artemis.boot.Artemis "$@"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-732) Need a 64-bit specific launching script
Jim Gomes created ARTEMIS-732:
-
Summary: Need a 64-bit specific launching script
Key: ARTEMIS-732
URL: https://issues.apache.org/jira/browse/ARTEMIS-732
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 1.4.0
Environment: Debian Linux 64-bit, OpenJDK 1.8.0.102
Reporter: Jim Gomes
Fix For: 1.5.0
The artemis launching script located in the bin folder needs to be split into
two separate scripts: one for 32-bit, and one for 64-bit. The current script
attempts (but fails) to be run-time adaptive. However, when running on a 64-bit
environment, the following error is always displayed when it is run:
{noformat}
OpenJDK 64-Bit Server VM warning: You have loaded library
/home/username/apache-artemis-1.4.0/bin/lib/linux-i686/libartemis-native-32.so
which might have disabled stack guard. The VM will try to fix the stack guard
now.
It's highly recommended that you fix the library with 'execstack -c ',
or link it with '-z noexecstack'
{noformat}
The problem is with the {{exec}} command-line, specifically the
{{-Djava.library.path}} parameter. It combines both the 32-bit library path and
the 64-bit library path, but it doesn't actually work. The script should be
split into two separate scripts, one for 32-bit and one for 64-bit. All that is
necessary is to modify the library path to be platform specific, and the error
condition is resolved. I have attached modified script files (*{{artemis}}* and
*{{artemis64}}*) that can be used depending on the run-time environment. Here
are the key differences between the two scripts:
{code:title=32-bit version}
exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
-classpath "$CLASSPATH" \
-Dartemis.home="$ARTEMIS_HOME" \
-Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-i686" \
$DEBUG_ARGS \
org.apache.activemq.artemis.boot.Artemis "$@"}}
{code}
{code:title=64-bit version}
exec "$JAVACMD" $JAVA_ARGS $ARTEMIS_CLUSTER_PROPS \
-classpath "$CLASSPATH" \
-Dartemis.home="$ARTEMIS_HOME" \
-Djava.library.path="$ARTEMIS_HOME/bin/lib/linux-x86_64" \
$DEBUG_ARGS \
org.apache.activemq.artemis.boot.Artemis "$@"
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQNET-327) Upgrade solution to VisualStudio 2015
[ https://issues.apache.org/jira/browse/AMQNET-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-327: - Description: The solution files should be upgraded to VisualStudio 2015. At the same time, now projects will be created to target specific .NET versions. The existing projects will be renamed to XXX-net2.0.csproj or XXX-net3.5.csproj, as appropriate. For example, the vs2008-nms.csproj will be renamed to vs2015-nms-net2.0.csproj. It will then be duplicated to vs2015-nms-net4.0.csproj to target the .NET 4.0 framework. Other platform specific versions can be created on an as-needed basis. These individual project files will all be included in the single vs2015-nms.sln file. was: The solution files should be upgraded to VisualStudio 2013. At the same time, now projects will be created to target specific .NET versions. The existing projects will be renamed to XXX-net2.0.csproj or XXX-net3.5.csproj, as appropriate. For example, the vs2008-nms.csproj will be renamed to vs2013-nms-net2.0.csproj. It will then be duplicated to vs2013-nms-net4.0.csproj to target the .NET 4.0 framework. Other platform specific versions can be created on an as-needed basis. These individual project files will all be included in the single vs2013-nms.sln file. Summary: Upgrade solution to VisualStudio 2015 (was: Upgrade solution to VisualStudio 2013) > Upgrade solution to VisualStudio 2015 > - > > Key: AMQNET-327 > URL: https://issues.apache.org/jira/browse/AMQNET-327 > Project: ActiveMQ .Net > Issue Type: Task > Components: ActiveMQ, EMS, MSMQ, NMS, Stomp, WCF >Reporter: Jim Gomes >Assignee: Jim Gomes > Labels: net-2.0, net-3.5, net-4.0, vs2010 > Fix For: 1.8.0 > > Original Estimate: 72h > Time Spent: 2.5h > Remaining Estimate: 66h > > The solution files should be upgraded to VisualStudio 2015. At the same > time, now projects will be created to target specific .NET versions. The > existing projects will be renamed to XXX-net2.0.csproj or XXX-net3.5.csproj, > as appropriate. For example, the vs2008-nms.csproj will be renamed to > vs2015-nms-net2.0.csproj. It will then be duplicated to > vs2015-nms-net4.0.csproj to target the .NET 4.0 framework. Other platform > specific versions can be created on an as-needed basis. These individual > project files will all be included in the single vs2015-nms.sln file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQNET-556) Added unit tests to Apache.NMS.MSMQ and subsequenly fixed a few bugs
[ https://issues.apache.org/jira/browse/AMQNET-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes resolved AMQNET-556. -- Resolution: Fixed Reviewed and applied the patch, with only minor changes to the .csproj file to include the new files. > Added unit tests to Apache.NMS.MSMQ and subsequenly fixed a few bugs > > > Key: AMQNET-556 > URL: https://issues.apache.org/jira/browse/AMQNET-556 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: MSMQ >Affects Versions: 1.8.0 >Reporter: Stephane Ramet >Assignee: Jim Gomes > Labels: patch > Fix For: 1.8.0 > > Attachments: 2016-08-09 - Apache.NMS.MSMQ.patch, 2016-08-09 - > Apache.NMS.MSMQ.submitted.7z > > > Added a "standard" set of unit tests and fixed a number of bugs or > non-conformities in the Apache.NMS.MSMQ source code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work stopped] (AMQNET-556) Added unit tests to Apache.NMS.MSMQ and subsequenly fixed a few bugs
[ https://issues.apache.org/jira/browse/AMQNET-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQNET-556 stopped by Jim Gomes. > Added unit tests to Apache.NMS.MSMQ and subsequenly fixed a few bugs > > > Key: AMQNET-556 > URL: https://issues.apache.org/jira/browse/AMQNET-556 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: MSMQ >Affects Versions: 1.8.0 >Reporter: Stephane Ramet >Assignee: Jim Gomes > Labels: patch > Fix For: 1.8.0 > > Attachments: 2016-08-09 - Apache.NMS.MSMQ.patch, 2016-08-09 - > Apache.NMS.MSMQ.submitted.7z > > > Added a "standard" set of unit tests and fixed a number of bugs or > non-conformities in the Apache.NMS.MSMQ source code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (AMQNET-556) Added unit tests to Apache.NMS.MSMQ and subsequenly fixed a few bugs
[ https://issues.apache.org/jira/browse/AMQNET-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQNET-556 started by Jim Gomes. > Added unit tests to Apache.NMS.MSMQ and subsequenly fixed a few bugs > > > Key: AMQNET-556 > URL: https://issues.apache.org/jira/browse/AMQNET-556 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: MSMQ >Affects Versions: 1.8.0 >Reporter: Stephane Ramet >Assignee: Jim Gomes > Labels: patch > Fix For: 1.8.0 > > Attachments: 2016-08-09 - Apache.NMS.MSMQ.patch, 2016-08-09 - > Apache.NMS.MSMQ.submitted.7z > > > Added a "standard" set of unit tests and fixed a number of bugs or > non-conformities in the Apache.NMS.MSMQ source code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQNET-554) Added support for message properties and selectors in Apache.NMS.MSMQ
[
https://issues.apache.org/jira/browse/AMQNET-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15366741#comment-15366741
]
Jim Gomes commented on AMQNET-554:
--
Changes reviewed and applied. Thank you for the contribution! The patch
wasn't fully working, so having the entire source bundle was a big help.
> Added support for message properties and selectors in Apache.NMS.MSMQ
> -
>
> Key: AMQNET-554
> URL: https://issues.apache.org/jira/browse/AMQNET-554
> Project: ActiveMQ .Net
> Issue Type: New Feature
> Components: MSMQ
>Affects Versions: 1.8.0
>Reporter: Stephane Ramet
>Assignee: Jim Gomes
>Priority: Minor
> Labels: features, patch
> Fix For: 1.8.0
>
> Attachments: 2016-07-05 - Apache.NMS.MSMQ.7z, 2016-07-05 -
> Apache.NMS.MSMQ.patch
>
>
> The proposed package implements the following enhancements :
> 1. Support for communication of message properties between compatible peers
> The DefaultMessageConverter has been enhanced, so as to marshall custom
> message properties in the MSMQ Message.Extension field, along with the
> NMSCorrelationID which was already marshalled in this field.
> An additional flag specifies whether the MSMQ Message.Label field should be
> populated with the NMSType (as currently - default value) or with the value
> of a message property called "Label".
> 2. Support for selectors
> A parser for selection strings has been introduced.
> It is based on the Apache.ActiveMQ V4 implementation, ported from Java to C#.
> MessageReaders have been developped, that support various types of filtering:
> - no filtering when no selector strings are specified.
> - filtering based on the Id (NMSMessageID), CorrelationId (NMSCorrelationID)
> or LookupId properties.
> - filtering based on any other valid selection string.
> MessageReaders have been introduced in MessageConsumers and QueueBrowsers.
> The generic filtering system, based on a selection string, has - at least -
> two limitations:
> - it cannot be fully included in the build chains: the source code is
> generated from SelectorParser.csc (a port of ActiveMQ's SelectorParser.jj) by
> CSharpCC (https://github.com/deveel/csharpcc, a port of JavaCC, now
> unmaintained). Due to limitations and/or bugs in the CSharpCC (eg. support
> for namespace {}), the generated code must be rectified manually. A port to
> another parser generator (eg. ANTLR) would certainly be required.
> - selection is performed by the client, by browsing through the messages in
> the queue, via MessageQueue.GetMessageEnumerator2() or MessageQueue.Peek(),
> and retrieving only the matching messages via MessageQueue.ReceiveByLookupId.
> When the queue gets very long and the relevant messages are sparse,
> performance becomes an issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQNET-554) Added support for message properties and selectors in Apache.NMS.MSMQ
[
https://issues.apache.org/jira/browse/AMQNET-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes resolved AMQNET-554.
--
Resolution: Fixed
Fix Version/s: 1.8.0
> Added support for message properties and selectors in Apache.NMS.MSMQ
> -
>
> Key: AMQNET-554
> URL: https://issues.apache.org/jira/browse/AMQNET-554
> Project: ActiveMQ .Net
> Issue Type: New Feature
> Components: MSMQ
>Affects Versions: 1.8.0
>Reporter: Stephane Ramet
>Assignee: Jim Gomes
>Priority: Minor
> Labels: features, patch
> Fix For: 1.8.0
>
> Attachments: 2016-07-05 - Apache.NMS.MSMQ.7z, 2016-07-05 -
> Apache.NMS.MSMQ.patch
>
>
> The proposed package implements the following enhancements :
> 1. Support for communication of message properties between compatible peers
> The DefaultMessageConverter has been enhanced, so as to marshall custom
> message properties in the MSMQ Message.Extension field, along with the
> NMSCorrelationID which was already marshalled in this field.
> An additional flag specifies whether the MSMQ Message.Label field should be
> populated with the NMSType (as currently - default value) or with the value
> of a message property called "Label".
> 2. Support for selectors
> A parser for selection strings has been introduced.
> It is based on the Apache.ActiveMQ V4 implementation, ported from Java to C#.
> MessageReaders have been developped, that support various types of filtering:
> - no filtering when no selector strings are specified.
> - filtering based on the Id (NMSMessageID), CorrelationId (NMSCorrelationID)
> or LookupId properties.
> - filtering based on any other valid selection string.
> MessageReaders have been introduced in MessageConsumers and QueueBrowsers.
> The generic filtering system, based on a selection string, has - at least -
> two limitations:
> - it cannot be fully included in the build chains: the source code is
> generated from SelectorParser.csc (a port of ActiveMQ's SelectorParser.jj) by
> CSharpCC (https://github.com/deveel/csharpcc, a port of JavaCC, now
> unmaintained). Due to limitations and/or bugs in the CSharpCC (eg. support
> for namespace {}), the generated code must be rectified manually. A port to
> another parser generator (eg. ANTLR) would certainly be required.
> - selection is performed by the client, by browsing through the messages in
> the queue, via MessageQueue.GetMessageEnumerator2() or MessageQueue.Peek(),
> and retrieving only the matching messages via MessageQueue.ReceiveByLookupId.
> When the queue gets very long and the relevant messages are sparse,
> performance becomes an issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (AMQNET-554) Added support for message properties and selectors in Apache.NMS.MSMQ
[
https://issues.apache.org/jira/browse/AMQNET-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on AMQNET-554 started by Jim Gomes.
> Added support for message properties and selectors in Apache.NMS.MSMQ
> -
>
> Key: AMQNET-554
> URL: https://issues.apache.org/jira/browse/AMQNET-554
> Project: ActiveMQ .Net
> Issue Type: New Feature
> Components: MSMQ
>Affects Versions: 1.8.0
>Reporter: Stephane Ramet
>Assignee: Jim Gomes
>Priority: Minor
> Labels: features, patch
> Attachments: 2016-07-05 - Apache.NMS.MSMQ.7z, 2016-07-05 -
> Apache.NMS.MSMQ.patch
>
>
> The proposed package implements the following enhancements :
> 1. Support for communication of message properties between compatible peers
> The DefaultMessageConverter has been enhanced, so as to marshall custom
> message properties in the MSMQ Message.Extension field, along with the
> NMSCorrelationID which was already marshalled in this field.
> An additional flag specifies whether the MSMQ Message.Label field should be
> populated with the NMSType (as currently - default value) or with the value
> of a message property called "Label".
> 2. Support for selectors
> A parser for selection strings has been introduced.
> It is based on the Apache.ActiveMQ V4 implementation, ported from Java to C#.
> MessageReaders have been developped, that support various types of filtering:
> - no filtering when no selector strings are specified.
> - filtering based on the Id (NMSMessageID), CorrelationId (NMSCorrelationID)
> or LookupId properties.
> - filtering based on any other valid selection string.
> MessageReaders have been introduced in MessageConsumers and QueueBrowsers.
> The generic filtering system, based on a selection string, has - at least -
> two limitations:
> - it cannot be fully included in the build chains: the source code is
> generated from SelectorParser.csc (a port of ActiveMQ's SelectorParser.jj) by
> CSharpCC (https://github.com/deveel/csharpcc, a port of JavaCC, now
> unmaintained). Due to limitations and/or bugs in the CSharpCC (eg. support
> for namespace {}), the generated code must be rectified manually. A port to
> another parser generator (eg. ANTLR) would certainly be required.
> - selection is performed by the client, by browsing through the messages in
> the queue, via MessageQueue.GetMessageEnumerator2() or MessageQueue.Peek(),
> and retrieving only the matching messages via MessageQueue.ReceiveByLookupId.
> When the queue gets very long and the relevant messages are sparse,
> performance becomes an issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (AMQNET-517) Added support for QueueBrowser and DeleteDestination in MSMQ provider + fixed EMS QueueBrowser
[ https://issues.apache.org/jira/browse/AMQNET-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQNET-517 started by Jim Gomes. > Added support for QueueBrowser and DeleteDestination in MSMQ provider + fixed > EMS QueueBrowser > -- > > Key: AMQNET-517 > URL: https://issues.apache.org/jira/browse/AMQNET-517 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: EMS, MSMQ >Affects Versions: 1.7.1 >Reporter: Stephane Ramet >Assignee: Jim Gomes >Priority: Minor > Fix For: 1.8.0 > > Attachments: EMS_MSMQ_QueueBrowser.patch > > > Added support for QueueBrowser and DeleteDestination in MSMQ provider, plus > fixed support for QueueBrowser in EMS provider. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQNET-517) Added support for QueueBrowser and DeleteDestination in MSMQ provider + fixed EMS QueueBrowser
[ https://issues.apache.org/jira/browse/AMQNET-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes resolved AMQNET-517. -- Resolution: Fixed Applied patch from Stephane Ramet. > Added support for QueueBrowser and DeleteDestination in MSMQ provider + fixed > EMS QueueBrowser > -- > > Key: AMQNET-517 > URL: https://issues.apache.org/jira/browse/AMQNET-517 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: EMS, MSMQ >Affects Versions: 1.7.1 >Reporter: Stephane Ramet >Assignee: Jim Gomes >Priority: Minor > Fix For: 1.8.0 > > Attachments: EMS_MSMQ_QueueBrowser.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Added support for QueueBrowser and DeleteDestination in MSMQ provider, plus > fixed support for QueueBrowser in EMS provider. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQNET-454) Add Apache Qpid provider to NMS
[ https://issues.apache.org/jira/browse/AMQNET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes resolved AMQNET-454. -- Resolution: Fixed Looks like this feature has been sufficiently developed to close this issue. New issues can be opened to address specific problems/enhancements. > Add Apache Qpid provider to NMS > --- > > Key: AMQNET-454 > URL: https://issues.apache.org/jira/browse/AMQNET-454 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: NMS >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Assignee: Jim Gomes > Attachments: Apache.NMS.AMQP-21-Add-Map-Text-Message-tests.patch, > Apache.NMS.AMQP-22-add-more-tests.patch, > Apache.NMS.AMQP-23a-MessageDeliveryTest.cs.patch, > Apache.NMS.AMQP-23b-MSConnectionFactoryTest.cs.patch, > Apache.NMS.AMQP-23c-NmsConsoleTracer.cs.patch, > Apache.NMS.AMQP-23d-addTraceStatements.patch, > Apache.NMS.AMQP-23e-addFilesToTestProject.patch, > Apache.NMS.AMQP-24-tidy-up.patch, Apache.NMS.AMQP-25-use-qpid-0.28.patch, > Apache.NMS.AMQP-26-hook-in-session-ack.patch, > Apache.NMS.AMQP-27-nant-unmanaged-copy.patch, > Apache.NMS.AMQP-28-close-qpid-sender-receiver.patch, > Apache.NMS.AMQP-29-stop-sessions-before-connection.patch, > Apache.NMS.AMQP-30-lock-x86-only.patch, > Apache.NMS.AMQP-Add-message-cloning-19.patch, > Apache.NMS.AMQP-add-connection-property-table-17.patch, > Apache.NMS.AMQP-add-hello-world-example-11.patch, > Apache.NMS.AMQP-add-hello-world-example-retry-12.patch, > Apache.NMS.AMQP-add-hello-world-to-vs2008-18.patch, > Apache.NMS.AMQP-add-message-conversions-06.patch, > Apache.NMS.AMQP-add-message-test-20.patch, > Apache.NMS.AMQP-add-topic-05.patch, > Apache.NMS.AMQP-connectionProperties-07.patch, > Apache.NMS.AMQP-copyrights-conn-str-fix-09.patch, > Apache.NMS.AMQP-fix-destination-to-use-qpid-address-10.patch, > Apache.NMS.AMQP-fix-helloworld-13.patch, > Apache.NMS.AMQP-fix-list-message-body-15.patch, > Apache.NMS.AMQP-fix-map-message-body-14.patch, > Apache.NMS.AMQP-fix-replyTo-and-receive-timeouts-16.patch, > Apache.NMS.AMQP-object-lifecycle-04.patch, > Apache.NMS.AMQP-provider-configs-03.patch, > Apache.NMS.AMQP-qpid-object-lifecycle-02.patch, > Apache.NMS.AMQP-set-connection-credentials-08.patch, RELEASE.txt, > vendor-Apache.QPID-00-replace-debug-with-release.patch, > vendor-QPid-nant-01.patch > > > NMS includes various providers ActiveMQ, STOMP, MSMQ, EMS, and WCF. This > issue proposes to add [Apache Qpid|http://qpid.apache.org/index.html] as > another provider. > Qpid has a [Messaging .NET > Binding|http://qpid.apache.org/releases/qpid-0.24/programming/book/ch05.html] > that is layered on top of the native C++ Qpid Messaging client. The Qpid .NET > binding is attractive as the hook for tying in Qpid as an NMS provider. > The proposed NMS provider supports [AMQP > 1.0|http://qpid.apache.org/amqp.html] by including [Qpid > Proton|http://qpid.apache.org/proton/index.html] libraries. > From a high level this addition to Active.NMS would consist of two parts > * Add Qpid as a vendor kit. This includes both the Qpid .NET Binding and Qpid > Proton in a single kit. > * Add the new provider with code linking NMS to Qpid -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQNET-512) Upgrade Apache.NMS.EMS to .NET 4.0
[ https://issues.apache.org/jira/browse/AMQNET-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes resolved AMQNET-512. -- Resolution: Fixed > Upgrade Apache.NMS.EMS to .NET 4.0 > -- > > Key: AMQNET-512 > URL: https://issues.apache.org/jira/browse/AMQNET-512 > Project: ActiveMQ .Net > Issue Type: Task > Components: EMS >Affects Versions: 1.7.1, 1.8.0 > Environment: .NET 4.0 >Reporter: Jim Gomes >Assignee: Jim Gomes > Labels: build > Fix For: 1.8.0, 1.7.1 > > Original Estimate: 4h > Remaining Estimate: 4h > > Upgrade to latest TIBCO EMS 8.2.0 client libraries. This will require > upgrading the build solution from VS2008 to VS2013. The latest TIBCO EMS > client is .NET 4.0 only, so older .NET runtimes (i.e., 2.0) will not be > supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQNET-516) Create wiki pages in Confluence for new XMS provider
Jim Gomes created AMQNET-516: Summary: Create wiki pages in Confluence for new XMS provider Key: AMQNET-516 URL: https://issues.apache.org/jira/browse/AMQNET-516 Project: ActiveMQ .Net Issue Type: Sub-task Components: XMS Affects Versions: 1.8.0 Reporter: Jim Gomes Assignee: Jim Gomes Priority: Minor Fix For: 1.8.0 The main documentation page should have links added to the new XMS provider information page. See this page: http://activemq.apache.org/nms/nms.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (AMQNET-185) Add new provider implementation for IBM WebSphere MQ (formerly MQSeries)
[ https://issues.apache.org/jira/browse/AMQNET-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQNET-185 started by Jim Gomes. > Add new provider implementation for IBM WebSphere MQ (formerly MQSeries) > > > Key: AMQNET-185 > URL: https://issues.apache.org/jira/browse/AMQNET-185 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: XMS >Affects Versions: 1.2.0 >Reporter: Jim Gomes >Assignee: Jim Gomes >Priority: Minor > Attachments: Apache.NMS.XMS.7z > > > An additional provider implementation for interfacing with IBM WebSphere MQ > would greatly enhance the cross-broker support of NMS. This new provider > implementation can be implemented in a similar fashion to the TIBCO EMS > provider. The new provider should be named Apache.NMS.XMS. The IBM > WebSphere MQ .NET client is informally, but commonly, referred to as XMS .NET. > The URI prefix for the provider should be XMS: in a similar way that EMS: > prefix is used for TIBCO. > A new Component module should be added to JIRA to track this provider. The > Component module should be named XMS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (AMQNET-512) Upgrade Apache.NMS.EMS to .NET 4.0
[ https://issues.apache.org/jira/browse/AMQNET-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQNET-512 started by Jim Gomes. > Upgrade Apache.NMS.EMS to .NET 4.0 > -- > > Key: AMQNET-512 > URL: https://issues.apache.org/jira/browse/AMQNET-512 > Project: ActiveMQ .Net > Issue Type: Task > Components: EMS >Affects Versions: 1.7.1, 1.8.0 > Environment: .NET 4.0 >Reporter: Jim Gomes >Assignee: Jim Gomes > Labels: build > Fix For: 1.7.1, 1.8.0 > > Original Estimate: 4h > Remaining Estimate: 4h > > Upgrade to latest TIBCO EMS 8.2.0 client libraries. This will require > upgrading the build solution from VS2008 to VS2013. The latest TIBCO EMS > client is .NET 4.0 only, so older .NET runtimes (i.e., 2.0) will not be > supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQNET-511) Failover modie is not enabled for TIBCO provider
[
https://issues.apache.org/jira/browse/AMQNET-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes resolved AMQNET-511.
--
Resolution: Fixed
Fix Version/s: 1.8.0
Added the following new optional URL parameters:
{noformat}
connection.ExceptionOnFTEvents
connection.ExceptionOnFTSwitch
connection.ConnAttemptCount
connection.ConnAttemptDelay
connection.ConnAttemptTimeout
connection.ReconnAttemptCount
connection.ReconnAttemptDelay
connection.ReconnAttemptTimeout
{noformat}
A sample usage:
{noformat}
ems:(tcp://emsbroker1:7222,tcp:emsbroker2:7222)?connection.ConnAttemptCount=5
{noformat}
The default values of the variables are as follows:
{noformat}
ExceptionOnFTEvents = true
ExceptionOnFTSwitch = true
ConnAttemptCount = Int32.MaxValue
ConnAttemptDelay = 3000 // 30 seconds
ConnAttemptTimeout = 5000// 5 seconds
ReconnAttemptCount = Int32.MaxValue
ReconnAttemptDelay = 3 // 30 seconds
ReconnAttemptTimeout = 5000 // 5 seconds
{noformat}
> Failover modie is not enabled for TIBCO provider
>
>
> Key: AMQNET-511
> URL: https://issues.apache.org/jira/browse/AMQNET-511
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: EMS
>Affects Versions: 1.5.0, 1.7.0
>Reporter: Jim Gomes
>Assignee: Jim Gomes
> Labels: failover
> Fix For: 1.7.1, 1.8.0
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> When attempting to use a failover URI, the TIBCO provider does not actually
> activate the failover mode.
> Given a simple failover URI:
> {{ems:tcp://emsbroker1:7222,tcp://emsbroker2:7222}}
> This should enable failover and auto-reconnect in case of network disruption.
> However, it only throws an exception and never attempts to reconnect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQNET-511) Failover modie is not enabled for TIBCO provider
Jim Gomes created AMQNET-511:
Summary: Failover modie is not enabled for TIBCO provider
Key: AMQNET-511
URL: https://issues.apache.org/jira/browse/AMQNET-511
Project: ActiveMQ .Net
Issue Type: Bug
Components: EMS
Affects Versions: 1.7.0, 1.5.0
Reporter: Jim Gomes
Assignee: Jim Gomes
Fix For: 1.7.1
When attempting to use a failover URI, the TIBCO provider does not actually
activate the failover mode.
Given a simple failover URI: {{ems:tcp://emsbroker1:7222,tcp://emsbroker2:7222}}
This should enable failover and auto-reconnect in case of network disruption.
However, it only throws an exception and never attempts to reconnect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQNET-511) Failover mode is not enabled for TIBCO provider
[
https://issues.apache.org/jira/browse/AMQNET-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes updated AMQNET-511:
-
Summary: Failover mode is not enabled for TIBCO provider (was: Failover
modie is not enabled for TIBCO provider)
> Failover mode is not enabled for TIBCO provider
> ---
>
> Key: AMQNET-511
> URL: https://issues.apache.org/jira/browse/AMQNET-511
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: EMS
>Affects Versions: 1.5.0, 1.7.0
>Reporter: Jim Gomes
>Assignee: Jim Gomes
> Labels: failover
> Fix For: 1.7.1, 1.8.0
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> When attempting to use a failover URI, the TIBCO provider does not actually
> activate the failover mode.
> Given a simple failover URI:
> {{ems:tcp://emsbroker1:7222,tcp://emsbroker2:7222}}
> This should enable failover and auto-reconnect in case of network disruption.
> However, it only throws an exception and never attempts to reconnect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQNET-398) NetTx transaction support in WCF binding
[ https://issues.apache.org/jira/browse/AMQNET-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-398: - Description: I needed to support .NET style distributed transactions with ActiveMQ broker and provided NMS WCF binding, but we can't get it working out of the box. Because of WCF binding lacks explicit support for this scenario, I tried to fool it by supplying a wrapper for INetTxConnectionFactory (and a related one for INetTxConnection) as an IConnectionFactory through nmsprovider-*.config file. Despite being able to make WCF binding to instantiate my wrapper class (and so, NetTxConnectionFactory under the hood), I needed to modify slightly WCF binding code in two points: * NmsOutputChannel: here I noticed that a premature session disposing due to the using block caused a deadlock when the ISession implementation was NetTxSession who waits for transaction to complete (TransactionContext.DtcWaitHandle.WaitOne() in Close() method). This phenomenon was not evident in the provided test code, because of the TransactionScope block is always INSIDE the using block that scopes the session. Using WCF binding is somewhat higher level, so I'm forced to wrap the WCF call with a TransactionScope. The modification I've made is to handle the non-transactional case like before, and to defer session disposing when inside a transaction (for this I've used provided events TransactionCommittedListener and TransactionRolledBackListener). * NmsInputChannelListener: assuming a service method with OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true), my perception of the expected behavior when an exception is thrown in the service method is that the active transaction must be rolled back. Here we are on the receiving part (NMS WCF binding is below service code in the stack!) so to ensure this behavior (I stress this here: it's the expected behavior for me), I've had to provide a WCF custom IErrorHandler to raise an exception in HandleError method, that NMS WCF binding could be catch and rollback the active transaction. To obtain this, I've had to rethrow the exception in Dispatch method. I don't know if this may cause troubles. Morover, I discovered a bug in ActiveMQ provider NetTxConnection.GuidFromId: the implementation does not cares that the hyphen is a valid character hostnames. I attach two patches here: one for the WCF binding component with the described changes, another for ActiveMQ provider with the transaction id translation fix and a minor one at a logging statement. Best Regards, Andrea Montemaggio was: I needed to support .NET style distributed transactions with ActiveMQ broker and provided NMS WCF binding, but we can't get it working out of the box. Because of WCF binding lacks explicit support for this scenario, I tried to fool it by supplying a wrapper for INetTxConnectionFactory (and a related one for INetTxConnection) as an IConnectionFactory through nmsprovider-*.config file. Despite being able to make WCF binding to instantiate my wrapper class (and so, NetTxConnectionFactory under the hood), I needed to modify slightly WCF binding code in two points: - NmsOutputChannel: here I noticed that a premature session disposing due to the using block caused a deadlock when the ISession implementation was NetTxSession who waits for transaction to complete (TransactionContext.DtcWaitHandle.WaitOne() in Close() method). This phenomenon was not evident in the provided test code, because of the TransactionScope block is always INSIDE the using block that scopes the session. Using WCF binding is somewhat higher level, so I'm forced to wrap the WCF call with a TransactionScope. The modification I've made is to handle the non-transactional case like before, and to defer session disposing when inside a transaction (for this I've used provided events TransactionCommittedListener and TransactionRolledBackListener). - NmsInputChannelListener: assuming a service method with OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true), my perception of the expected behavior when an exception is thrown in the service method is that the active transaction must be rolled back. Here we are on the receiving part (NMS WCF binding is below service code in the stack!) so to ensure this behavior (I stress this here: it's the expected behavior for me), I've had to provide a WCF custom IErrorHandler to raise an exception in HandleError method, that NMS WCF binding could be catch and rollback the active transaction. To obtain this, I've had to rethrow the exception in Dispatch method. I don't know if this cay cause troubles. Morover, I discovered a bug in ActiveMQ provider NetTxConnection.GuidFromId: the implementation does not cares that the hyphen is a valid character hostnames. I attach two patches here: one for the WCF binding
[jira] [Updated] (AMQNET-503) DTC Transactions do not respect rollbacks consistently leading to duplicated messages
[ https://issues.apache.org/jira/browse/AMQNET-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-503: - Component/s: NMS DTC Transactions do not respect rollbacks consistently leading to duplicated messages - Key: AMQNET-503 URL: https://issues.apache.org/jira/browse/AMQNET-503 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ, NMS Reporter: Jose Alvarado Assignee: Jim Gomes Fix For: 1.7.1 Attachments: Apache Documentation.docx, Apache.NMS.AMQNETIssue.patch, Apache.NMS.ActiveMQ.AMQNETIssue.patch In certain circumstances, rollback does not work properly, as a result duplicate messages are generated from normal DTC operations. The circumstances under which this issues occurs are: - DTC transaction initiated, but fails to commit; - Another DTC transaction initiated and successfully commits; - When a transaction is roll backed and committed on retry; As a result the number of messages sent is larger to the number of messages received by the target broker. Some of the messages are not roll backed when it fails and they get sent again when committed on retry. This issue has been raised in Jira as issues 413 and 472: https://issues.apache.org/jira/browse/AMQNET-413 https://issues.apache.org/jira/browse/AMQNET-472 Analysing the code we realised that these two issues above are similar, and they have the same cause. We have therefore developed a patch based on feedback and unit tests provided by those two issues, where we fix the problem and we pass all existing unit tests. The changes modify only code related to DTC, and it was developed in .NET 2.0 as per the requirements for 413/472 The fix implements the solution suggested in the patch for issue 472 where some lock conditions were missing. In addition we have added a condition where we will not lock the transaction whenever a distributed transaction occurs. The DtcWaitHandle.WaitOne causes DTC transactions involving a database or XA transaction to fail unit testing. The patch was extensively tested with over a 1000 messages (1K, 1.5K, 10K, 100K, 1M) using two brokers across different servers to guarantee distributed transactions. Testing also included different message sizes, infrastructure setup, databases, and message content verification to validate its integrity and ensure messages were not duplicated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQNET-500) Using Ssl transport with certificates failure
[ https://issues.apache.org/jira/browse/AMQNET-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes resolved AMQNET-500. -- Resolution: Fixed Applied submitted patch. Thanks, Enrique! Using Ssl transport with certificates failure - Key: AMQNET-500 URL: https://issues.apache.org/jira/browse/AMQNET-500 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ Affects Versions: 1.7.0 Environment: Mono Reporter: Enrique GarcÃa Assignee: Jim Gomes Priority: Minor Labels: ssl Fix For: 1.7.1 Attachments: SslTransport_X509StorePatch.diff Using the SSL transport and a certificate from the X509Store with mono is not possible. That is because of a bug in the mono implementation of the X509Store (I sent a patch yesterday). The X509Store.Certificates returns a reference to the internal list of certificates which is closed after calling X509Store.Close(). I implemented a workaround in the code you could use if you consider it useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (AMQNET-398) NetTx transaction support in WCF binding
[ https://issues.apache.org/jira/browse/AMQNET-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQNET-398 started by Jim Gomes. NetTx transaction support in WCF binding Key: AMQNET-398 URL: https://issues.apache.org/jira/browse/AMQNET-398 Project: ActiveMQ .Net Issue Type: Improvement Components: ActiveMQ, WCF Reporter: Andrea Montemaggio Assignee: Jim Gomes Priority: Minor Labels: transaction Attachments: Apache.NMS.ActiveMQ-NetTx.patch, Apache.NMS.WCF-NetTx.patch I needed to support .NET style distributed transactions with ActiveMQ broker and provided NMS WCF binding, but we can't get it working out of the box. Because of WCF binding lacks explicit support for this scenario, I tried to fool it by supplying a wrapper for INetTxConnectionFactory (and a related one for INetTxConnection) as an IConnectionFactory through nmsprovider-*.config file. Despite being able to make WCF binding to instantiate my wrapper class (and so, NetTxConnectionFactory under the hood), I needed to modify slightly WCF binding code in two points: - NmsOutputChannel: here I noticed that a premature session disposing due to the using block caused a deadlock when the ISession implementation was NetTxSession who waits for transaction to complete (TransactionContext.DtcWaitHandle.WaitOne() in Close() method). This phenomenon was not evident in the provided test code, because of the TransactionScope block is always INSIDE the using block that scopes the session. Using WCF binding is somewhat higher level, so I'm forced to wrap the WCF call with a TransactionScope. The modification I've made is to handle the non-transactional case like before, and to defer session disposing when inside a transaction (for this I've used provided events TransactionCommittedListener and TransactionRolledBackListener). - NmsInputChannelListener: assuming a service method with OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true), my perception of the expected behavior when an exception is thrown in the service method is that the active transaction must be rolled back. Here we are on the receiving part (NMS WCF binding is below service code in the stack!) so to ensure this behavior (I stress this here: it's the expected behavior for me), I've had to provide a WCF custom IErrorHandler to raise an exception in HandleError method, that NMS WCF binding could be catch and rollback the active transaction. To obtain this, I've had to rethrow the exception in Dispatch method. I don't know if this cay cause troubles. Morover, I discovered a bug in ActiveMQ provider NetTxConnection.GuidFromId: the implementation does not cares that the hyphen is a valid character hostnames. I attach two patches here: one for the WCF binding component with the described changes, another for ActiveMQ provider with the transaction id translation fix and a minor one at a logging statement. Best Regards, Andrea Montemaggio -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQNET-500) Using Ssl transport with certificates failure
[ https://issues.apache.org/jira/browse/AMQNET-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-500: - Fix Version/s: 1.7.1 Using Ssl transport with certificates failure - Key: AMQNET-500 URL: https://issues.apache.org/jira/browse/AMQNET-500 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ Affects Versions: 1.7.0 Environment: Mono Reporter: Enrique GarcÃa Assignee: Jim Gomes Priority: Minor Labels: ssl Fix For: 1.7.1 Attachments: SslTransport_X509StorePatch.diff Using the SSL transport and a certificate from the X509Store with mono is not possible. That is because of a bug in the mono implementation of the X509Store (I sent a patch yesterday). The X509Store.Certificates returns a reference to the internal list of certificates which is closed after calling X509Store.Close(). I implemented a workaround in the code you could use if you consider it useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQNET-490) Stomp Client 1.5.4 error creating subscription to topic on JBoss HornetQ (Jboss 6.4.2 GA)
[
https://issues.apache.org/jira/browse/AMQNET-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes updated AMQNET-490:
-
Component/s: (was: ActiveMQ)
Stomp Client 1.5.4 error creating subscription to topic on JBoss HornetQ
(Jboss 6.4.2 GA)
-
Key: AMQNET-490
URL: https://issues.apache.org/jira/browse/AMQNET-490
Project: ActiveMQ .Net
Issue Type: New Feature
Components: Stomp
Affects Versions: 1.5.4
Reporter: Harley Blumenfeld
Assignee: Jim Gomes
Fix For: 1.8.0
Maybe I am doing something dumb, but using a simple example I cannot seem to
get a topic subscription working using the Apache.NMS.Stomp version 1.5.4
(http://activemq.apache.org/nms/apachenmsstomp-v154.html).
I am compiling the Stomp source code and project under .Net 4.0. I have
created a console application in the Apache.NMS.Stomp solution. My program
fails when it attempts to create a subscription to the topic. The same
example works fine with the 1.5.3 version of the DLL so this seems like it
could be a bug.
bHere is the result of my simple program:/b
About to connect to stomp:tcp://myjboss:61613
Using destination: topic://jms.topic.test.topic
Connection Error: : Error creating subscription
IDcSTHBLUMENF-50514-635475847768724525-1:0c1:1
Connection Error:
Error: : Error creating subscription
IDcSTHBLUMENF-50514-635475847768724525-1:0c1:1
Error: at Apache.NMS.Stomp.Connection.SyncRequest(Command command, TimeSpan
requestTimeout) in
C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\src\main\csharp\Connection.cs:line
525
at Apache.NMS.Stomp.Connection.SyncRequest(Command command) in
C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\src\main\csharp\Connection.cs:line
505
at Apache.NMS.Stomp.Session.CreateConsumer(IDestination destination,
String selector, Boolean noLocal) in
C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\src\main\csharp\Session.cs:line
425
at Apache.NMS.Stomp.Session.CreateConsumer(IDestination destination) in
C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\src\main\csharp\Session.cs:line
379
at TopicSubscriberTest.Program.Main(String[] args) in
C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\TopicSubscribeTest\Program.cs:line
31
bHere is the code:/b
class Program
{
private static void Main(string[] args)
{
try
{
var connecturi = new Uri(stomp:tcp://myjboss:61613);
Console.WriteLine(About to connect to + connecturi);
IConnectionFactory factory = new
NMSConnectionFactory(connecturi);
busing (IConnection connection =
factory.CreateConnection(testuser, test))/b
{
connection.ExceptionListener += new
ExceptionListener(OnConnectionException);
connection.Start();
using (ISession session =
connection.CreateSession())
{
connection.Start();
IDestination destination =
SessionUtil.GetDestination(session,topic://jms.topic.test.topic);
Console.WriteLine(Using destination:
+ destination);
using (IMessageConsumer consumer =
session.CreateConsumer(destination))
{
consumer.Listener += OnMessage;
while (true)
{
Thread.Sleep(5000);
Console.WriteLine(.);
}
}
}
}
}
catch (Exception e)
{
Console.WriteLine(Error: + e.Message);
Console.WriteLine(Error: + e.StackTrace);
Console.ReadLine();
}
}
private static void OnConnectionException(Exception e)
{
Console.WriteLine(Connection Error: + e.Message);
Console.WriteLine(Connection Error: + e.StackTrace);
}
protected static void OnMessage(IMessage receivedMsg)
{
var message = receivedMsg as ITextMessage;
Console.WriteLine(message.Text);
}
}
--
This message
[jira] [Updated] (AMQNET-502) When a SocketException is thrown in DoConnect, invalid exception message is generated
[
https://issues.apache.org/jira/browse/AMQNET-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes updated AMQNET-502:
-
Fix Version/s: 1.7.1
When a SocketException is thrown in DoConnect, invalid exception message is
generated
-
Key: AMQNET-502
URL: https://issues.apache.org/jira/browse/AMQNET-502
Project: ActiveMQ .Net
Issue Type: Improvement
Components: ActiveMQ
Affects Versions: 1.6.4, 1.7.0
Environment: Windows Server 2012, Visual Studio 2015
Reporter: Matthew Hintzen
Priority: Minor
Labels: easyfix
Fix For: 1.7.1
Original Estimate: 1h
Remaining Estimate: 1h
When attempting to connect the TCP socket in TcpTransportFactory.cs in the
```DoConnect(host, port, localAddress, localPort)``` proc if all attempts to
call
```TryConnectSocket(ipaddress, port, localAddress, localPort)```
are unsucessful ( resulting in socket == null) at line 375 a
```throw new SocketException();```
is generated.
Since this SocketException has not message in it, it is then caught in turn
at line 380 and repackaged as
```throw new NMSConnectionException(String.Format(Error connecting to
{0}:{1}., host, port), ex);```
Unfortunately when a SocketException is thrown with no default error message,
the inner exception text shows as The operation completed successfully for
any client consuming application.
I recommend that we give back some more meaningful and relevant information.
```InnerException:
ErrorCode=0
HResult=-2147467259
Message=The operation completed successfully
NativeErrorCode=0
Source=Apache.NMS.ActiveMQ
StackTrace:
at
Apache.NMS.ActiveMQ.Transport.Tcp.TcpTransportFactory.DoConnect(String host,
Int32 port, String localAddress, Int32 localPort)
```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQNET-327) Upgrade solution to VisualStudio 2013
[ https://issues.apache.org/jira/browse/AMQNET-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-327: - Fix Version/s: (was: 1.6.1) 1.8.0 Upgrade solution to VisualStudio 2013 - Key: AMQNET-327 URL: https://issues.apache.org/jira/browse/AMQNET-327 Project: ActiveMQ .Net Issue Type: Task Components: ActiveMQ, EMS, MSMQ, NMS, Stomp, WCF Reporter: Jim Gomes Assignee: Jim Gomes Labels: net-2.0, net-3.5, net-4.0, vs2010 Fix For: 1.8.0 Original Estimate: 72h Time Spent: 2.5h Remaining Estimate: 66h The solution files should be upgraded to VisualStudio 2013. At the same time, now projects will be created to target specific .NET versions. The existing projects will be renamed to XXX-net2.0.csproj or XXX-net3.5.csproj, as appropriate. For example, the vs2008-nms.csproj will be renamed to vs2013-nms-net2.0.csproj. It will then be duplicated to vs2013-nms-net4.0.csproj to target the .NET 4.0 framework. Other platform specific versions can be created on an as-needed basis. These individual project files will all be included in the single vs2013-nms.sln file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQNET-493) Activemq Failover is not working when the remote computer is turned off
[ https://issues.apache.org/jira/browse/AMQNET-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-493: - Fix Version/s: 1.7.2 Activemq Failover is not working when the remote computer is turned off --- Key: AMQNET-493 URL: https://issues.apache.org/jira/browse/AMQNET-493 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ Affects Versions: 1.6.2 Environment: ActiveMQ 5.9.1, NMS 1.6.0, NMS.ActiveMQ 1.6.2 Reporter: Tamilmaran Assignee: Jim Gomes Fix For: 1.7.2 we have used following failover URl:- activemq:failover://(ssl://10.2.114.40:61617?transport.serverName=MCCActiveMQBroker,ssl://10.2.152.190:61617?transport.serverName=MCCActiveMQBroker,ssl://10.2.112.178:61617?transport.serverName=MCCActiveMQBroker)?transport.randomize=falsetransport.startupMaxReconnectAttempts=0transport.timeout=5000 If the computer 10.2.114.40 is turned off, then it throws error and connection not created even if the computers 10.2.152.190 and 10.2.112.178 are running. Testcase 1: 10.2.114.40 is ON but stopped ActiveMQ 10.2.152.190 is ON and started ActiveMQ there This case is working for the failover. Testcase 2: 10.2.114.40 is turned OFF 10.2.152.190 is ON and started ActiveMQ there This case is NOT working for the failover. Following error is thrown in this case:- Thread was being aborted. - mscorlib - at System.Threading.Monitor.Enter(Object obj) at Apache.NMS.ActiveMQ.Transport.Failover.FailoverTransport.Oneway(Command command) at Apache.NMS.ActiveMQ.Transport.TransportFilter.Oneway(Command command) at Apache.NMS.ActiveMQ.Transport.MutexTransport.Oneway(Command command) at Apache.NMS.ActiveMQ.Transport.ResponseCorrelator.AsyncRequest(Command command) at Apache.NMS.ActiveMQ.Transport.ResponseCorrelator.Request(Command command, TimeSpan timeout) at Apache.NMS.ActiveMQ.Connection.CheckConnected() at Apache.NMS.ActiveMQ.Connection.Start() at BrokerComm.ChannelManager.CheckConnection() in D:\Projects\MCCWAP\Source\BrokerComm\ChannelManager.cs:line 394 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQNET-490) Stomp Client 1.5.4 error creating subscription to topic on JBoss HornetQ (Jboss 6.4.2 GA)
[
https://issues.apache.org/jira/browse/AMQNET-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes updated AMQNET-490:
-
Fix Version/s: 1.8.0
Stomp Client 1.5.4 error creating subscription to topic on JBoss HornetQ
(Jboss 6.4.2 GA)
-
Key: AMQNET-490
URL: https://issues.apache.org/jira/browse/AMQNET-490
Project: ActiveMQ .Net
Issue Type: New Feature
Components: Stomp
Affects Versions: 1.5.4
Reporter: Harley Blumenfeld
Assignee: Jim Gomes
Fix For: 1.8.0
Maybe I am doing something dumb, but using a simple example I cannot seem to
get a topic subscription working using the Apache.NMS.Stomp version 1.5.4
(http://activemq.apache.org/nms/apachenmsstomp-v154.html).
I am compiling the Stomp source code and project under .Net 4.0. I have
created a console application in the Apache.NMS.Stomp solution. My program
fails when it attempts to create a subscription to the topic. The same
example works fine with the 1.5.3 version of the DLL so this seems like it
could be a bug.
bHere is the result of my simple program:/b
About to connect to stomp:tcp://myjboss:61613
Using destination: topic://jms.topic.test.topic
Connection Error: : Error creating subscription
IDcSTHBLUMENF-50514-635475847768724525-1:0c1:1
Connection Error:
Error: : Error creating subscription
IDcSTHBLUMENF-50514-635475847768724525-1:0c1:1
Error: at Apache.NMS.Stomp.Connection.SyncRequest(Command command, TimeSpan
requestTimeout) in
C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\src\main\csharp\Connection.cs:line
525
at Apache.NMS.Stomp.Connection.SyncRequest(Command command) in
C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\src\main\csharp\Connection.cs:line
505
at Apache.NMS.Stomp.Session.CreateConsumer(IDestination destination,
String selector, Boolean noLocal) in
C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\src\main\csharp\Session.cs:line
425
at Apache.NMS.Stomp.Session.CreateConsumer(IDestination destination) in
C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\src\main\csharp\Session.cs:line
379
at TopicSubscriberTest.Program.Main(String[] args) in
C:\dev\Apache.NMS.Stomp\source\branches\1.5.4\TopicSubscribeTest\Program.cs:line
31
bHere is the code:/b
class Program
{
private static void Main(string[] args)
{
try
{
var connecturi = new Uri(stomp:tcp://myjboss:61613);
Console.WriteLine(About to connect to + connecturi);
IConnectionFactory factory = new
NMSConnectionFactory(connecturi);
busing (IConnection connection =
factory.CreateConnection(testuser, test))/b
{
connection.ExceptionListener += new
ExceptionListener(OnConnectionException);
connection.Start();
using (ISession session =
connection.CreateSession())
{
connection.Start();
IDestination destination =
SessionUtil.GetDestination(session,topic://jms.topic.test.topic);
Console.WriteLine(Using destination:
+ destination);
using (IMessageConsumer consumer =
session.CreateConsumer(destination))
{
consumer.Listener += OnMessage;
while (true)
{
Thread.Sleep(5000);
Console.WriteLine(.);
}
}
}
}
}
catch (Exception e)
{
Console.WriteLine(Error: + e.Message);
Console.WriteLine(Error: + e.StackTrace);
Console.ReadLine();
}
}
private static void OnConnectionException(Exception e)
{
Console.WriteLine(Connection Error: + e.Message);
Console.WriteLine(Connection Error: + e.StackTrace);
}
protected static void OnMessage(IMessage receivedMsg)
{
var message = receivedMsg as ITextMessage;
Console.WriteLine(message.Text);
}
}
--
This message was sent by
[jira] [Resolved] (AMQNET-502) When a SocketException is thrown in DoConnect, invalid exception message is generated
[
https://issues.apache.org/jira/browse/AMQNET-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes resolved AMQNET-502.
--
Resolution: Fixed
Assignee: Jim Gomes
Set the socket exception error code to RTSSL_HANDSHAKE_FAILURE.
When a SocketException is thrown in DoConnect, invalid exception message is
generated
-
Key: AMQNET-502
URL: https://issues.apache.org/jira/browse/AMQNET-502
Project: ActiveMQ .Net
Issue Type: Improvement
Components: ActiveMQ
Affects Versions: 1.6.4, 1.7.0
Environment: Windows Server 2012, Visual Studio 2015
Reporter: Matthew Hintzen
Assignee: Jim Gomes
Priority: Minor
Labels: easyfix
Fix For: 1.7.1
Original Estimate: 1h
Remaining Estimate: 1h
When attempting to connect the TCP socket in TcpTransportFactory.cs in the
```DoConnect(host, port, localAddress, localPort)``` proc if all attempts to
call
```TryConnectSocket(ipaddress, port, localAddress, localPort)```
are unsucessful ( resulting in socket == null) at line 375 a
```throw new SocketException();```
is generated.
Since this SocketException has not message in it, it is then caught in turn
at line 380 and repackaged as
```throw new NMSConnectionException(String.Format(Error connecting to
{0}:{1}., host, port), ex);```
Unfortunately when a SocketException is thrown with no default error message,
the inner exception text shows as The operation completed successfully for
any client consuming application.
I recommend that we give back some more meaningful and relevant information.
```InnerException:
ErrorCode=0
HResult=-2147467259
Message=The operation completed successfully
NativeErrorCode=0
Source=Apache.NMS.ActiveMQ
StackTrace:
at
Apache.NMS.ActiveMQ.Transport.Tcp.TcpTransportFactory.DoConnect(String host,
Int32 port, String localAddress, Int32 localPort)
```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQNET-422) Added support for transactions for Asyncronous Listeners
[
https://issues.apache.org/jira/browse/AMQNET-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes updated AMQNET-422:
-
Fix Version/s: 1.8.0
Added support for transactions for Asyncronous Listeners
Key: AMQNET-422
URL: https://issues.apache.org/jira/browse/AMQNET-422
Project: ActiveMQ .Net
Issue Type: New Feature
Components: ActiveMQ
Reporter: Remo Gloor
Assignee: Jim Gomes
Priority: Minor
Fix For: 1.8.0
Attachments: AddedSupportForAmbientTransactionForAsyncConsumers -
When_AMQNET-413_IsFixed.patch,
AddedSupportForAmbientTransactionForAsyncConsumers.patch,
AddedSupportForAmbientTransactionForAsyncConsumers.patch,
allDTCImprovments.patch
Asyncronous Listeners do not support transactions properly. I suggest to add
the option to register a callback that can be used to create a transaction
for each message received by the asyncronous listener.
e.g.
((MessageConsumer)consumer).CreateTransactionScopeForAsyncMessage =
this.CreateScope;
private TransactionScope CreateScope()
{
return new TransactionScope(TransactionScopeOption.RequiresNew);
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQNET-501) The InitialRedeliveryDelay doesn't seem to work.
[ https://issues.apache.org/jira/browse/AMQNET-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes resolved AMQNET-501. -- Resolution: Not A Problem Fix Version/s: (was: 1.8.0) The InitialRedeliveryDelay is only used if the NonBlockingRedelivery flag is set to true. The InitialRedeliveryDelay doesn't seem to work. Key: AMQNET-501 URL: https://issues.apache.org/jira/browse/AMQNET-501 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ Affects Versions: 1.6.0 Environment: Win 7 Pro SP 1 Reporter: David Elliott Assignee: Jim Gomes Priority: Trivial ActiveMQ v5.9.1 Apache.NMS v1.6.0.3083 The InitialRedeliveryDelay doesn't seem to work. I added a try...catch block to display the time and then re-throw so I could see what was going on. I'm looking to wait 5 seconds initially and then 5 seconds in between each attempt. You can see the first exception is immediately followed by the second and then 5 seconds in between. A first chance exception of type 'System.Collections.Generic.KeyNotFoundException' occurred in mscorlib.dll 6/1/2015 11:59:00 AM A first chance exception of type 'System.Collections.Generic.KeyNotFoundException' occurred in mscorlib.dll 6/1/2015 11:59:00 AM A first chance exception of type 'System.Collections.Generic.KeyNotFoundException' occurred in mscorlib.dll 6/1/2015 11:59:05 AM A first chance exception of type 'System.Collections.Generic.KeyNotFoundException' occurred in mscorlib.dll 6/1/2015 11:59:10 AM A first chance exception of type 'System.Collections.Generic.KeyNotFoundException' occurred in mscorlib.dll 6/1/2015 11:59:16 AM A first chance exception of type 'System.Collections.Generic.KeyNotFoundException' occurred in mscorlib.dll 6/1/2015 11:59:21 AM A first chance exception of type 'System.Collections.Generic.KeyNotFoundException' occurred in mscorlib.dll 6/1/2015 11:59:26 AM Here is my code and values. It doesn't matter whether UseExponentialBackOff is on or off. var connectionFactory = new ConnectionFactory(_queueInfo.URI); connectionFactory.RedeliveryPolicy.MaximumRedeliveries = _queueInfo.RetryCount; // 6 connectionFactory.RedeliveryPolicy.RedeliveryDelay(_queueInfo.RedeliveryDelay); // 5000 connectionFactory.RedeliveryPolicy.InitialRedeliveryDelay = _queueInfo.RedeliveryDelay; // 5000 connectionFactory.RedeliveryPolicy.BackOffMultiplier = _queueInfo.BackOffMultiplier; // 1 connectionFactory.RedeliveryPolicy.UseExponentialBackOff = true; // _queueInfo.AcknowledgementMode = IndividualAcknowledge _connection = QueueConnectionFactory.CreateConnection(connectionFactory, _queueInfo.QueueName, _queueInfo.QueueParameters, _queueInfo.AcknowledgementMode); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQNET-398) NetTx transaction support in WCF binding
[ https://issues.apache.org/jira/browse/AMQNET-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes resolved AMQNET-398. -- Resolution: Fixed Applied the submitted patches with one small change. In the Dispatch() function, the new behavior of rethrowing exception is only done if the session is transacted. This will help preserve existing behavior, but will support the transaction semantics for rollback on error. NetTx transaction support in WCF binding Key: AMQNET-398 URL: https://issues.apache.org/jira/browse/AMQNET-398 Project: ActiveMQ .Net Issue Type: Improvement Components: ActiveMQ, WCF Reporter: Andrea Montemaggio Assignee: Jim Gomes Priority: Minor Labels: transaction Fix For: 1.7.1 Attachments: Apache.NMS.ActiveMQ-NetTx.patch, Apache.NMS.WCF-NetTx.patch I needed to support .NET style distributed transactions with ActiveMQ broker and provided NMS WCF binding, but we can't get it working out of the box. Because of WCF binding lacks explicit support for this scenario, I tried to fool it by supplying a wrapper for INetTxConnectionFactory (and a related one for INetTxConnection) as an IConnectionFactory through nmsprovider-*.config file. Despite being able to make WCF binding to instantiate my wrapper class (and so, NetTxConnectionFactory under the hood), I needed to modify slightly WCF binding code in two points: * NmsOutputChannel: here I noticed that a premature session disposing due to the using block caused a deadlock when the ISession implementation was NetTxSession who waits for transaction to complete (TransactionContext.DtcWaitHandle.WaitOne() in Close() method). This phenomenon was not evident in the provided test code, because of the TransactionScope block is always INSIDE the using block that scopes the session. Using WCF binding is somewhat higher level, so I'm forced to wrap the WCF call with a TransactionScope. The modification I've made is to handle the non-transactional case like before, and to defer session disposing when inside a transaction (for this I've used provided events TransactionCommittedListener and TransactionRolledBackListener). * NmsInputChannelListener: assuming a service method with OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true), my perception of the expected behavior when an exception is thrown in the service method is that the active transaction must be rolled back. Here we are on the receiving part (NMS WCF binding is below service code in the stack!) so to ensure this behavior (I stress this here: it's the expected behavior for me), I've had to provide a WCF custom IErrorHandler to raise an exception in HandleError method, that NMS WCF binding could be catch and rollback the active transaction. To obtain this, I've had to rethrow the exception in Dispatch method. I don't know if this may cause troubles. Morover, I discovered a bug in ActiveMQ provider NetTxConnection.GuidFromId: the implementation does not cares that the hyphen is a valid character hostnames. I attach two patches here: one for the WCF binding component with the described changes, another for ActiveMQ provider with the transaction id translation fix and a minor one at a logging statement. Best Regards, Andrea Montemaggio -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQNET-458) Create a new NMS provider library for the MQTT protocol
[ https://issues.apache.org/jira/browse/AMQNET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-458: - Component/s: (was: NMS) MQTT Create a new NMS provider library for the MQTT protocol --- Key: AMQNET-458 URL: https://issues.apache.org/jira/browse/AMQNET-458 Project: ActiveMQ .Net Issue Type: Task Components: MQTT Reporter: Timothy Bish Assignee: Timothy Bish Create a new provider library for the MQTT protocol v3.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQNET-458) Create a new NMS provider library for the MQTT protocol
[ https://issues.apache.org/jira/browse/AMQNET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-458: - Fix Version/s: 1.7.1 Create a new NMS provider library for the MQTT protocol --- Key: AMQNET-458 URL: https://issues.apache.org/jira/browse/AMQNET-458 Project: ActiveMQ .Net Issue Type: Task Components: MQTT Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 1.7.1 Create a new provider library for the MQTT protocol v3.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQNET-458) Create a new NMS provider library for the MQTT protocol
[ https://issues.apache.org/jira/browse/AMQNET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes resolved AMQNET-458. -- Resolution: Fixed This looks to be a sufficient starting point for this provider implementation. Marking this item as resolved. New issues can be entered separately. Create a new NMS provider library for the MQTT protocol --- Key: AMQNET-458 URL: https://issues.apache.org/jira/browse/AMQNET-458 Project: ActiveMQ .Net Issue Type: Task Components: MQTT Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 1.7.1 Create a new provider library for the MQTT protocol v3.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQNET-354) Add new NMS Provider Implementation that provides Pooling for NMS Provider Connection Resources
[ https://issues.apache.org/jira/browse/AMQNET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-354: - Fix Version/s: (was: 1.6.1) 1.8.0 Add new NMS Provider Implementation that provides Pooling for NMS Provider Connection Resources --- Key: AMQNET-354 URL: https://issues.apache.org/jira/browse/AMQNET-354 Project: ActiveMQ .Net Issue Type: Improvement Components: NMS Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor Fix For: 1.8.0 Create a new NMS Provider that serves as a wrapper around NMS Provider Connections and acts to pool the Connection and its associated resources for use in long running applications which may create and close connections over time or for applications that create and destroy lots of connections and sessions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQNET-492) MessageId assumed to be a number
[
https://issues.apache.org/jira/browse/AMQNET-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes updated AMQNET-492:
-
Fix Version/s: 1.7.1
MessageId assumed to be a number
Key: AMQNET-492
URL: https://issues.apache.org/jira/browse/AMQNET-492
Project: ActiveMQ .Net
Issue Type: Bug
Components: Stomp
Affects Versions: 1.5.4
Environment: Windows8, VisualStudio Express 2013
Reporter: Otto Chrons
Assignee: Jim Gomes
Fix For: 1.7.1
When NMS.Stomp receives a message with a messageId containing something else
than a number, it will throw an exception:
{noformat}
Unhandled Exception: Apache.NMS.NMSException: Input string was not in a
correct format. --- System.FormatException: Input string was not in a
correct format.
at System.Number.StringToNumber(String str, NumberStyles options,
NumberBuffer number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseInt64(String value, NumberStyles options,
NumberFormatInfo numfmt)
at Apache.NMS.Stomp.Commands.MessageId.SetValue(String messageKey)
at Apache.NMS.Stomp.Protocol.StompWireFormat.ReadMessage(StompFrame frame)
at Apache.NMS.Stomp.Protocol.StompWireFormat.CreateCommand(StompFrame
frame)
at Apache.NMS.Stomp.Protocol.StompWireFormat.Unmarshal(BinaryReader dataIn)
at Apache.NMS.Stomp.Transport.Tcp.TcpTransport.ReadLoop()
--- End of inner exception stack trace ---
at Apache.NMS.Stomp.MessageConsumer.Dequeue(TimeSpan timeout)
at Apache.NMS.Stomp.MessageConsumer.Receive(TimeSpan timeout)
{noformat}
Message headers (according to Apollo web UI)
content-length50652
correlation-id5e3b57eae6af6d54e0426dae4ef14732
destination /queue/OCRRequest
message-idID:default-3ec-17
receipt 18
persistenttrue
transformationTEXT
reply-to
/queue/temp.default.default-3ec.d1b799a4-b165-422f-b5cc-dd2cb4ff5442
According to the specification the messageId is a string and doesn't
necessarily contain a valid number following the semicolon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQNET-492) MessageId assumed to be a number
[
https://issues.apache.org/jira/browse/AMQNET-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes updated AMQNET-492:
-
Component/s: (was: NMS)
MessageId assumed to be a number
Key: AMQNET-492
URL: https://issues.apache.org/jira/browse/AMQNET-492
Project: ActiveMQ .Net
Issue Type: Bug
Components: Stomp
Affects Versions: 1.5.4
Environment: Windows8, VisualStudio Express 2013
Reporter: Otto Chrons
Assignee: Jim Gomes
Fix For: 1.7.1
When NMS.Stomp receives a message with a messageId containing something else
than a number, it will throw an exception:
{noformat}
Unhandled Exception: Apache.NMS.NMSException: Input string was not in a
correct format. --- System.FormatException: Input string was not in a
correct format.
at System.Number.StringToNumber(String str, NumberStyles options,
NumberBuffer number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseInt64(String value, NumberStyles options,
NumberFormatInfo numfmt)
at Apache.NMS.Stomp.Commands.MessageId.SetValue(String messageKey)
at Apache.NMS.Stomp.Protocol.StompWireFormat.ReadMessage(StompFrame frame)
at Apache.NMS.Stomp.Protocol.StompWireFormat.CreateCommand(StompFrame
frame)
at Apache.NMS.Stomp.Protocol.StompWireFormat.Unmarshal(BinaryReader dataIn)
at Apache.NMS.Stomp.Transport.Tcp.TcpTransport.ReadLoop()
--- End of inner exception stack trace ---
at Apache.NMS.Stomp.MessageConsumer.Dequeue(TimeSpan timeout)
at Apache.NMS.Stomp.MessageConsumer.Receive(TimeSpan timeout)
{noformat}
Message headers (according to Apollo web UI)
content-length50652
correlation-id5e3b57eae6af6d54e0426dae4ef14732
destination /queue/OCRRequest
message-idID:default-3ec-17
receipt 18
persistenttrue
transformationTEXT
reply-to
/queue/temp.default.default-3ec.d1b799a4-b165-422f-b5cc-dd2cb4ff5442
According to the specification the messageId is a string and doesn't
necessarily contain a valid number following the semicolon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work stopped] (AMQNET-503) DTC Transactions do not respect rollbacks consistently leading to duplicated messages
[ https://issues.apache.org/jira/browse/AMQNET-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQNET-503 stopped by Jim Gomes. DTC Transactions do not respect rollbacks consistently leading to duplicated messages - Key: AMQNET-503 URL: https://issues.apache.org/jira/browse/AMQNET-503 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ Reporter: Jose Alvarado Assignee: Jim Gomes Attachments: Apache Documentation.docx, Apache.NMS.AMQNETIssue.patch, Apache.NMS.ActiveMQ.AMQNETIssue.patch In certain circumstances, rollback does not work properly, as a result duplicate messages are generated from normal DTC operations. The circumstances under which this issues occurs are: - DTC transaction initiated, but fails to commit; - Another DTC transaction initiated and successfully commits; - When a transaction is roll backed and committed on retry; As a result the number of messages sent is larger to the number of messages received by the target broker. Some of the messages are not roll backed when it fails and they get sent again when committed on retry. This issue has been raised in Jira as issues 413 and 472: https://issues.apache.org/jira/browse/AMQNET-413 https://issues.apache.org/jira/browse/AMQNET-472 Analysing the code we realised that these two issues above are similar, and they have the same cause. We have therefore developed a patch based on feedback and unit tests provided by those two issues, where we fix the problem and we pass all existing unit tests. The changes modify only code related to DTC, and it was developed in .NET 2.0 as per the requirements for 413/472 The fix implements the solution suggested in the patch for issue 472 where some lock conditions were missing. In addition we have added a condition where we will not lock the transaction whenever a distributed transaction occurs. The DtcWaitHandle.WaitOne causes DTC transactions involving a database or XA transaction to fail unit testing. The patch was extensively tested with over a 1000 messages (1K, 1.5K, 10K, 100K, 1M) using two brokers across different servers to guarantee distributed transactions. Testing also included different message sizes, infrastructure setup, databases, and message content verification to validate its integrity and ensure messages were not duplicated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQNET-503) DTC Transactions do not respect rollbacks consistently leading to duplicated messages
[ https://issues.apache.org/jira/browse/AMQNET-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes resolved AMQNET-503. -- Resolution: Fixed Fix Version/s: 1.7.1 Merged the fix into the trunk and into the 1.7.x branches to prepare for the 1.7.1 release. Updated the separated NMS provider modules to create a new 1.7.x branch for each that will use the new NMS 1.7.1 API version. Thanks to Jose Alvarado for submitting the fix along with the test case and documentation write-up. Great job! DTC Transactions do not respect rollbacks consistently leading to duplicated messages - Key: AMQNET-503 URL: https://issues.apache.org/jira/browse/AMQNET-503 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ Reporter: Jose Alvarado Assignee: Jim Gomes Fix For: 1.7.1 Attachments: Apache Documentation.docx, Apache.NMS.AMQNETIssue.patch, Apache.NMS.ActiveMQ.AMQNETIssue.patch In certain circumstances, rollback does not work properly, as a result duplicate messages are generated from normal DTC operations. The circumstances under which this issues occurs are: - DTC transaction initiated, but fails to commit; - Another DTC transaction initiated and successfully commits; - When a transaction is roll backed and committed on retry; As a result the number of messages sent is larger to the number of messages received by the target broker. Some of the messages are not roll backed when it fails and they get sent again when committed on retry. This issue has been raised in Jira as issues 413 and 472: https://issues.apache.org/jira/browse/AMQNET-413 https://issues.apache.org/jira/browse/AMQNET-472 Analysing the code we realised that these two issues above are similar, and they have the same cause. We have therefore developed a patch based on feedback and unit tests provided by those two issues, where we fix the problem and we pass all existing unit tests. The changes modify only code related to DTC, and it was developed in .NET 2.0 as per the requirements for 413/472 The fix implements the solution suggested in the patch for issue 472 where some lock conditions were missing. In addition we have added a condition where we will not lock the transaction whenever a distributed transaction occurs. The DtcWaitHandle.WaitOne causes DTC transactions involving a database or XA transaction to fail unit testing. The patch was extensively tested with over a 1000 messages (1K, 1.5K, 10K, 100K, 1M) using two brokers across different servers to guarantee distributed transactions. Testing also included different message sizes, infrastructure setup, databases, and message content verification to validate its integrity and ensure messages were not duplicated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQNET-472) Synchronous DTC Consumer will experience duplicates on transaction rollback
[
https://issues.apache.org/jira/browse/AMQNET-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes resolved AMQNET-472.
--
Resolution: Done
Synchronous DTC Consumer will experience duplicates on transaction rollback
---
Key: AMQNET-472
URL: https://issues.apache.org/jira/browse/AMQNET-472
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Affects Versions: 1.6.2
Reporter: Imran
Assignee: Jim Gomes
Attachments: NetTxMessageConsumer.patch
Rollback when using DTC will result in a duplicate message being received.
{code:title=FailingTest|borderStyle=solid}
using System;
using System.Configuration;
using System.ServiceProcess;
using System.Transactions;
using Apache.NMS;
using Apache.NMS.ActiveMQ;
using Apache.NMS.Policies;
using Apache.NMS.Util;
using Common.Logging;
using Common.Logging.Simple;
using NUnit.Framework;
namespace IntegrationTests.ApacheNms.Jira
{
[TestFixture]
public class Dtc
{
[Test, Explicit(Bug in 1.6.2)]
public void
First_message_should_be_redilivered_and_republished_on_rollback_and_second_message_processed_as_normal()
{
SendMessageToQueue(1);
SendMessageToQueue(2);
var session = _connection.CreateSession();
var sessionTwo = _connection.CreateSession();
var consumer =
session.CreateConsumer(SessionUtil.GetDestination(session, InQueue));
var producer =
sessionTwo.CreateProducer(SessionUtil.GetDestination(session, OutQueue));
_log.Debug(Process message one and rollback);
var transaction = new
TransactionScope(TransactionScopeOption.RequiresNew);
var message = consumer.Receive(TimeSpan.FromSeconds(30));
producer.Send(message);
transaction.Dispose();
_log.Debug(Processing message two and commit);
transaction = new
TransactionScope(TransactionScopeOption.RequiresNew);
message = consumer.Receive(TimeSpan.FromSeconds(30));
producer.Send(message);
transaction.Complete();
transaction.Dispose();
_log.Debug(Processing message one replay and commit);
transaction = new
TransactionScope(TransactionScopeOption.RequiresNew);
message = consumer.Receive(TimeSpan.FromSeconds(30));
producer.Send(message);
transaction.Complete();
transaction.Dispose();
_log.Debug(Process any repeats, there should be none);
transaction = new
TransactionScope(TransactionScopeOption.RequiresNew);
message = consumer.Receive(TimeSpan.FromSeconds(30));
if (message != null)
producer.Send(message);
transaction.Complete();
transaction.Dispose();
session.Dispose();
sessionTwo.Dispose();
Assert.That(CountMessagesInQueue(InQueue), Is.EqualTo(0));
Assert.That(CountMessagesInQueue(OutQueue), Is.EqualTo(2));
}
public static void TransactionCallback(object s, TransactionEventArgs
e)
{
LogManager.GetCurrentClassLogger().DebugFormat(Tranasaction
{0}, e.Transaction.TransactionInformation.Status);
}
private int CountMessagesInQueue(string queue)
{
var count = 0;
using (var session = _connection.CreateSession())
using (var consumerIn =
session.CreateConsumer(SessionUtil.GetDestination(session, queue)))
using (var scope = new
TransactionScope(TransactionScopeOption.RequiresNew))
{
while (true)
{
var msg = consumerIn.Receive(TimeSpan.FromSeconds(2));
if (msg == null)
break;
count++;
}
}
return count;
}
private void StartService(ServiceController service)
{
if (service.Status != ServiceControllerStatus.Running)
service.Start();
service.WaitForStatus(ServiceControllerStatus.Running);
_log.Debug(Started Broker);
}
private void StopService(ServiceController service)
{
if (service.Status != ServiceControllerStatus.Stopped)
service.Stop();
service.WaitForStatus(ServiceControllerStatus.Stopped);
_log.Debug(Stopped Broker Broker);
}
private void SendMessageToQueue(string message)
{
using (var session = _connection.CreateSession())
using (var producer =
[jira] [Resolved] (AMQNET-413) Message consumers do not respect DTC Transactions correctly
[
https://issues.apache.org/jira/browse/AMQNET-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes resolved AMQNET-413.
--
Resolution: Done
Message consumers do not respect DTC Transactions correctly
---
Key: AMQNET-413
URL: https://issues.apache.org/jira/browse/AMQNET-413
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ
Reporter: Remo Gloor
Assignee: Jim Gomes
Attachments: AMQNET-413.patch,
AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
AllMessagesAreAcknowledgedAndRolledbackIndependentOfTheTransaction.patch,
allDTCImprovments.patch
When consuming messages in a transaction and sending new ones during
processing of that message and the transaction is rolled back and commited on
retry the number of published messages should be equal to the received one.
But the number of sent message is bigger than the number of received ones.
This means some of the message sends are not rolled back others are.
EDIT: Further analysis have shown that the TransactionContext.TransactionId
is null when sending eventhough a transaction is in progress and not yet
completed. It must incorrectly be assigned to null somewhere.
The following application demonstrates the problem when enqueuing 100+
messages to foo.bar
class Program
{
private static INetTxSession activeMqSession;
private static IMessageConsumer consumer;
private static INetTxConnection connection;
static void Main(string[] args)
{
using (connection = CreateActiveMqConnection())
using (activeMqSession = connection.CreateNetTxSession())
using (consumer =
activeMqSession.CreateConsumer(SessionUtil.GetQueue(activeMqSession,
queue://foo.bar)))
{
connection.Start();
while (true)
{
try
{
using (TransactionScope scoped = new
TransactionScope(TransactionScopeOption.RequiresNew))
{
IMessage msg = null;
while (msg == null)
{
msg = consumer.ReceiveNoWait();
}
OnMessage(msg);
scoped.Complete();
}
}
catch(Exception exception) {}
}
}
}
private static INetTxConnection CreateActiveMqConnection()
{
var connectionFactory = new
Apache.NMS.ActiveMQ.NetTxConnectionFactory(activemq:tcp://localhost:61616)
{
AcknowledgementMode = AcknowledgementMode.Transactional
};
return connectionFactory.CreateNetTxConnection();
}
private static void OnMessage(IMessage message)
{
var x = new TestSinglePhaseCommit();
Console.WriteLine(Processing message {0} in transaction {1} -
{2}, message.NMSMessageId,
Transaction.Current.TransactionInformation.LocalIdentifier,
Transaction.Current.TransactionInformation.DistributedIdentifier);
var session2 = activeMqSession;
{
Transaction.Current.EnlistDurable(Guid.NewGuid(), x,
EnlistmentOptions.None);
using (var producer =
session2.CreateProducer(SessionUtil.GetQueue(session2, queue://foo.baz)))
{
producer.Send(new ActiveMQTextMessage(foo));
}
if (!message.NMSRedelivered) throw new Exception();
}
}
}
internal class TestSinglePhaseCommit : ISinglePhaseNotification
{
public void Prepare(PreparingEnlistment preparingEnlistment)
{
preparingEnlistment.Prepared();
}
public void Commit(Enlistment enlistment)
{
enlistment.Done();
}
public void Rollback(Enlistment enlistment)
{
enlistment.Done();
}
public void InDoubt(Enlistment enlistment)
{
enlistment.Done();
}
public void SinglePhaseCommit(SinglePhaseEnlistment
singlePhaseEnlistment)
{
singlePhaseEnlistment.Committed();
}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (AMQNET-503) DTC Transactions do not respect rollbacks consistently leading to duplicated messages
[ https://issues.apache.org/jira/browse/AMQNET-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQNET-503 started by Jim Gomes. DTC Transactions do not respect rollbacks consistently leading to duplicated messages - Key: AMQNET-503 URL: https://issues.apache.org/jira/browse/AMQNET-503 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ Reporter: Jose Alvarado Assignee: Jim Gomes Attachments: Apache Documentation.docx, Apache.NMS.AMQNETIssue.patch, Apache.NMS.ActiveMQ.AMQNETIssue.patch In certain circumstances, rollback does not work properly, as a result duplicate messages are generated from normal DTC operations. The circumstances under which this issues occurs are: - DTC transaction initiated, but fails to commit; - Another DTC transaction initiated and successfully commits; - When a transaction is roll backed and committed on retry; As a result the number of messages sent is larger to the number of messages received by the target broker. Some of the messages are not roll backed when it fails and they get sent again when committed on retry. This issue has been raised in Jira as issues 413 and 472: https://issues.apache.org/jira/browse/AMQNET-413 https://issues.apache.org/jira/browse/AMQNET-472 Analysing the code we realised that these two issues above are similar, and they have the same cause. We have therefore developed a patch based on feedback and unit tests provided by those two issues, where we fix the problem and we pass all existing unit tests. The changes modify only code related to DTC, and it was developed in .NET 2.0 as per the requirements for 413/472 The fix implements the solution suggested in the patch for issue 472 where some lock conditions were missing. In addition we have added a condition where we will not lock the transaction whenever a distributed transaction occurs. The DtcWaitHandle.WaitOne causes DTC transactions involving a database or XA transaction to fail unit testing. The patch was extensively tested with over a 1000 messages (1K, 1.5K, 10K, 100K, 1M) using two brokers across different servers to guarantee distributed transactions. Testing also included different message sizes, infrastructure setup, databases, and message content verification to validate its integrity and ensure messages were not duplicated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ACTIVEMQ6-106) OpenWire Protocol Failure with NMS Clients
[
https://issues.apache.org/jira/browse/ACTIVEMQ6-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Gomes updated ACTIVEMQ6-106:
Description:
When attempting to connect an NMS client via OpenWire, a client cannot maintain
a stable consumer connection. After connecting a client for a short while, the
client will send the KeepAlive messages. However, it gets kicked out by the
server as having been idle for too long. The client goes in to its failover
reconnect code, and continually gets kicked off by the server.
Following are the exceptions thrown on the server:
{noformat}
ERROR [org.apache.activemq.artemis.core.server] error decoding:
java.lang.IllegalStateException: Cannot handle command: ConnectionControl
{commandId = 0, responseRequired = false, suspend = false, resume = false,
close = false, exit = false, faultTolerant = true, connectedBrokers = null,
reconnectTo = null, token = null, rebalanceConnection = false}
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.handleCommand(OpenWireProtocolManager.java:236)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:315)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
[artemis-server-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
[artemis-core-client-1.0.0.jar:1.0.0]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
ERROR [org.apache.activemq.artemis.core.server] error decoding:
java.lang.NullPointerException
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.fail(OpenWireConnection.java:450)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.disconnect(OpenWireConnection.java:515)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.processAddConnection(OpenWireConnection.java:640)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:139)
[activemq-client-5.10.0.jar:5.10.0]
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:271)
[artemis-openwire-protocol-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:694)
[artemis-server-1.0.0.jar:1.0.0]
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
[artemis-core-client-1.0.0.jar:1.0.0]
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
[netty-all-4.0.20.Final.jar:4.0.20.Final]
at
