[jira] Commented: (AMQ-3120) KahaDB error: Could not locate data file
[ https://issues.apache.org/jira/browse/AMQ-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991528#comment-12991528 ] Lei Huang commented on AMQ-3120: I'm new to fuse. Could someone help me, how can I find and download a specific release (5.4.2-fuse-01-00) on fusesource.com? Thanks, Lei KahaDB error: Could not locate data file -- Key: AMQ-3120 URL: https://issues.apache.org/jira/browse/AMQ-3120 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.4.2 Environment: linux: CentOS 5.5 happens on both dual- and quad-cpu boxes, 4gb ram java version 1.6.0_21 Java(TM) SE Runtime Environment (build 1.6.0_21-b06) Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode) Reporter: Dan Checkoway Assignee: Gary Tully Fix For: 5.5.0 I'm using an embedded broker (version 5.4.2) with persistence enabled. We're pumping hundreds of millions of messages per day through this thing. Every once in a while, all of a sudden the KahaDB directory starts growing uncontrollably, and these errors start spewing out in the log over and over... -- ERROR; Jan 5, 2011 16:37:57 PM; tid:BrokerService[localhost] Task; AbstractStoreCursor - Failed to fill batch java.lang.RuntimeException: java.io.IOException: Could not locate data file /usr/local/embedded/activemq-data/localhost/KahaDB/db-28098.log at org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:265) at org.apache.activemq.broker.region.cursors.AbstractStoreCursor.hasNext(AbstractStoreCursor.java:148) at org.apache.activemq.broker.region.cursors.StoreQueueCursor.hasNext(StoreQueueCursor.java:131) at org.apache.activemq.broker.region.Queue.doPageIn(Queue.java:1679) at org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:1898) at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1425) at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122) at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.IOException: Could not locate data file /usr/local/embedded/activemq-data/localhost/KahaDB/db-28098.log at org.apache.kahadb.journal.Journal.getDataFile(Journal.java:345) at org.apache.kahadb.journal.Journal.read(Journal.java:592) at org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:786) at org.apache.activemq.store.kahadb.KahaDBStore.loadMessage(KahaDBStore.java:956) at org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore$5.execute(KahaDBStore.java:494) at org.apache.kahadb.page.Transaction.execute(Transaction.java:728) at org.apache.activemq.store.kahadb.KahaDBStore$KahaDBMessageStore.recoverNextMessages(KahaDBStore.java:485) at org.apache.activemq.store.ProxyMessageStore.recoverNextMessages(ProxyMessageStore.java:88) at org.apache.activemq.broker.region.cursors.QueueStorePrefetch.doFillBatch(QueueStorePrefetch.java:97) at org.apache.activemq.broker.region.cursors.AbstractStoreCursor.fillBatch(AbstractStoreCursor.java:262) ... 10 more ERROR; Jan 5, 2011 16:37:57 PM; tid:BrokerService[localhost] Task; Queue - Failed to page in more queue messages java.lang.RuntimeException: java.lang.RuntimeException: java.io.IOException: Could not locate data file /usr/local/embedded/activemq-data/localhost/KahaDB/db-28098.log at org.apache.activemq.broker.region.cursors.AbstractStoreCursor.hasNext(AbstractStoreCursor.java:151) at org.apache.activemq.broker.region.cursors.StoreQueueCursor.hasNext(StoreQueueCursor.java:131) at org.apache.activemq.broker.region.Queue.doPageIn(Queue.java:1679) at org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:1898) at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1425) at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122) at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.RuntimeException: java.io.IOException: Could not locate data file
how to get 5.4.2-fuse-01-00 release on fusesource.com
Hi, I'm new to fuse. Could someone help me, how can I find and download a specific release (5.4.2-fuse-01-00) on fusesource.com? Thanks, Lei -- View this message in context: http://activemq.2283324.n4.nabble.com/how-to-get-5-4-2-fuse-01-00-release-on-fusesource-com-tp3264908p3264908.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Updated: (AMQCPP-348) Allow unverified SSL peer
[ https://issues.apache.org/jira/browse/AMQCPP-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQCPP-348: Priority: Minor (was: Major) Fix Version/s: 3.3.0 3.2.5 Allow unverified SSL peer - Key: AMQCPP-348 URL: https://issues.apache.org/jira/browse/AMQCPP-348 Project: ActiveMQ C++ Client Issue Type: Improvement Affects Versions: 3.2.4 Reporter: Kevin Quick Assignee: Timothy Bish Priority: Minor Fix For: 3.2.5, 3.3.0 When using an ssl: connection, attempting to only provide a client certificate via: decaf::lang::System::setProperty(decaf.net.ssl.keyStore, certfile); fails with the following: Error occurred while accessing an OpenSSL library method: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Init failure ERROR: Error occurred while accessing an OpenSSL library method: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed It would be nice if the library would set peer_verify to false if no decaf.net.ssl.trustStore was provided to allow the client to bypass verification of the broker. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQCPP-348) Allow unverified SSL peer
[
https://issues.apache.org/jira/browse/AMQCPP-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQCPP-348.
-
Resolution: Fixed
Added code to check for the property decaf.net.ssl.disablePeerVerification
and disable all verification if true.
client code sets via:
{noformat}
System::setProperty( decaf.net.ssl.disablePeerVerification, true )
{noformat}
Allow unverified SSL peer
-
Key: AMQCPP-348
URL: https://issues.apache.org/jira/browse/AMQCPP-348
Project: ActiveMQ C++ Client
Issue Type: Improvement
Affects Versions: 3.2.4
Reporter: Kevin Quick
Assignee: Timothy Bish
Priority: Minor
Fix For: 3.2.5, 3.3.0
When using an ssl: connection, attempting to only provide a client
certificate via:
decaf::lang::System::setProperty(decaf.net.ssl.keyStore,
certfile);
fails with the following:
Error occurred while accessing an OpenSSL library method:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed
Init failure ERROR: Error occurred while accessing an OpenSSL library method:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed
It would be nice if the library would set peer_verify to false if no
decaf.net.ssl.trustStore was provided to allow the client to bypass
verification of the broker.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQCPP-321) Created separate producer and consumer examples
[ https://issues.apache.org/jira/browse/AMQCPP-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQCPP-321. - Resolution: Fixed Fix Version/s: 1.0 Patch applied, thanks! Created separate producer and consumer examples --- Key: AMQCPP-321 URL: https://issues.apache.org/jira/browse/AMQCPP-321 Project: ActiveMQ C++ Client Issue Type: Improvement Reporter: Scott Cranton Assignee: Timothy Bish Fix For: 1.0 Attachments: mypatch.diff split example into separate producer and consumer to make easier to test against Java clients -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: how to get 5.4.2-fuse-01-00 release on fusesource.com
Hi Lei! You can find it here - http://repo.fusesource.com/nexus/content/repositories/releases/org/apache/activemq/apache-activemq/5.4.2-fuse-01-00/ Note that you should probably use the FuseSource forums to ask for help on the FuseSource distributions, this list (also note you want to use the user list for help, not the dev list) is for the Apache distribution. Forums are here - http://fusesource.com/forums/index.jspa On Mon, Feb 7, 2011 at 2:38 PM, Lei lehu...@paypal.com wrote: Hi, I'm new to fuse. Could someone help me, how can I find and download a specific release (5.4.2-fuse-01-00) on fusesource.com? Thanks, Lei -- View this message in context: http://activemq.2283324.n4.nabble.com/how-to-get-5-4-2-fuse-01-00-release-on-fusesource-com-tp3264908p3264908.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Stan Lewis FuseSource Email: sle...@fusesource.com Web: http://fusesource.com Twitter: gashcrumb
[jira] Updated: (AMQNET-305) Failover reconnect doesn't work correct in NMS 1.5.0 and memory usage is still growing.
[ https://issues.apache.org/jira/browse/AMQNET-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-305: - Component/s: (was: NMS) Failover reconnect doesn't work correct in NMS 1.5.0 and memory usage is still growing. --- Key: AMQNET-305 URL: https://issues.apache.org/jira/browse/AMQNET-305 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ Affects Versions: 1.5.0 Environment: windows 7 Reporter: Kaminiecki Assignee: Jim Gomes Priority: Critical I use four brokers 5.4.2 in the cluster. activemq client 1.4.1 and new NMS 1.5.0 I just started testing a new NSM 1.5.0 and I had a problem with the network through which I have not had access to three of the brokers during the test. However, I had one visible on the network but the client did not switched to. Just so happens that one is in a different subnet than the three others. I had three clients connected to one topic with the uri failover (4 brokes url) All clients had the same uri. One of them was sending 10 messages per second. When network connection dissapeard with three of the brokers. Message producer began to consume more memory. It was growing and growing. When I wanted to stop them, the producer stuck! Now I found somthing interesting more the 4th broker was stopped so so in this case no working broker or destination with brokers were available. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQNET-294) durable subscription message loss when master broker fails to slave
[ https://issues.apache.org/jira/browse/AMQNET-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-294: - Component/s: (was: NMS) ActiveMQ durable subscription message loss when master broker fails to slave --- Key: AMQNET-294 URL: https://issues.apache.org/jira/browse/AMQNET-294 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ Affects Versions: 1.4.1 Environment: Windows 7 (client), Windows Server 2008 64-bit (server brokers run on), Sql Server 2008 (database) Reporter: Mark Gellings Assignee: Jim Gomes Attachments: Apache.NMS.Test (2).zip, Apache.NMS.Test.zip, DurableConsumerTest.cs, DurableSubscriberFailoverTest.java, NMSLog.txt, NMSLogLocalFreshCannedActiveMQ542Broker.txt, TimsTestRevisedSlightly.zip We are seeing message loss on a durable subscription when using NMS ActiveMQ v1.4.1 and ActiveMQ v5.4.1. Please run the included NUnit test and watch the console output. When it says Failover the broker now! do as it says. About 75% of the time less than half of the expected 250 messages come through. Using version 1.1 of NMS the majority of the time the test passes. I have seen it fail only a few times with this earlier version, and when it does there are only a couple messages that don't come through. In the zip file will be the unit test, and a config directory containing the master and slave activemq configurations. We are using JDBC master/slave. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQNET-243) failover causes duplicate messages
[ https://issues.apache.org/jira/browse/AMQNET-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-243: - Component/s: (was: NMS) ActiveMQ Fix Version/s: 1.6.0 failover causes duplicate messages -- Key: AMQNET-243 URL: https://issues.apache.org/jira/browse/AMQNET-243 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ Affects Versions: 1.1.0 Reporter: Mark Gellings Assignee: Jim Gomes Fix For: 1.6.0 Attachments: IdempotentConsumer.zip Reference https://issues.apache.org/activemq/browse/AMQ-2627 for specifics on problem. Attached to that issue is a zip file which is password protected with password fridaytest. We're using ActiveMQ v5.2, jdbc master/slave MSSQL 2008. Attached is an NMS v1.2 RC4 consumer with a transacted session as well as activemq.xml. To replicate: 1) Work through the console prompts and produce 50 msgs. 2) Restart console and start consuming those 50 msgs. 3) In the middle of the consumer processing, restart broker 4) The last message consumer was processing will be resent and not marked as redelivered. (this is the idempotent msg problem. Ex. - instead of $500 getting deposited into your account, $1000 does) 5) Then NMS blows up which seems like a different problem? From what I understand this shouldn't be the case if you use a transacted session, however the attached console app can prove it is a problem. Bottomline--I thought this was why the camel idempotent consumer pattern [1] existed which can be leveraged by java clients. [1] http://fusesource.com/docs/router/1.6/eip/MsgEnd-Idempotent.html Regards, Mark -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQNET-201) WCF binding to support request reply message exchange
[ https://issues.apache.org/jira/browse/AMQNET-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-201: - Component/s: (was: NMS) WCF WCF binding to support request reply message exchange - Key: AMQNET-201 URL: https://issues.apache.org/jira/browse/AMQNET-201 Project: ActiveMQ .Net Issue Type: Improvement Components: WCF Affects Versions: 1.1.0 Reporter: Mark Pollack Assignee: Jim Gomes Priority: Minor I remember a while back there was some discussion on a JIRA issue where there was an explicit decision not to implement the request reply message exchange pattern in the WCF binding. I think this is not the correct decision. Request/Reply is a natural interaction for messaging systems, though clearly not the default. Implementation options are to use a temporary queue as the return destination or to setup a standard queue but create a message listener with a selector. Just for reference the TIBCO WCF binding supports request reply message exchange. A customer driven motivation behind this is that usually everyone creates request/reply endpoints over http transport in WCF. When they want to switch transports to messaging they discover (in MSMQ case) that they can't and would have to redesign their entire web services design to accomodate using JMS transport. This is simply not needed. Please reconsider and let's discuss more. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (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 ] Jim Gomes updated AMQNET-185: - Component/s: XMS 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 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 is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQNET-290) Add an API model to NMS that allows providers to participate in Distributed Transactions.
[ https://issues.apache.org/jira/browse/AMQNET-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-290: - Component/s: ActiveMQ Add an API model to NMS that allows providers to participate in Distributed Transactions. - Key: AMQNET-290 URL: https://issues.apache.org/jira/browse/AMQNET-290 Project: ActiveMQ .Net Issue Type: New Feature Components: ActiveMQ, NMS Affects Versions: 1.4.0 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor Fix For: 1.5.0 Currently the NMS API doesn't define any way for the client to participate in distributed transactions. The JMS model allows a for this using the Java XA transactions. The JMS API defines an XAConnectionFactory, XAConnection, and XASession that provide the needed bits to interact with a Transaction Manager. We should provide something similar in NMS that allows for a provider library like NMS.ActiveMQ to be used in distributed transactions in .NET most likely using the MSDTC. The API could expose an IEnlistmentNotification implementation that allows the client to enlist the Transaction in a DTC controlled transaction as a Resource Manager. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQNET-305) Failover reconnect doesn't work correct in NMS 1.5.0 and memory usage is still growing.
[ https://issues.apache.org/jira/browse/AMQNET-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes updated AMQNET-305: - Fix Version/s: 1.5.0 Failover reconnect doesn't work correct in NMS 1.5.0 and memory usage is still growing. --- Key: AMQNET-305 URL: https://issues.apache.org/jira/browse/AMQNET-305 Project: ActiveMQ .Net Issue Type: Bug Components: ActiveMQ Affects Versions: 1.5.0 Environment: windows 7 Reporter: Kaminiecki Assignee: Jim Gomes Priority: Critical Fix For: 1.5.0 I use four brokers 5.4.2 in the cluster. activemq client 1.4.1 and new NMS 1.5.0 I just started testing a new NSM 1.5.0 and I had a problem with the network through which I have not had access to three of the brokers during the test. However, I had one visible on the network but the client did not switched to. Just so happens that one is in a different subnet than the three others. I had three clients connected to one topic with the uri failover (4 brokes url) All clients had the same uri. One of them was sending 10 messages per second. When network connection dissapeard with three of the brokers. Message producer began to consume more memory. It was growing and growing. When I wanted to stop them, the producer stuck! Now I found somthing interesting more the 4th broker was stopped so so in this case no working broker or destination with brokers were available. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (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 ] Jim Gomes updated AMQNET-185: - Fix Version/s: 1.6.0 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 Fix For: 1.6.0 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 is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQNET-130) WCF provider is catching exceptions thrown by WCF service implementation
[ https://issues.apache.org/jira/browse/AMQNET-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991677#comment-12991677 ] Jim Gomes commented on AMQNET-130: -- I reviewed the exception handlers NmsInputChannelListener::OnExceptionThrown() and NmsInputSessionChannelListener::OnExceptionThrown(). Both of these exception handlers have filters set on them to only handle NMSException types. All other exception types are re-thrown up the exception handler chain. Based on that review, the recommended behavior is what appears to be coded, therefore I am closing this bug. WCF provider is catching exceptions thrown by WCF service implementation Key: AMQNET-130 URL: https://issues.apache.org/jira/browse/AMQNET-130 Project: ActiveMQ .Net Issue Type: Bug Components: WCF Affects Versions: 1.1.0 Environment: Windows Server 2003 SP1, ActiveMQ 5.2.0, latest Apache.NMS and Apache.NMS.ActiveMQ Reporter: David Keaveny Assignee: Jim Gomes Original Estimate: 10h Remaining Estimate: 10h Exceptions that occur within WCF service implementations are being caught by the WCF provider and swallowed, so that the service never sees the exception. The exceptions *are* logged to the WCF trace log though, if the system.diagnostics / configuration section is defined. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-3172) Add support for Message Priority to Stomp
[ https://issues.apache.org/jira/browse/AMQ-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991679#comment-12991679 ] Timothy Bish commented on AMQ-3172: --- The test given isn't quite right in that it produces to the Queue and then immediately creates a consumer and consumes a message. What can happen here is that the first message sent is dispatched and processed before the second message even makes it onto the Queue and so it appears to be out of order but in fact its not. You can see this by inserting a small sleep just after sending the second message, in this case both messages will be placed on the brokers queue and dispatched in the correct order. You could also place a small sleep after the consumer create so that both messages arrive in the consumers prefetch buffer and then see that they are dequeued in the correct order. Add support for Message Priority to Stomp - Key: AMQ-3172 URL: https://issues.apache.org/jira/browse/AMQ-3172 Project: ActiveMQ Issue Type: Improvement Components: Transport Affects Versions: 5.4.2 Reporter: Craig Lewis Priority: Minor Attachments: StompTest.java.patch Creating a Stomp message with a priority header has no effect. The messages are delivered in FIFO order, not priority order. The Stomp transport (activemq-core/src/main/java/org/apache/activemq/transport/stomp/FrameTranslator.java) is calling msg.setJMSPriority(), but never calls producer.setPriority(). Because of this, messages claims to have a priority, but the messages are never actually re-ordered. I believe a new unit test should be added to activemq-core/src/test/java/org/apache/activemq/transport/stomp/StompTest.java. It should send 2 messages at different priorities, and verifies that they are re-ordered by ActiveMQ. I'll attach a unit test. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (AMQNET-130) WCF provider is catching exceptions thrown by WCF service implementation
[ https://issues.apache.org/jira/browse/AMQNET-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes closed AMQNET-130. WCF provider is catching exceptions thrown by WCF service implementation Key: AMQNET-130 URL: https://issues.apache.org/jira/browse/AMQNET-130 Project: ActiveMQ .Net Issue Type: Bug Components: WCF Affects Versions: 1.1.0 Environment: Windows Server 2003 SP1, ActiveMQ 5.2.0, latest Apache.NMS and Apache.NMS.ActiveMQ Reporter: David Keaveny Assignee: Jim Gomes Fix For: 1.5.0 Original Estimate: 10h Remaining Estimate: 10h Exceptions that occur within WCF service implementations are being caught by the WCF provider and swallowed, so that the service never sees the exception. The exceptions *are* logged to the WCF trace log though, if the system.diagnostics / configuration section is defined. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQNET-130) WCF provider is catching exceptions thrown by WCF service implementation
[ https://issues.apache.org/jira/browse/AMQNET-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Gomes resolved AMQNET-130. -- Resolution: Fixed Fix Version/s: 1.5.0 WCF provider is catching exceptions thrown by WCF service implementation Key: AMQNET-130 URL: https://issues.apache.org/jira/browse/AMQNET-130 Project: ActiveMQ .Net Issue Type: Bug Components: WCF Affects Versions: 1.1.0 Environment: Windows Server 2003 SP1, ActiveMQ 5.2.0, latest Apache.NMS and Apache.NMS.ActiveMQ Reporter: David Keaveny Assignee: Jim Gomes Fix For: 1.5.0 Original Estimate: 10h Remaining Estimate: 10h Exceptions that occur within WCF service implementations are being caught by the WCF provider and swallowed, so that the service never sees the exception. The exceptions *are* logged to the WCF trace log though, if the system.diagnostics / configuration section is defined. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (AMQ-3172) Add support for Message Priority to Stomp
[ https://issues.apache.org/jira/browse/AMQ-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-3172. - Resolution: Not A Problem Working as designed, the message will be in order if both are allow to get to the queue before the consumer receive. Add support for Message Priority to Stomp - Key: AMQ-3172 URL: https://issues.apache.org/jira/browse/AMQ-3172 Project: ActiveMQ Issue Type: Improvement Components: Transport Affects Versions: 5.4.2 Reporter: Craig Lewis Priority: Minor Attachments: StompTest.java.patch Creating a Stomp message with a priority header has no effect. The messages are delivered in FIFO order, not priority order. The Stomp transport (activemq-core/src/main/java/org/apache/activemq/transport/stomp/FrameTranslator.java) is calling msg.setJMSPriority(), but never calls producer.setPriority(). Because of this, messages claims to have a priority, but the messages are never actually re-ordered. I believe a new unit test should be added to activemq-core/src/test/java/org/apache/activemq/transport/stomp/StompTest.java. It should send 2 messages at different priorities, and verifies that they are re-ordered by ActiveMQ. I'll attach a unit test. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQNET-201) WCF binding to support request reply message exchange
[ https://issues.apache.org/jira/browse/AMQNET-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991695#comment-12991695 ] Jim Gomes commented on AMQNET-201: -- I don't see anything inherently wrong with modifying the Apache.NMS.WCF provider to support a request/reply message exchange. The link that was referenced in AMQNET-126 is somewhat dated, and I think newer WCF will easily support request/reply. However, I am not a WCF user, so this is in an area that I can't help much. I've done some searches and there are lots of blogging examples for this. One such blog of interest may be the following: http://davybrion.com/blog/2009/11/requestresponse-service-layer-exposing-the-service-layer-through-wcf/ Hopefully, there's smoeone interested in submitting a patch to support request/reply in the Apache.NMS.WCF provider. WCF binding to support request reply message exchange - Key: AMQNET-201 URL: https://issues.apache.org/jira/browse/AMQNET-201 Project: ActiveMQ .Net Issue Type: Improvement Components: WCF Affects Versions: 1.1.0 Reporter: Mark Pollack Assignee: Jim Gomes Priority: Minor I remember a while back there was some discussion on a JIRA issue where there was an explicit decision not to implement the request reply message exchange pattern in the WCF binding. I think this is not the correct decision. Request/Reply is a natural interaction for messaging systems, though clearly not the default. Implementation options are to use a temporary queue as the return destination or to setup a standard queue but create a message listener with a selector. Just for reference the TIBCO WCF binding supports request reply message exchange. A customer driven motivation behind this is that usually everyone creates request/reply endpoints over http transport in WCF. When they want to switch transports to messaging they discover (in MSMQ case) that they can't and would have to redesign their entire web services design to accomodate using JMS transport. This is simply not needed. Please reconsider and let's discuss more. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-3172) Add support for Message Priority to Stomp
[ https://issues.apache.org/jira/browse/AMQ-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991770#comment-12991770 ] Craig Lewis commented on AMQ-3172: -- Confirmed. Without the sleep, it fails approximately 50% of the time. After adding the sleep, it's passed 10 runs out of 10. Thanks for the help. Add support for Message Priority to Stomp - Key: AMQ-3172 URL: https://issues.apache.org/jira/browse/AMQ-3172 Project: ActiveMQ Issue Type: Improvement Components: Transport Affects Versions: 5.4.2 Reporter: Craig Lewis Priority: Minor Attachments: StompTest.java.patch Creating a Stomp message with a priority header has no effect. The messages are delivered in FIFO order, not priority order. The Stomp transport (activemq-core/src/main/java/org/apache/activemq/transport/stomp/FrameTranslator.java) is calling msg.setJMSPriority(), but never calls producer.setPriority(). Because of this, messages claims to have a priority, but the messages are never actually re-ordered. I believe a new unit test should be added to activemq-core/src/test/java/org/apache/activemq/transport/stomp/StompTest.java. It should send 2 messages at different priorities, and verifies that they are re-ordered by ActiveMQ. I'll attach a unit test. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
