Nabble - ActiveMQ - Dev

Hudson build is still unstable: ActiveMQ #195

2009-11-23T18:24:46Z

See <http://hudson.zones.apache.org/hudson/job/ActiveMQ/195/changes>

Hudson build is still unstable: ActiveMQ » ActiveMQ :: Core #195

2009-11-23T18:24:38Z

See <http://hudson.zones.apache.org/hudson/job/ActiveMQ/org.apache.activemq$activemq-core/195/changes>

[jira] Resolved: (AMQCPP-250) Implement an Inactivity Monotir Transport filter for use on Transport that are used by the Failover Transport

2009-11-23T12:49:58Z

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

Timothy Bish resolved AMQCPP-250.
---------------------------------

Resolution: Fixed

Resolved in SVN Rev. 883495

> Implement an Inactivity Monotir Transport filter for use on Transport that are used by the Failover Transport
> -------------------------------------------------------------------------------------------------------------
>
> Key: AMQCPP-250
> URL: https://issues.apache.org/activemq/browse/AMQCPP-250
> Project: ActiveMQ C++ Client
> Issue Type: Improvement
> Components: Decaf, Transports
> Affects Versions: 3.0
> Reporter: Timothy Bish
> Assignee: Timothy Bish
> Fix For: 3.1
>
> Original Estimate: 4 weeks
> Time Spent: 1 day
> Remaining Estimate: 3 weeks, 5 days
>
> Now that the Failover Transport is in place we need an Inactivity Monitor to wrap around transports such as TCP to detect long periods of inactivity and failures due to TCP connections that are otherwise not detected as broken such as a plug pull or switch failure.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AMQ-2507) When using a producer/session with a send timeout, send() doesn't throw an exception if the timeout is reached.

2009-11-23T12:09:52Z

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

Dave Stanley updated AMQ-2507:
------------------------------

Attachment: producer_timeout_test.txt

Attaching patch with testcase that shows the problem. Cut from trunk.

> When using a producer/session with a send timeout, send() doesn't throw an exception if the timeout is reached.
> ---------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-2507
> URL: https://issues.apache.org/activemq/browse/AMQ-2507
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 5.3.0
> Environment: All platforms, 5.3.x
> Reporter: Dave Stanley
> Attachments: producer_timeout_test.txt
>
>
> In the attached testcase we set a low broker memory limit (to force a producer to block due to the memory usage limit being hit), and also set a sendtimeout on the connection to force the producer.send() to return if it cannot send a message within the timeout period.
> On running the test the broker sends messages until the timeout kicks in. Once the hits the memory limit it blocks and the producer.send() returns after the timeout.
> The problem is there is no way to know that the send() failed. This improvement is to modify the session to throw an exception of some kind when the sendTimeout is reached.
> I have attached the testcase without a fix as its not clear the best approach to fix.
> One possible solution is to modify ActiveMQSession, but need some clarification on whats the best JMSException to throw. It doesn't look like this is explicitly spelled out in the JMS Spec.
> General area is the send() method
> protected void send(ActiveMQMessageProducer producer, ActiveMQDestination destination, Message message, int deliveryMode, int priority, long timeToLive,
> MemoryUsage producerWindow, int sendTimeout) throws JMSException {
> .....
> if (sendTimeout <= 0 && !msg.isResponseRequired() && !connection.isAlwaysSyncSend() && (!msg.isPersistent() || connection.isUseAsyncSend() || txid != null)) {
> this.connection.asyncSendPacket(msg);
> if (producerWindow != null) {
> // Since we defer lots of the marshaling till we hit the
> // wire, this might not
> // provide and accurate size. We may change over to doing
> // more aggressive marshaling,
> // to get more accurate sizes.. this is more important once
> // users start using producer window
> // flow control.
> int size = msg.getSize();
> producerWindow.increaseUsage(size);
> }
> } else {
> // Handle send timeout here
> if (sendTimeout > 0) {
> Object response = this.connection.syncSendPacket(msg,sendTimeout);
> if(response == null) {
> LOG.debug(getSessionId() + " timeout sending message: " + msg);
> }
> // What jms exception is most appropriate to throw here?
> }else {
> this.connection.syncSendPacket(msg);
> }
> }
> }

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AMQ-2507) When using a producer/session with a send timeout, send() doesn't throw an exception if the timeout is reached.

2009-11-23T12:07:52Z

When using a producer/session with a send timeout, send() doesn't throw an exception if the timeout is reached.
---------------------------------------------------------------------------------------------------------------

Key: AMQ-2507
URL: https://issues.apache.org/activemq/browse/AMQ-2507
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Affects Versions: 5.3.0
Environment: All platforms, 5.3.x
Reporter: Dave Stanley

In the attached testcase we set a low broker memory limit (to force a producer to block due to the memory usage limit being hit), and also set a sendtimeout on the connection to force the producer.send() to return if it cannot send a message within the timeout period.

On running the test the broker sends messages until the timeout kicks in. Once the hits the memory limit it blocks and the producer.send() returns after the timeout.

The problem is there is no way to know that the send() failed. This improvement is to modify the session to throw an exception of some kind when the sendTimeout is reached.

I have attached the testcase without a fix as its not clear the best approach to fix.

One possible solution is to modify ActiveMQSession, but need some clarification on whats the best JMSException to throw. It doesn't look like this is explicitly spelled out in the JMS Spec.

General area is the send() method

protected void send(ActiveMQMessageProducer producer, ActiveMQDestination destination, Message message, int deliveryMode, int priority, long timeToLive,
MemoryUsage producerWindow, int sendTimeout) throws JMSException {
.....

if (sendTimeout <= 0 && !msg.isResponseRequired() && !connection.isAlwaysSyncSend() && (!msg.isPersistent() || connection.isUseAsyncSend() || txid != null)) {
this.connection.asyncSendPacket(msg);
if (producerWindow != null) {
// Since we defer lots of the marshaling till we hit the
// wire, this might not
// provide and accurate size. We may change over to doing
// more aggressive marshaling,
// to get more accurate sizes.. this is more important once
// users start using producer window
// flow control.
int size = msg.getSize();
producerWindow.increaseUsage(size);
}
} else {
// Handle send timeout here
if (sendTimeout > 0) {
Object response = this.connection.syncSendPacket(msg,sendTimeout);
if(response == null) {
LOG.debug(getSessionId() + " timeout sending message: " + msg);
}

// What jms exception is most appropriate to throw here?
}else {
this.connection.syncSendPacket(msg);
}
}
}

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AMQCPP-270) Broker exception on message Ack,

2009-11-23T11:35:52Z

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

Timothy Bish resolved AMQCPP-270.
---------------------------------

Resolution: Fixed

Fixed in trunk.

> Broker exception on message Ack,
> ---------------------------------
>
> Key: AMQCPP-270
> URL: https://issues.apache.org/activemq/browse/AMQCPP-270
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Affects Versions: 3.0.1
> Reporter: Timothy Bish
> Assignee: Timothy Bish
> Fix For: 3.1
>
>
> Certain cases that involved acknowledging a message from the async callback of a MessageListener when in Client or Individual Ack modes can result in this error from the broker: "Could not correlate acknowledgment with dispatched message"
> This is the same situation as documented in AMQ-2489

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AMQCPP-270) Broker exception on message Ack,

2009-11-23T11:33:52Z

Broker exception on message Ack,
---------------------------------

Key: AMQCPP-270
URL: https://issues.apache.org/activemq/browse/AMQCPP-270
Project: ActiveMQ C++ Client
Issue Type: Bug
Affects Versions: 3.0.1
Reporter: Timothy Bish
Assignee: Timothy Bish
Fix For: 3.1

Certain cases that involved acknowledging a message from the async callback of a MessageListener when in Client or Individual Ack modes can result in this error from the broker: "Could not correlate acknowledgment with dispatched message"

This is the same situation as documented in AMQ-2489

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r883411 - /activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java

2009-11-23T11:08:02Z

On Mon, Nov 23, 2009 at 11:49 AM, Gary Tully <gary.tully@...> wrote:
> committed a fix for the protected access compile error, but the test fails
> for me.

Whoops, sorry about that. I forgot to ask about the change to the
modifier on the ManagementContext.getMBeanServer() method. Thanks for
changing the use of that.

Could you provide the failure stack trace please?

Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder

[jira] Commented: (AMQ-2506) Incorrect activemq-policy.xml in activemq-core tests used and referenced in http://activemq.apache.org/dispatch-policies.html.

2009-11-23T11:07:52Z

[ https://issues.apache.org/activemq/browse/AMQ-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56028#action_56028 ]

Gary Tully commented on AMQ-2506:
---------------------------------

Is this really wrong? Check out the test case that validates the config setting. org.apache.activemq.xbean.XBeanConfigTest
It fails with the patch. There may be cases where topic dispatch order is important. Advisories in a network scenario for example can be more deterministic. Am not sure if this is really a bug in the doc.
If it really is then the corresponding test needs to change but it looks ok to me.

> Incorrect activemq-policy.xml in activemq-core tests used and referenced in http://activemq.apache.org/dispatch-policies.html.
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-2506
> URL: https://issues.apache.org/activemq/browse/AMQ-2506
> Project: ActiveMQ
> Issue Type: Bug
> Components: Documentation, Test Cases
> Affects Versions: 5.3.0
> Reporter: Torsten Mielke
> Priority: Minor
> Attachments: AMQ-2506.patch
>
> Original Estimate: 20 minutes
> Remaining Estimate: 20 minutes
>
> http://activemq.apache.org/dispatch-policies.html explains the use of dispatch policies and gives an example which is a code snippet taken from activemq/trunk/activemq-core/src/test/resources/org/apache/activemq/xbean/activemq-policy.xml.
> That example is incorrect as it configures a round robin dispatch policy for topics but such policy only really makes sense for queues.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r883411 - /activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java

2009-11-23T10:49:53Z

committed a fix for the protected access compile error, but the test fails
for me.

2009/11/23 Gary Tully <gary.tully@...>

> this breaks the build, getMBeanServer() is intentionally protected in
> ManagementContext.
>
> >
> activemq_t/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java:[364,33]
> getMBeanServer() has protected access in
> org.apache.activemq.broker.jmx.ManagementContext
>
> 2009/11/23 <bsnyder@...>
>
> Author: bsnyder
>> Date: Mon Nov 23 17:02:39 2009
>> New Revision: 883411
>>
>> URL: http://svn.apache.org/viewvc?rev=883411&view=rev
>> Log:
>> Updated test for AMQ-2324 and AMQ-2484
>>
>> Modified:
>>
>> activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java
>>
>> Modified:
>> activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java
>> URL:
>> http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java?rev=883411&r1=883410&r2=883411&view=diff
>>
>> ==============================================================================
>> ---
>> activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java
>> (original)
>> +++
>> activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java
>> Mon Nov 23 17:02:39 2009
>> @@ -2,35 +2,102 @@
>>
>> import java.io.File;
>> import java.io.IOException;
>> +import java.net.URI;
>> +import java.net.URISyntaxException;
>> +import java.util.ArrayList;
>> +import java.util.Enumeration;
>> +import java.util.HashMap;
>> +import java.util.Hashtable;
>> +import java.util.List;
>> +import java.util.Map;
>> +import java.util.concurrent.TimeUnit;
>>
>> +import javax.jms.Connection;
>> import javax.jms.DeliveryMode;
>> -
>> -import junit.framework.Test;
>> -
>> +import javax.jms.MessageNotWriteableException;
>> +import javax.jms.Queue;
>> +import javax.jms.QueueBrowser;
>> +import javax.jms.Session;
>> +import javax.management.MBeanServer;
>> +import javax.management.ObjectName;
>> +
>> +import junit.framework.TestCase;
>> +
>> +import org.apache.activemq.ActiveMQConnectionFactory;
>> +import org.apache.activemq.broker.BrokerService;
>> +import org.apache.activemq.broker.BrokerTestSupport;
>> import org.apache.activemq.broker.StubConnection;
>> +import org.apache.activemq.broker.TransportConnector;
>> +import org.apache.activemq.broker.jmx.ManagementContext;
>> import org.apache.activemq.command.ActiveMQDestination;
>> -import org.apache.activemq.command.Command;
>> +import org.apache.activemq.command.ActiveMQTextMessage;
>> +import org.apache.activemq.command.ConnectionId;
>> import org.apache.activemq.command.ConnectionInfo;
>> import org.apache.activemq.command.ConsumerInfo;
>> +import org.apache.activemq.command.DestinationInfo;
>> import org.apache.activemq.command.Message;
>> import org.apache.activemq.command.MessageAck;
>> +import org.apache.activemq.command.MessageDispatch;
>> +import org.apache.activemq.command.MessageId;
>> import org.apache.activemq.command.ProducerInfo;
>> import org.apache.activemq.command.SessionInfo;
>> import org.apache.activemq.transport.Transport;
>> -import org.apache.activemq.transport.TransportListener;
>> +import org.apache.activemq.transport.TransportFactory;
>> import org.apache.activemq.util.Wait;
>> import org.apache.commons.io.FileUtils;
>> import org.apache.commons.logging.Log;
>> import org.apache.commons.logging.LogFactory;
>>
>> -public class BrokerNetworkWithStuckMessagesTest extends
>> NetworkTestSupport {
>> -
>> +/**
>> + * This class duplicates most of the functionality in {@link
>> NetworkTestSupport}
>> + * and {@link BrokerTestSupport} because more control was needed over how
>> brokers
>> + * and connectors are created. Also, this test asserts message counts via
>> JMX on
>> + * each broker.
>> + *
>> + * @author bsnyder
>> + *
>> + */
>> +public class BrokerNetworkWithStuckMessagesTest extends TestCase
>> /*NetworkTestSupport*/ {
>> +
>> private static final Log LOG =
>> LogFactory.getLog(BrokerNetworkWithStuckMessagesTest.class);
>> -
>> - private DemandForwardingBridge bridge;
>> -
>> - protected void setUp() throws Exception {
>> - super.setUp();
>> +
>> + private BrokerService localBroker;
>> + private BrokerService remoteBroker;
>> + private DemandForwardingBridge bridge;
>> +
>> + protected Map<String, BrokerService> brokers = new HashMap<String,
>> BrokerService>();
>> + protected ArrayList connections = new ArrayList();
>> +
>> + protected TransportConnector connector;
>> + protected TransportConnector remoteConnector;
>> +
>> + protected long idGenerator;
>> + protected int msgIdGenerator;
>> + protected int tempDestGenerator;
>> + protected int maxWait = 4000;
>> + protected String queueName = "TEST";
>> +
>> + protected String amqDomain = "org.apache.activemq";
>> +
>> + protected void setUp() throws Exception {
>> +
>> + // For those who want visual confirmation:
>> + // Uncomment the following to enable JMX support on a port
>> number to use
>> + // Jconsole to view each broker. You will need to add some
>> calls to
>> + // Thread.sleep() to be able to actually slow things down so
>> that you
>> + // can manually see JMX attrs.
>> +// System.setProperty("com.sun.management.jmxremote", "");
>> +// System.setProperty("com.sun.management.jmxremote.port",
>> "1099");
>> +// System.setProperty("com.sun.management.jmxremote.authenticate",
>> "false");
>> +// System.setProperty("com.sun.management.jmxremote.ssl",
>> "false");
>> +
>> + // Create the local broker
>> + createBroker();
>> + // Create the remote broker
>> + createRemoteBroker();
>> +
>> + // Remove the activemq-data directory from the creation of the
>> remote broker
>> + FileUtils.deleteDirectory(new File("activemq-data"));
>>
>> // Create a network bridge between the local and remote brokers so
>> that
>> // demand-based forwarding can take place
>> @@ -39,79 +106,42 @@
>> config.setDispatchAsync(false);
>>
>> Transport localTransport = createTransport();
>> - localTransport.setTransportListener(new TransportListener() {
>> - Command command = null;
>> - public void onCommand(Object o) {
>> - this.command = (Command) o;
>> - LOG.info("Command from [" +
>> command.getFrom() + "] to [" + command.getTo() + "]");
>> - }
>> -
>> - public void onException(IOException error) {
>> - LOG.info("Command from [" +
>> command.getFrom() + "] to [" + command.getTo() + "]");
>> - LOG.info("Exception: " + error);
>> - }
>> -
>> - public void transportInterupted() {
>> - LOG.info("Interruption on local
>> transport");
>> - }
>> -
>> - public void transportResumed() {
>> - LOG.info("Resumption on local transport");
>> - }
>> - });
>> -
>> Transport remoteTransport = createRemoteTransport();
>> - remoteTransport.setTransportListener(new TransportListener() {
>> - Command command = null;
>> - public void onCommand(Object o) {
>> - this.command = (Command) o;
>> - LOG.info("Command from [" +
>> command.getFrom() + "] to [" + command.getTo() + "]");
>> - }
>> -
>> - public void onException(IOException error) {
>> - LOG.info("Command from [" +
>> command.getFrom() + "] to [" + command.getTo() + "]");
>> - LOG.info("Exception: " + error);
>> - }
>> -
>> - public void transportInterupted() {
>> - LOG.info("Interruption on remote
>> transport");
>> - }
>> -
>> - public void transportResumed() {
>> - LOG.info("Resumption on remote
>> transport");
>> - }
>> - });
>>
>> + // Create a network bridge between the two brokers
>> bridge = new DemandForwardingBridge(config, localTransport,
>> remoteTransport);
>> - bridge.setBrokerService(broker);
>> + bridge.setBrokerService(localBroker);
>> bridge.start();
>>
>> - // Enable JMX support on the local and remote brokers
>> -// broker.setUseJmx(true);
>> -// remoteBroker.setUseJmx(true);
>> -
>> - // Make sure persistence is disabled
>> - broker.setPersistent(false);
>> - broker.setPersistenceAdapter(null);
>> - remoteBroker.setPersistent(false);
>> - remoteBroker.setPersistenceAdapter(null);
>> + waitForBridgeFormation();
>>
>> - // Remove the activemq-data directory from the creation of the
>> remote broker
>> - FileUtils.deleteDirectory(new File("activemq-data"));
>> }
>> -
>> - protected void tearDown() throws Exception {
>> +
>> + protected void waitForBridgeFormation() throws Exception {
>> + for (final BrokerService broker : brokers.values()) {
>> + if (!broker.getNetworkConnectors().isEmpty()) {
>> + // Max wait here is 30 secs
>> + Wait.waitFor(new Wait.Condition() {
>> + public boolean isSatisified() throws Exception {
>> + return
>> !broker.getNetworkConnectors().get(0).activeBridges().isEmpty();
>> + }});
>> + }
>> + }
>> + }
>> +
>> + protected void tearDown() throws Exception {
>> bridge.stop();
>> - super.tearDown();
>> + localBroker.stop();
>> + remoteBroker.stop();
>> }
>>
>> - public void testBrokerNetworkWithStuckMessages() throws Exception
>> {
>> -
>> - int sendNumMessages = 10;
>> - int receiveNumMessages = 5;
>> -
>> - // Create a producer and send a batch of 10 messages to
>> the local broker
>> - StubConnection connection1 = createConnection();
>> + public void testBrokerNetworkWithStuckMessages() throws Exception {
>> +
>> + int sendNumMessages = 10;
>> + int receiveNumMessages = 5;
>> +
>> + // Create a producer
>> + StubConnection connection1 = createConnection();
>> ConnectionInfo connectionInfo1 = createConnectionInfo();
>> SessionInfo sessionInfo1 = createSessionInfo(connectionInfo1);
>> ProducerInfo producerInfo = createProducerInfo(sessionInfo1);
>> @@ -122,25 +152,25 @@
>> // Create a destination on the local broker
>> ActiveMQDestination destinationInfo1 = null;
>>
>> + // Send a 10 messages to the local broker
>> for (int i = 0; i < sendNumMessages; ++i) {
>> - destinationInfo1 = createDestinationInfo(connection1,
>> connectionInfo1, ActiveMQDestination.QUEUE_TYPE);
>> -// connection1.send(createMessage(producerInfo,
>> destinationInfo1, DeliveryMode.NON_PERSISTENT));
>> - connection1.request(createMessage(producerInfo,
>> destinationInfo1, DeliveryMode.NON_PERSISTENT));
>> + destinationInfo1 = createDestinationInfo(connection1,
>> connectionInfo1, ActiveMQDestination.QUEUE_TYPE);
>> + connection1.request(createMessage(producerInfo,
>> destinationInfo1, DeliveryMode.NON_PERSISTENT));
>> }
>>
>> // Ensure that there are 10 messages on the local broker
>> - int messageCount1 = countMessagesInQueue(connection1,
>> connectionInfo1, destinationInfo1);
>> - assertEquals(10, messageCount1);
>> + Object[] messages = browseQueueWithJmx(localBroker);
>> + assertEquals(sendNumMessages, messages.length);
>>
>>
>> - // Create a consumer on the remote broker
>> + // Create a synchronous consumer on the remote broker
>> final StubConnection connection2 = createRemoteConnection();
>> ConnectionInfo connectionInfo2 = createConnectionInfo();
>> SessionInfo sessionInfo2 = createSessionInfo(connectionInfo2);
>> connection2.send(connectionInfo2);
>> connection2.send(sessionInfo2);
>> ActiveMQDestination destinationInfo2 =
>> - createDestinationInfo(connection2, connectionInfo2,
>> ActiveMQDestination.QUEUE_TYPE);
>> + createDestinationInfo(connection2, connectionInfo2,
>> ActiveMQDestination.QUEUE_TYPE);
>> final ConsumerInfo consumerInfo2 =
>> createConsumerInfo(sessionInfo2, destinationInfo2);
>> connection2.send(consumerInfo2);
>>
>> @@ -149,32 +179,27 @@
>> // method, this will cause the messages on the local broker to be
>> // forwarded to the remote broker.
>> for (int i = 0; i < receiveNumMessages; ++i) {
>> - assertTrue("Message " + i + " was not received",
>> Wait.waitFor(new Wait.Condition() {
>> - public boolean isSatisified() throws Exception {
>> - Message message1 =
>> receiveMessage(connection2);
>> - assertNotNull(message1);
>> - connection2.send(createAck(consumerInfo2,
>> message1, 1, MessageAck.STANDARD_ACK_TYPE));
>> - return message1 != null;
>> - }
>> - }));
>> -// Message message1 = receiveMessage(connection2);
>> -// assertNotNull(message1);
>> -// connection2.send(createAck(consumerInfo2, message1, 1,
>> MessageAck.STANDARD_ACK_TYPE));
>> + Message message1 = receiveMessage(connection2);
>> + assertNotNull(message1);
>> + connection2.send(createAck(consumerInfo2, message1, 1,
>> MessageAck.STANDARD_ACK_TYPE));
>> +
>> + Object[] msgs1 = browseQueueWithJmx(remoteBroker);
>> + LOG.info("Found [" + msgs1.length + "] messages with JMX");
>> +// assertEquals((sendNumMessages-i), msgs.length);
>> }
>>
>> - // Close the consumer on the remote broker
>> - connection2.send(consumerInfo2.createRemoveCommand());
>> -
>> // Ensure that there are zero messages on the local broker. This
>> tells
>> // us that those messages have been prefetched to the remote
>> broker
>> // where the demand exists.
>> - int messageCount2 = countMessagesInQueue(connection1,
>> connectionInfo1, destinationInfo1);
>> -// Sometimes it fails here
>> - assertEquals(0, messageCount2);
>> + messages = browseQueueWithJmx(localBroker);
>> + assertEquals(0, messages.length);
>> +
>> + // Close the consumer on the remote broker
>> + connection2.send(consumerInfo2.createRemoveCommand());
>>
>> // There should now be 5 messages stuck on the remote broker
>> - int messageCount3 = countMessagesInQueue(connection2,
>> connectionInfo2, destinationInfo2);
>> - assertEquals(5, messageCount3);
>> + messages = browseQueueWithJmx(remoteBroker);
>> + assertEquals(5, messages.length);
>>
>> // Create a consumer on the local broker just to confirm that it
>> doesn't
>> // receive any messages
>> @@ -182,13 +207,13 @@
>> connection1.send(consumerInfo1);
>> Message message1 = receiveMessage(connection1);
>>
>> - //////////////////////////////////////////////////////
>> + //////////////////////////////////////////////////////
>> // An assertNull() is done here because this is currently the
>> correct
>> // behavior. This is actually the purpose of this test - to prove
>> that
>> // messages are stuck on the remote broker. AMQ-2324 and AMQ-2484
>> aim
>> // to fix this situation so that messages don't get stuck.
>> assertNull(message1);
>> - //////////////////////////////////////////////////////
>> + //////////////////////////////////////////////////////
>>
>> ConsumerInfo consumerInfo3 = createConsumerInfo(sessionInfo2,
>> destinationInfo2);
>> connection2.send(consumerInfo3);
>> @@ -197,30 +222,247 @@
>> // to clean up the queue.
>> int counter = 0;
>> for (int i = 0; i < receiveNumMessages; ++i) {
>> - message1 = receiveMessage(connection2);
>> - assertNotNull(message1);
>> + message1 = receiveMessage(connection2);
>> + assertNotNull(message1);
>> connection2.send(createAck(consumerInfo3, message1, 1,
>> MessageAck.STANDARD_ACK_TYPE));
>> ++counter;
>> }
>> // Ensure that 5 messages were received
>> assertEquals(receiveNumMessages, counter);
>>
>> - Thread.sleep(2000);
>> + // Let those acks percolate... This stinks but it's the only way
>> currently
>> + // because these types of internal broker actions are
>> non-deterministic.
>> + Thread.sleep(4000);
>>
>> // Ensure that the queue on the remote broker is empty
>> - int messageCount4 = countMessagesInQueue(connection2,
>> connectionInfo2, destinationInfo1);
>> -// Sometimes it fails here
>> - assertEquals(0, messageCount4);
>> + messages = browseQueueWithJmx(remoteBroker);
>> + assertEquals(0, messages.length);
>>
>> // Close the consumer on the remote broker
>> connection2.send(consumerInfo3.createRemoveCommand());
>>
>> connection1.stop();
>> connection2.stop();
>> + }
>> +
>> + protected BrokerService createBroker() throws Exception {
>> + localBroker = new BrokerService();
>> + localBroker.setBrokerName("localhost");
>> + localBroker.setUseJmx(true);
>> + localBroker.setPersistenceAdapter(null);
>> + localBroker.setPersistent(false);
>> + connector = createConnector();
>> + localBroker.addConnector(connector);
>> + localBroker.start();
>> + localBroker.waitUntilStarted();
>> +
>> + localBroker.getManagementContext().setConnectorPort(2221);
>> +
>> + brokers.put(localBroker.getBrokerName(), localBroker);
>> +
>> + return localBroker;
>> + }
>> +
>> + protected BrokerService createRemoteBroker() throws Exception {
>> + remoteBroker = new BrokerService();
>> + remoteBroker.setBrokerName("remotehost");
>> + remoteBroker.setUseJmx(true);
>> + remoteBroker.setPersistenceAdapter(null);
>> + remoteBroker.setPersistent(false);
>> + remoteConnector = createRemoteConnector();
>> + remoteBroker.addConnector(remoteConnector);
>> + remoteBroker.waitUntilStarted();
>> +
>> + remoteBroker.getManagementContext().setConnectorPort(2222);
>> +
>> + brokers.put(remoteBroker.getBrokerName(), remoteBroker);
>> +
>> + return remoteBroker;
>> + }
>> +
>> + protected Transport createTransport() throws Exception {
>> + Transport transport =
>> TransportFactory.connect(connector.getServer().getConnectURI());
>> + return transport;
>> + }
>> +
>> + protected Transport createRemoteTransport() throws Exception {
>> + Transport transport =
>> TransportFactory.connect(remoteConnector.getServer().getConnectURI());
>> + return transport;
>> + }
>> +
>> + protected TransportConnector createConnector() throws Exception,
>> IOException, URISyntaxException {
>> + return new TransportConnector(TransportFactory.bind(new
>> URI(getLocalURI())));
>> + }
>> +
>> + protected TransportConnector createRemoteConnector() throws
>> Exception, IOException, URISyntaxException {
>> + return new TransportConnector(TransportFactory.bind(new
>> URI(getRemoteURI())));
>> + }
>> +
>> + protected String getRemoteURI() {
>> + return "vm://remotehost";
>> + }
>> +
>> + protected String getLocalURI() {
>> + return "vm://localhost";
>> + }
>> +
>> + protected StubConnection createConnection() throws Exception {
>> + Transport transport =
>> TransportFactory.connect(connector.getServer().getConnectURI());
>> + StubConnection connection = new StubConnection(transport);
>> + connections.add(connection);
>> + return connection;
>> + }
>> +
>> + protected StubConnection createRemoteConnection() throws Exception {
>> + Transport transport =
>> TransportFactory.connect(remoteConnector.getServer().getConnectURI());
>> + StubConnection connection = new StubConnection(transport);
>> + connections.add(connection);
>> + return connection;
>> + }
>> +
>> + @SuppressWarnings("unchecked")
>> + private Object[] browseQueueWithJms(BrokerService broker) throws
>> Exception {
>> + Object[] messages = null;
>> + Connection connection = null;
>> + Session session = null;
>> +
>> + try {
>> + URI brokerUri = connector.getUri();
>> + ActiveMQConnectionFactory connectionFactory = new
>> ActiveMQConnectionFactory(brokerUri.toString());
>> + connection = connectionFactory.createConnection();
>> + connection.start();
>> + session = connection.createSession(false,
>> Session.AUTO_ACKNOWLEDGE);
>> + Queue destination =
>> session.createQueue(queueName);
>> + QueueBrowser browser =
>> session.createBrowser(destination);
>> + List<Message> list = new ArrayList<Message>();
>> + for (Enumeration<Message> enumn =
>> browser.getEnumeration(); enumn.hasMoreElements();) {
>> + list.add(enumn.nextElement());
>> + }
>> + messages = list.toArray();
>> + }
>> + finally {
>> + if (session != null) {
>> + session.close();
>> + }
>> + if (connection != null) {
>> + connection.close();
>> + }
>> + }
>> + LOG.info("+Browsed with JMS: " + messages.length);
>> +
>> + return messages;
>> }
>> -
>> - public static Test suite() {
>> - return suite(BrokerNetworkWithStuckMessagesTest.class);
>> +
>> + private Object[] browseQueueWithJmx(BrokerService broker) throws
>> Exception {
>> + Hashtable<String, String> params = new Hashtable<String,
>> String>();
>> + params.put("BrokerName", broker.getBrokerName());
>> + params.put("Type", "Queue");
>> + params.put("Destination", queueName);
>> + ObjectName queueObjectName = ObjectName.getInstance(amqDomain,
>> params);
>> +
>> + ManagementContext mgmtCtx = broker.getManagementContext();
>> + MBeanServer mbs = mgmtCtx.getMBeanServer();
>> + Object[] messages = (Object[]) mbs.invoke(queueObjectName,
>> "browse", new Object[0], new String[0]);
>> +
>> + LOG.info("+Browsed with JMX: " + messages.length);
>> +
>> + return messages;
>> + }
>> +
>> + protected ConnectionInfo createConnectionInfo() throws Exception {
>> + ConnectionInfo info = new ConnectionInfo();
>> + info.setConnectionId(new ConnectionId("connection:" +
>> (++idGenerator)));
>> + info.setClientId(info.getConnectionId().getValue());
>> + return info;
>> + }
>> +
>> + protected SessionInfo createSessionInfo(ConnectionInfo
>> connectionInfo) throws Exception {
>> + SessionInfo info = new SessionInfo(connectionInfo,
>> ++idGenerator);
>> + return info;
>> + }
>> +
>> + protected ProducerInfo createProducerInfo(SessionInfo sessionInfo)
>> throws Exception {
>> + ProducerInfo info = new ProducerInfo(sessionInfo, ++idGenerator);
>> + return info;
>> + }
>> +
>> + protected ConsumerInfo createConsumerInfo(SessionInfo sessionInfo,
>> ActiveMQDestination destination) throws Exception {
>> + ConsumerInfo info = new ConsumerInfo(sessionInfo, ++idGenerator);
>> + info.setBrowser(false);
>> + info.setDestination(destination);
>> + info.setPrefetchSize(1000);
>> + info.setDispatchAsync(false);
>> + return info;
>> + }
>> +
>> + protected DestinationInfo createTempDestinationInfo(ConnectionInfo
>> connectionInfo, byte destinationType) {
>> + DestinationInfo info = new DestinationInfo();
>> + info.setConnectionId(connectionInfo.getConnectionId());
>> + info.setOperationType(DestinationInfo.ADD_OPERATION_TYPE);
>> +
>> info.setDestination(ActiveMQDestination.createDestination(info.getConnectionId()
>> + ":" + (++tempDestGenerator), destinationType));
>> + return info;
>> + }
>> +
>> + protected ActiveMQDestination createDestinationInfo(StubConnection
>> connection, ConnectionInfo connectionInfo1, byte destinationType) throws
>> Exception {
>> + if ((destinationType & ActiveMQDestination.TEMP_MASK) != 0) {
>> + DestinationInfo info =
>> createTempDestinationInfo(connectionInfo1, destinationType);
>> + connection.send(info);
>> + return info.getDestination();
>> + } else {
>> + return ActiveMQDestination.createDestination(queueName,
>> destinationType);
>> + }
>> + }
>> +
>> + protected Message createMessage(ProducerInfo producerInfo,
>> ActiveMQDestination destination, int deliveryMode) {
>> + Message message = createMessage(producerInfo, destination);
>> + message.setPersistent(deliveryMode == DeliveryMode.PERSISTENT);
>> + return message;
>> + }
>> +
>> + protected Message createMessage(ProducerInfo producerInfo,
>> ActiveMQDestination destination) {
>> + ActiveMQTextMessage message = new ActiveMQTextMessage();
>> + message.setMessageId(new MessageId(producerInfo,
>> ++msgIdGenerator));
>> + message.setDestination(destination);
>> + message.setPersistent(false);
>> + try {
>> + message.setText("Test Message Payload.");
>> + } catch (MessageNotWriteableException e) {
>> + }
>> + return message;
>> + }
>> +
>> + protected MessageAck createAck(ConsumerInfo consumerInfo, Message
>> msg, int count, byte ackType) {
>> + MessageAck ack = new MessageAck();
>> + ack.setAckType(ackType);
>> + ack.setConsumerId(consumerInfo.getConsumerId());
>> + ack.setDestination(msg.getDestination());
>> + ack.setLastMessageId(msg.getMessageId());
>> + ack.setMessageCount(count);
>> + return ack;
>> + }
>> +
>> + public Message receiveMessage(StubConnection connection) throws
>> InterruptedException {
>> + return receiveMessage(connection, maxWait);
>> + }
>> +
>> + public Message receiveMessage(StubConnection connection, long
>> timeout) throws InterruptedException {
>> + while (true) {
>> + Object o = connection.getDispatchQueue().poll(timeout,
>> TimeUnit.MILLISECONDS);
>> +
>> + if (o == null) {
>> + return null;
>> + }
>> + if (o instanceof MessageDispatch) {
>> +
>> + MessageDispatch dispatch = (MessageDispatch)o;
>> + if (dispatch.getMessage() == null) {
>> + return null;
>> + }
>> + dispatch.setMessage(dispatch.getMessage().copy());
>> +
>> dispatch.getMessage().setRedeliveryCounter(dispatch.getRedeliveryCounter());
>> + return dispatch.getMessage();
>> + }
>> + }
>> }
>>
>> }
>>
>>
>>
>
>
> --
> http://blog.garytully.com
>
> Open Source Integration
> http://fusesource.com
>

--
http://blog.garytully.com

Open Source Integration
http://fusesource.com

[jira] Resolved: (AMQ-2489) "Could not correlate acknowledgment with dispatched message" exception

2009-11-23T10:45:54Z

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

Gary Tully resolved AMQ-2489.
-----------------------------

Resolution: Fixed
Fix Version/s: 5.4.0

resolved in r883458 - delivery acks are only needed for unacked messages to update prefetch and expiry. When message is acked, they should be suppressed as they now are as they will result in this exception due to not found in the dispatch list.

> "Could not correlate acknowledgment with dispatched message" exception
> ----------------------------------------------------------------------
>
> Key: AMQ-2489
> URL: https://issues.apache.org/activemq/browse/AMQ-2489
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.1.0, 5.3.0, 5.4.0
> Reporter: Dariusz Szablinski
> Assignee: Gary Tully
> Fix For: 5.3.1, 5.4.0
>
> Attachments: JmsUnorderedAsynchAckTest.java
>
>
> This exception is thrown on broker side when two or more ASYNCH consumers acknowledges messages in not in order they received the messages.
> See more on users list: http://old.nabble.com/%22Could-not-correlate-acknowledgment-with-dispatched-message%22-td26308220.html
> Simple unit test attached.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r883411 - /activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java

2009-11-23T10:21:24Z

this breaks the build, getMBeanServer() is intentionally protected in
ManagementContext.

>
activemq_t/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java:[364,33]
getMBeanServer() has protected access in
org.apache.activemq.broker.jmx.ManagementContext

2009/11/23 <bsnyder@...>

> Author: bsnyder
> Date: Mon Nov 23 17:02:39 2009
> New Revision: 883411
>
> URL: http://svn.apache.org/viewvc?rev=883411&view=rev
> Log:
> Updated test for AMQ-2324 and AMQ-2484
>
> Modified:
>
> activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java
>
> Modified:
> activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java
> URL:
> http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java?rev=883411&r1=883410&r2=883411&view=diff
>
> ==============================================================================
> ---
> activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java
> (original)
> +++
> activemq/trunk/activemq-core/src/test/java/org/apache/activemq/network/BrokerNetworkWithStuckMessagesTest.java
> Mon Nov 23 17:02:39 2009
> @@ -2,35 +2,102 @@
>
> import java.io.File;
> import java.io.IOException;
> +import java.net.URI;
> +import java.net.URISyntaxException;
> +import java.util.ArrayList;
> +import java.util.Enumeration;
> +import java.util.HashMap;
> +import java.util.Hashtable;
> +import java.util.List;
> +import java.util.Map;
> +import java.util.concurrent.TimeUnit;
>
> +import javax.jms.Connection;
> import javax.jms.DeliveryMode;
> -
> -import junit.framework.Test;
> -
> +import javax.jms.MessageNotWriteableException;
> +import javax.jms.Queue;
> +import javax.jms.QueueBrowser;
> +import javax.jms.Session;
> +import javax.management.MBeanServer;
> +import javax.management.ObjectName;
> +
> +import junit.framework.TestCase;
> +
> +import org.apache.activemq.ActiveMQConnectionFactory;
> +import org.apache.activemq.broker.BrokerService;
> +import org.apache.activemq.broker.BrokerTestSupport;
> import org.apache.activemq.broker.StubConnection;
> +import org.apache.activemq.broker.TransportConnector;
> +import org.apache.activemq.broker.jmx.ManagementContext;
> import org.apache.activemq.command.ActiveMQDestination;
> -import org.apache.activemq.command.Command;
> +import org.apache.activemq.command.ActiveMQTextMessage;
> +import org.apache.activemq.command.ConnectionId;
> import org.apache.activemq.command.ConnectionInfo;
> import org.apache.activemq.command.ConsumerInfo;
> +import org.apache.activemq.command.DestinationInfo;
> import org.apache.activemq.command.Message;
> import org.apache.activemq.command.MessageAck;
> +import org.apache.activemq.command.MessageDispatch;
> +import org.apache.activemq.command.MessageId;
> import org.apache.activemq.command.ProducerInfo;
> import org.apache.activemq.command.SessionInfo;
> import org.apache.activemq.transport.Transport;
> -import org.apache.activemq.transport.TransportListener;
> +import org.apache.activemq.transport.TransportFactory;
> import org.apache.activemq.util.Wait;
> import org.apache.commons.io.FileUtils;
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
>
> -public class BrokerNetworkWithStuckMessagesTest extends NetworkTestSupport
> {
> -
> +/**
> + * This class duplicates most of the functionality in {@link
> NetworkTestSupport}
> + * and {@link BrokerTestSupport} because more control was needed over how
> brokers
> + * and connectors are created. Also, this test asserts message counts via
> JMX on
> + * each broker.
> + *
> + * @author bsnyder
> + *
> + */
> +public class BrokerNetworkWithStuckMessagesTest extends TestCase
> /*NetworkTestSupport*/ {
> +
> private static final Log LOG =
> LogFactory.getLog(BrokerNetworkWithStuckMessagesTest.class);
> -
> - private DemandForwardingBridge bridge;
> -
> - protected void setUp() throws Exception {
> - super.setUp();
> +
> + private BrokerService localBroker;
> + private BrokerService remoteBroker;
> + private DemandForwardingBridge bridge;
> +
> + protected Map<String, BrokerService> brokers = new HashMap<String,
> BrokerService>();
> + protected ArrayList connections = new ArrayList();
> +
> + protected TransportConnector connector;
> + protected TransportConnector remoteConnector;
> +
> + protected long idGenerator;
> + protected int msgIdGenerator;
> + protected int tempDestGenerator;
> + protected int maxWait = 4000;
> + protected String queueName = "TEST";
> +
> + protected String amqDomain = "org.apache.activemq";
> +
> + protected void setUp() throws Exception {
> +
> + // For those who want visual confirmation:
> + // Uncomment the following to enable JMX support on a port
> number to use
> + // Jconsole to view each broker. You will need to add some calls
> to
> + // Thread.sleep() to be able to actually slow things down so
> that you
> + // can manually see JMX attrs.
> +// System.setProperty("com.sun.management.jmxremote", "");
> +// System.setProperty("com.sun.management.jmxremote.port", "1099");
> +// System.setProperty("com.sun.management.jmxremote.authenticate",
> "false");
> +// System.setProperty("com.sun.management.jmxremote.ssl", "false");
> +
> + // Create the local broker
> + createBroker();
> + // Create the remote broker
> + createRemoteBroker();
> +
> + // Remove the activemq-data directory from the creation of the
> remote broker
> + FileUtils.deleteDirectory(new File("activemq-data"));
>
> // Create a network bridge between the local and remote brokers so
> that
> // demand-based forwarding can take place
> @@ -39,79 +106,42 @@
> config.setDispatchAsync(false);
>
> Transport localTransport = createTransport();
> - localTransport.setTransportListener(new TransportListener() {
> - Command command = null;
> - public void onCommand(Object o) {
> - this.command = (Command) o;
> - LOG.info("Command from [" +
> command.getFrom() + "] to [" + command.getTo() + "]");
> - }
> -
> - public void onException(IOException error) {
> - LOG.info("Command from [" +
> command.getFrom() + "] to [" + command.getTo() + "]");
> - LOG.info("Exception: " + error);
> - }
> -
> - public void transportInterupted() {
> - LOG.info("Interruption on local
> transport");
> - }
> -
> - public void transportResumed() {
> - LOG.info("Resumption on local transport");
> - }
> - });
> -
> Transport remoteTransport = createRemoteTransport();
> - remoteTransport.setTransportListener(new TransportListener() {
> - Command command = null;
> - public void onCommand(Object o) {
> - this.command = (Command) o;
> - LOG.info("Command from [" +
> command.getFrom() + "] to [" + command.getTo() + "]");
> - }
> -
> - public void onException(IOException error) {
> - LOG.info("Command from [" +
> command.getFrom() + "] to [" + command.getTo() + "]");
> - LOG.info("Exception: " + error);
> - }
> -
> - public void transportInterupted() {
> - LOG.info("Interruption on remote
> transport");
> - }
> -
> - public void transportResumed() {
> - LOG.info("Resumption on remote transport");
> - }
> - });
>
> + // Create a network bridge between the two brokers
> bridge = new DemandForwardingBridge(config, localTransport,
> remoteTransport);
> - bridge.setBrokerService(broker);
> + bridge.setBrokerService(localBroker);
> bridge.start();
>
> - // Enable JMX support on the local and remote brokers
> -// broker.setUseJmx(true);
> -// remoteBroker.setUseJmx(true);
> -
> - // Make sure persistence is disabled
> - broker.setPersistent(false);
> - broker.setPersistenceAdapter(null);
> - remoteBroker.setPersistent(false);
> - remoteBroker.setPersistenceAdapter(null);
> + waitForBridgeFormation();
>
> - // Remove the activemq-data directory from the creation of the
> remote broker
> - FileUtils.deleteDirectory(new File("activemq-data"));
> }
> -
> - protected void tearDown() throws Exception {
> +
> + protected void waitForBridgeFormation() throws Exception {
> + for (final BrokerService broker : brokers.values()) {
> + if (!broker.getNetworkConnectors().isEmpty()) {
> + // Max wait here is 30 secs
> + Wait.waitFor(new Wait.Condition() {
> + public boolean isSatisified() throws Exception {
> + return
> !broker.getNetworkConnectors().get(0).activeBridges().isEmpty();
> + }});
> + }
> + }
> + }
> +
> + protected void tearDown() throws Exception {
> bridge.stop();
> - super.tearDown();
> + localBroker.stop();
> + remoteBroker.stop();
> }
>
> - public void testBrokerNetworkWithStuckMessages() throws Exception {
> -
> - int sendNumMessages = 10;
> - int receiveNumMessages = 5;
> -
> - // Create a producer and send a batch of 10 messages to the
> local broker
> - StubConnection connection1 = createConnection();
> + public void testBrokerNetworkWithStuckMessages() throws Exception {
> +
> + int sendNumMessages = 10;
> + int receiveNumMessages = 5;
> +
> + // Create a producer
> + StubConnection connection1 = createConnection();
> ConnectionInfo connectionInfo1 = createConnectionInfo();
> SessionInfo sessionInfo1 = createSessionInfo(connectionInfo1);
> ProducerInfo producerInfo = createProducerInfo(sessionInfo1);
> @@ -122,25 +152,25 @@
> // Create a destination on the local broker
> ActiveMQDestination destinationInfo1 = null;
>
> + // Send a 10 messages to the local broker
> for (int i = 0; i < sendNumMessages; ++i) {
> - destinationInfo1 = createDestinationInfo(connection1,
> connectionInfo1, ActiveMQDestination.QUEUE_TYPE);
> -// connection1.send(createMessage(producerInfo,
> destinationInfo1, DeliveryMode.NON_PERSISTENT));
> - connection1.request(createMessage(producerInfo,
> destinationInfo1, DeliveryMode.NON_PERSISTENT));
> + destinationInfo1 = createDestinationInfo(connection1,
> connectionInfo1, ActiveMQDestination.QUEUE_TYPE);
> + connection1.request(createMessage(producerInfo,
> destinationInfo1, DeliveryMode.NON_PERSISTENT));
> }
>
> // Ensure that there are 10 messages on the local broker
> - int messageCount1 = countMessagesInQueue(connection1,
> connectionInfo1, destinationInfo1);
> - assertEquals(10, messageCount1);
> + Object[] messages = browseQueueWithJmx(localBroker);
> + assertEquals(sendNumMessages, messages.length);
>
>
> - // Create a consumer on the remote broker
> + // Create a synchronous consumer on the remote broker
> final StubConnection connection2 = createRemoteConnection();
> ConnectionInfo connectionInfo2 = createConnectionInfo();
> SessionInfo sessionInfo2 = createSessionInfo(connectionInfo2);
> connection2.send(connectionInfo2);
> connection2.send(sessionInfo2);
> ActiveMQDestination destinationInfo2 =
> - createDestinationInfo(connection2, connectionInfo2,
> ActiveMQDestination.QUEUE_TYPE);
> + createDestinationInfo(connection2, connectionInfo2,
> ActiveMQDestination.QUEUE_TYPE);
> final ConsumerInfo consumerInfo2 = createConsumerInfo(sessionInfo2,
> destinationInfo2);
> connection2.send(consumerInfo2);
>
> @@ -149,32 +179,27 @@
> // method, this will cause the messages on the local broker to be
> // forwarded to the remote broker.
> for (int i = 0; i < receiveNumMessages; ++i) {
> - assertTrue("Message " + i + " was not received",
> Wait.waitFor(new Wait.Condition() {
> - public boolean isSatisified() throws Exception {
> - Message message1 =
> receiveMessage(connection2);
> - assertNotNull(message1);
> - connection2.send(createAck(consumerInfo2,
> message1, 1, MessageAck.STANDARD_ACK_TYPE));
> - return message1 != null;
> - }
> - }));
> -// Message message1 = receiveMessage(connection2);
> -// assertNotNull(message1);
> -// connection2.send(createAck(consumerInfo2, message1, 1,
> MessageAck.STANDARD_ACK_TYPE));
> + Message message1 = receiveMessage(connection2);
> + assertNotNull(message1);
> + connection2.send(createAck(consumerInfo2, message1, 1,
> MessageAck.STANDARD_ACK_TYPE));
> +
> + Object[] msgs1 = browseQueueWithJmx(remoteBroker);
> + LOG.info("Found [" + msgs1.length + "] messages with JMX");
> +// assertEquals((sendNumMessages-i), msgs.length);
> }
>
> - // Close the consumer on the remote broker
> - connection2.send(consumerInfo2.createRemoveCommand());
> -
> // Ensure that there are zero messages on the local broker. This
> tells
> // us that those messages have been prefetched to the remote broker
> // where the demand exists.
> - int messageCount2 = countMessagesInQueue(connection1,
> connectionInfo1, destinationInfo1);
> -// Sometimes it fails here
> - assertEquals(0, messageCount2);
> + messages = browseQueueWithJmx(localBroker);
> + assertEquals(0, messages.length);
> +
> + // Close the consumer on the remote broker
> + connection2.send(consumerInfo2.createRemoveCommand());
>
> // There should now be 5 messages stuck on the remote broker
> - int messageCount3 = countMessagesInQueue(connection2,
> connectionInfo2, destinationInfo2);
> - assertEquals(5, messageCount3);
> + messages = browseQueueWithJmx(remoteBroker);
> + assertEquals(5, messages.length);
>
> // Create a consumer on the local broker just to confirm that it
> doesn't
> // receive any messages
> @@ -182,13 +207,13 @@
> connection1.send(consumerInfo1);
> Message message1 = receiveMessage(connection1);
>
> - //////////////////////////////////////////////////////
> + //////////////////////////////////////////////////////
> // An assertNull() is done here because this is currently the
> correct
> // behavior. This is actually the purpose of this test - to prove
> that
> // messages are stuck on the remote broker. AMQ-2324 and AMQ-2484
> aim
> // to fix this situation so that messages don't get stuck.
> assertNull(message1);
> - //////////////////////////////////////////////////////
> + //////////////////////////////////////////////////////
>
> ConsumerInfo consumerInfo3 = createConsumerInfo(sessionInfo2,
> destinationInfo2);
> connection2.send(consumerInfo3);
> @@ -197,30 +222,247 @@
> // to clean up the queue.
> int counter = 0;
> for (int i = 0; i < receiveNumMessages; ++i) {
> - message1 = receiveMessage(connection2);
> - assertNotNull(message1);
> + message1 = receiveMessage(connection2);
> + assertNotNull(message1);
> connection2.send(createAck(consumerInfo3, message1, 1,
> MessageAck.STANDARD_ACK_TYPE));
> ++counter;
> }
> // Ensure that 5 messages were received
> assertEquals(receiveNumMessages, counter);
>
> - Thread.sleep(2000);
> + // Let those acks percolate... This stinks but it's the only way
> currently
> + // because these types of internal broker actions are
> non-deterministic.
> + Thread.sleep(4000);
>
> // Ensure that the queue on the remote broker is empty
> - int messageCount4 = countMessagesInQueue(connection2,
> connectionInfo2, destinationInfo1);
> -// Sometimes it fails here
> - assertEquals(0, messageCount4);
> + messages = browseQueueWithJmx(remoteBroker);
> + assertEquals(0, messages.length);
>
> // Close the consumer on the remote broker
> connection2.send(consumerInfo3.createRemoveCommand());
>
> connection1.stop();
> connection2.stop();
> + }
> +
> + protected BrokerService createBroker() throws Exception {
> + localBroker = new BrokerService();
> + localBroker.setBrokerName("localhost");
> + localBroker.setUseJmx(true);
> + localBroker.setPersistenceAdapter(null);
> + localBroker.setPersistent(false);
> + connector = createConnector();
> + localBroker.addConnector(connector);
> + localBroker.start();
> + localBroker.waitUntilStarted();
> +
> + localBroker.getManagementContext().setConnectorPort(2221);
> +
> + brokers.put(localBroker.getBrokerName(), localBroker);
> +
> + return localBroker;
> + }
> +
> + protected BrokerService createRemoteBroker() throws Exception {
> + remoteBroker = new BrokerService();
> + remoteBroker.setBrokerName("remotehost");
> + remoteBroker.setUseJmx(true);
> + remoteBroker.setPersistenceAdapter(null);
> + remoteBroker.setPersistent(false);
> + remoteConnector = createRemoteConnector();
> + remoteBroker.addConnector(remoteConnector);
> + remoteBroker.waitUntilStarted();
> +
> + remoteBroker.getManagementContext().setConnectorPort(2222);
> +
> + brokers.put(remoteBroker.getBrokerName(), remoteBroker);
> +
> + return remoteBroker;
> + }
> +
> + protected Transport createTransport() throws Exception {
> + Transport transport =
> TransportFactory.connect(connector.getServer().getConnectURI());
> + return transport;
> + }
> +
> + protected Transport createRemoteTransport() throws Exception {
> + Transport transport =
> TransportFactory.connect(remoteConnector.getServer().getConnectURI());
> + return transport;
> + }
> +
> + protected TransportConnector createConnector() throws Exception,
> IOException, URISyntaxException {
> + return new TransportConnector(TransportFactory.bind(new
> URI(getLocalURI())));
> + }
> +
> + protected TransportConnector createRemoteConnector() throws Exception,
> IOException, URISyntaxException {
> + return new TransportConnector(TransportFactory.bind(new
> URI(getRemoteURI())));
> + }
> +
> + protected String getRemoteURI() {
> + return "vm://remotehost";
> + }
> +
> + protected String getLocalURI() {
> + return "vm://localhost";
> + }
> +
> + protected StubConnection createConnection() throws Exception {
> + Transport transport =
> TransportFactory.connect(connector.getServer().getConnectURI());
> + StubConnection connection = new StubConnection(transport);
> + connections.add(connection);
> + return connection;
> + }
> +
> + protected StubConnection createRemoteConnection() throws Exception {
> + Transport transport =
> TransportFactory.connect(remoteConnector.getServer().getConnectURI());
> + StubConnection connection = new StubConnection(transport);
> + connections.add(connection);
> + return connection;
> + }
> +
> + @SuppressWarnings("unchecked")
> + private Object[] browseQueueWithJms(BrokerService broker) throws
> Exception {
> + Object[] messages = null;
> + Connection connection = null;
> + Session session = null;
> +
> + try {
> + URI brokerUri = connector.getUri();
> + ActiveMQConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory(brokerUri.toString());
> + connection = connectionFactory.createConnection();
> + connection.start();
> + session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> + Queue destination = session.createQueue(queueName);
> + QueueBrowser browser =
> session.createBrowser(destination);
> + List<Message> list = new ArrayList<Message>();
> + for (Enumeration<Message> enumn =
> browser.getEnumeration(); enumn.hasMoreElements();) {
> + list.add(enumn.nextElement());
> + }
> + messages = list.toArray();
> + }
> + finally {
> + if (session != null) {
> + session.close();
> + }
> + if (connection != null) {
> + connection.close();
> + }
> + }
> + LOG.info("+Browsed with JMS: " + messages.length);
> +
> + return messages;
> }
> -
> - public static Test suite() {
> - return suite(BrokerNetworkWithStuckMessagesTest.class);
> +
> + private Object[] browseQueueWithJmx(BrokerService broker) throws
> Exception {
> + Hashtable<String, String> params = new Hashtable<String,
> String>();
> + params.put("BrokerName", broker.getBrokerName());
> + params.put("Type", "Queue");
> + params.put("Destination", queueName);
> + ObjectName queueObjectName = ObjectName.getInstance(amqDomain,
> params);
> +
> + ManagementContext mgmtCtx = broker.getManagementContext();
> + MBeanServer mbs = mgmtCtx.getMBeanServer();
> + Object[] messages = (Object[]) mbs.invoke(queueObjectName,
> "browse", new Object[0], new String[0]);
> +
> + LOG.info("+Browsed with JMX: " + messages.length);
> +
> + return messages;
> + }
> +
> + protected ConnectionInfo createConnectionInfo() throws Exception {
> + ConnectionInfo info = new ConnectionInfo();
> + info.setConnectionId(new ConnectionId("connection:" +
> (++idGenerator)));
> + info.setClientId(info.getConnectionId().getValue());
> + return info;
> + }
> +
> + protected SessionInfo createSessionInfo(ConnectionInfo connectionInfo)
> throws Exception {
> + SessionInfo info = new SessionInfo(connectionInfo, ++idGenerator);
> + return info;
> + }
> +
> + protected ProducerInfo createProducerInfo(SessionInfo sessionInfo)
> throws Exception {
> + ProducerInfo info = new ProducerInfo(sessionInfo, ++idGenerator);
> + return info;
> + }
> +
> + protected ConsumerInfo createConsumerInfo(SessionInfo sessionInfo,
> ActiveMQDestination destination) throws Exception {
> + ConsumerInfo info = new ConsumerInfo(sessionInfo, ++idGenerator);
> + info.setBrowser(false);
> + info.setDestination(destination);
> + info.setPrefetchSize(1000);
> + info.setDispatchAsync(false);
> + return info;
> + }
> +
> + protected DestinationInfo createTempDestinationInfo(ConnectionInfo
> connectionInfo, byte destinationType) {
> + DestinationInfo info = new DestinationInfo();
> + info.setConnectionId(connectionInfo.getConnectionId());
> + info.setOperationType(DestinationInfo.ADD_OPERATION_TYPE);
> +
> info.setDestination(ActiveMQDestination.createDestination(info.getConnectionId()
> + ":" + (++tempDestGenerator), destinationType));
> + return info;
> + }
> +
> + protected ActiveMQDestination createDestinationInfo(StubConnection
> connection, ConnectionInfo connectionInfo1, byte destinationType) throws
> Exception {
> + if ((destinationType & ActiveMQDestination.TEMP_MASK) != 0) {
> + DestinationInfo info =
> createTempDestinationInfo(connectionInfo1, destinationType);
> + connection.send(info);
> + return info.getDestination();
> + } else {
> + return ActiveMQDestination.createDestination(queueName,
> destinationType);
> + }
> + }
> +
> + protected Message createMessage(ProducerInfo producerInfo,
> ActiveMQDestination destination, int deliveryMode) {
> + Message message = createMessage(producerInfo, destination);
> + message.setPersistent(deliveryMode == DeliveryMode.PERSISTENT);
> + return message;
> + }
> +
> + protected Message createMessage(ProducerInfo producerInfo,
> ActiveMQDestination destination) {
> + ActiveMQTextMessage message = new ActiveMQTextMessage();
> + message.setMessageId(new MessageId(producerInfo,
> ++msgIdGenerator));
> + message.setDestination(destination);
> + message.setPersistent(false);
> + try {
> + message.setText("Test Message Payload.");
> + } catch (MessageNotWriteableException e) {
> + }
> + return message;
> + }
> +
> + protected MessageAck createAck(ConsumerInfo consumerInfo, Message msg,
> int count, byte ackType) {
> + MessageAck ack = new MessageAck();
> + ack.setAckType(ackType);
> + ack.setConsumerId(consumerInfo.getConsumerId());
> + ack.setDestination(msg.getDestination());
> + ack.setLastMessageId(msg.getMessageId());
> + ack.setMessageCount(count);
> + return ack;
> + }
> +
> + public Message receiveMessage(StubConnection connection) throws
> InterruptedException {
> + return receiveMessage(connection, maxWait);
> + }
> +
> + public Message receiveMessage(StubConnection connection, long timeout)
> throws InterruptedException {
> + while (true) {
> + Object o = connection.getDispatchQueue().poll(timeout,
> TimeUnit.MILLISECONDS);
> +
> + if (o == null) {
> + return null;
> + }
> + if (o instanceof MessageDispatch) {
> +
> + MessageDispatch dispatch = (MessageDispatch)o;
> + if (dispatch.getMessage() == null) {
> + return null;
> + }
> + dispatch.setMessage(dispatch.getMessage().copy());
> +
> dispatch.getMessage().setRedeliveryCounter(dispatch.getRedeliveryCounter());
> + return dispatch.getMessage();
> + }
> + }
> }
>
> }
>
>
>

--
http://blog.garytully.com

Open Source Integration
http://fusesource.com

Re: Are JIRA issue flooding your inbox?

2009-11-23T06:32:26Z

On Mon, Nov 23, 2009 at 5:19 AM, Hiram Chirino <hiram@...> wrote:
> I think a good middle ground is that we time box how long we let an
> issue without a unit test sit around before it's kicked. If the
> original reporter or another contributor has not provided a unit test
> in a month, we should close it out.

I agree that we should begin aging issues, especially if they don't
even have steps to reproduce. If they don't even have that, then we
should mark the issue as Can't Reproduce and add a comment encouraging
the user to reopen the issue if they can provide steps to reproduce or
even a test. It really boils down to just staying on top of the issues
as they're opened and taking action to close those that are
insufficient.

Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder

[jira] Updated: (AMQ-2506) Incorrect activemq-policy.xml in activemq-core tests used and referenced in http://activemq.apache.org/dispatch-policies.html.

2009-11-23T06:25:53Z

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

Torsten Mielke updated AMQ-2506:
--------------------------------

Attachment: AMQ-2506.patch

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AMQ-2506) Incorrect activemq-policy.xml in activemq-core tests used and referenced in http://activemq.apache.org/dispatch-policies.html.

2009-11-23T06:23:52Z

Incorrect activemq-policy.xml in activemq-core tests used and referenced in http://activemq.apache.org/dispatch-policies.html.
------------------------------------------------------------------------------------------------------------------------------

Key: AMQ-2506
URL: https://issues.apache.org/activemq/browse/AMQ-2506
Project: ActiveMQ
Issue Type: Bug
Components: Documentation, Test Cases
Affects Versions: 5.3.0
Reporter: Torsten Mielke
Priority: Minor

http://activemq.apache.org/dispatch-policies.html explains the use of dispatch policies and gives an example which is a code snippet taken from activemq/trunk/activemq-core/src/test/resources/org/apache/activemq/xbean/activemq-policy.xml.

That example is incorrect as it configures a round robin dispatch policy for topics but such policy only really makes sense for queues.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AMQNET-211) ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode

2009-11-23T05:55:52Z

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

Timothy Bish updated AMQNET-211:
--------------------------------

Fix Version/s: 1.3.0

> ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode
> ----------------------------------------------------------------------------------------------
>
> Key: AMQNET-211
> URL: https://issues.apache.org/activemq/browse/AMQNET-211
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
> Affects Versions: 1.2.0
> Environment: ActiveMQ 5.3 stable release. tested also with ActiveMQ 5.4 Nightly build
> Apache.NMS 1.2.0.1778
> Apache.NMS.ActiveMQ.dll 1.2.0.1778
> Reporter: Sebastien Rodriguez
> Assignee: Jim Gomes
> Fix For: 1.3.0
>
> Attachments: activemq.xml
>
>
> The problem comes when I set up the following configuration:
> Network of brokers (2 brokers, A and B) in failover mode
> Client written in C# using the Apache.NMS.ActiveMQ client, configured in failover mode. (machine C)
> When stopping manually the service in one computer(A for eg), the switch is done without any problems. C uses B to send the data. The admin console shows he has one consumer.
> Turning the service on and doing the same step in the other computer works great too (the client failovers to the recovered broker again without any problems: C is connected to A now)
> Unplugging the network cable in A does not cause C to switch to B again. Looking at the admin console there are no consumers connected to B.
> Looking the logs of B:
> jvm 1 | WARN | Could not start network bridge between: vm://10.216.1.66 and: tcp://10.216.1.101:61616 due to: java.net.ConnectException: Connection timed out: connect
> This should have raised a ConnectionInterruptedListener event. Logs shoes nothing such happens

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AMQNET-212) Add an Inactivity Monitor to the Transports layer to timeout broken connections

2009-11-23T05:45:52Z

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

Timothy Bish updated AMQNET-212:
--------------------------------

Affects Version/s: (was: 1.3.0)
1.2.0
Fix Version/s: 1.3.0

> Add an Inactivity Monitor to the Transports layer to timeout broken connections
> -------------------------------------------------------------------------------
>
> Key: AMQNET-212
> URL: https://issues.apache.org/activemq/browse/AMQNET-212
> Project: ActiveMQ .Net
> Issue Type: Improvement
> Components: ActiveMQ
> Affects Versions: 1.2.0
> Reporter: Timothy Bish
> Assignee: Timothy Bish
> Fix For: 1.3.0
>
>
> In order to more quickly detect broken connections between client and broker the NMS.AcitveMQ client needs to add an InactivityMonitor transport filter that deals with the keep alive messages that allow for detection of broken sockets. Right now a broken connection such as one that occurs when a cable is pulled isn't detected and the client can sit idle instead of failing over if there's no outbound messages to trigger a failed write.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AMQNET-212) Add an Inactivity Monitor to the Transports layer to timeout broken connections

2009-11-23T05:41:52Z

Add an Inactivity Monitor to the Transports layer to timeout broken connections
-------------------------------------------------------------------------------

Key: AMQNET-212
URL: https://issues.apache.org/activemq/browse/AMQNET-212
Project: ActiveMQ .Net
Issue Type: Improvement
Components: ActiveMQ
Affects Versions: 1.3.0
Reporter: Timothy Bish
Assignee: Timothy Bish

In order to more quickly detect broken connections between client and broker the NMS.AcitveMQ client needs to add an InactivityMonitor transport filter that deals with the keep alive messages that allow for detection of broken sockets. Right now a broken connection such as one that occurs when a cable is pulled isn't detected and the client can sit idle instead of failing over if there's no outbound messages to trigger a failed write.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AMQNET-211) ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode

2009-11-23T05:37:54Z

[ https://issues.apache.org/activemq/browse/AMQNET-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56024#action_56024 ]

Timothy Bish commented on AMQNET-211:
-------------------------------------

It can help but it depends on what the OS timing is for the keep alive.

> ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode
> ----------------------------------------------------------------------------------------------
>
> Key: AMQNET-211
> URL: https://issues.apache.org/activemq/browse/AMQNET-211
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
> Affects Versions: 1.2.0
> Environment: ActiveMQ 5.3 stable release. tested also with ActiveMQ 5.4 Nightly build
> Apache.NMS 1.2.0.1778
> Apache.NMS.ActiveMQ.dll 1.2.0.1778
> Reporter: Sebastien Rodriguez
> Assignee: Jim Gomes
> Attachments: activemq.xml
>
>
> The problem comes when I set up the following configuration:
> Network of brokers (2 brokers, A and B) in failover mode
> Client written in C# using the Apache.NMS.ActiveMQ client, configured in failover mode. (machine C)
> When stopping manually the service in one computer(A for eg), the switch is done without any problems. C uses B to send the data. The admin console shows he has one consumer.
> Turning the service on and doing the same step in the other computer works great too (the client failovers to the recovered broker again without any problems: C is connected to A now)
> Unplugging the network cable in A does not cause C to switch to B again. Looking at the admin console there are no consumers connected to B.
> Looking the logs of B:
> jvm 1 | WARN | Could not start network bridge between: vm://10.216.1.66 and: tcp://10.216.1.101:61616 due to: java.net.ConnectException: Connection timed out: connect
> This should have raised a ConnectionInterruptedListener event. Logs shoes nothing such happens

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AMQNET-211) ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode

2009-11-23T05:29:52Z

[ https://issues.apache.org/activemq/browse/AMQNET-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56023#action_56023 ]

Sebastien Rodriguez commented on AMQNET-211:
--------------------------------------------

Could soKeepAlive option on the connection URI help to switch over connection to the failover URI, in case of a cable unplug?

> ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode
> ----------------------------------------------------------------------------------------------
>
> Key: AMQNET-211
> URL: https://issues.apache.org/activemq/browse/AMQNET-211
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
> Affects Versions: 1.2.0
> Environment: ActiveMQ 5.3 stable release. tested also with ActiveMQ 5.4 Nightly build
> Apache.NMS 1.2.0.1778
> Apache.NMS.ActiveMQ.dll 1.2.0.1778
> Reporter: Sebastien Rodriguez
> Assignee: Jim Gomes
> Attachments: activemq.xml
>
>
> The problem comes when I set up the following configuration:
> Network of brokers (2 brokers, A and B) in failover mode
> Client written in C# using the Apache.NMS.ActiveMQ client, configured in failover mode. (machine C)
> When stopping manually the service in one computer(A for eg), the switch is done without any problems. C uses B to send the data. The admin console shows he has one consumer.
> Turning the service on and doing the same step in the other computer works great too (the client failovers to the recovered broker again without any problems: C is connected to A now)
> Unplugging the network cable in A does not cause C to switch to B again. Looking at the admin console there are no consumers connected to B.
> Looking the logs of B:
> jvm 1 | WARN | Could not start network bridge between: vm://10.216.1.66 and: tcp://10.216.1.101:61616 due to: java.net.ConnectException: Connection timed out: connect
> This should have raised a ConnectionInterruptedListener event. Logs shoes nothing such happens

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AMQNET-211) ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode

2009-11-23T05:23:54Z

[ https://issues.apache.org/activemq/browse/AMQNET-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56022#action_56022 ]

Timothy Bish commented on AMQNET-211:
-------------------------------------

Ok, this is working as I'd expect then. The NMS.ActiveMQ implementation currently doesn't have an inactivity monitor so there's no active ping of the connection from the client so in the case of the network plug being pulled you are essentially waiting for the OS to timeout the socket, this can take up to an hour depending on the OS and the TCP/IP config.

Adding an inactivity monitor is on my TODO list but I'm not sure it will make it into the 1.2.0 release, we are planning on cutting release candidates for that this week.

> ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode
> ----------------------------------------------------------------------------------------------
>
> Key: AMQNET-211
> URL: https://issues.apache.org/activemq/browse/AMQNET-211
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
> Affects Versions: 1.2.0
> Environment: ActiveMQ 5.3 stable release. tested also with ActiveMQ 5.4 Nightly build
> Apache.NMS 1.2.0.1778
> Apache.NMS.ActiveMQ.dll 1.2.0.1778
> Reporter: Sebastien Rodriguez
> Assignee: Jim Gomes
> Attachments: activemq.xml
>
>
> The problem comes when I set up the following configuration:
> Network of brokers (2 brokers, A and B) in failover mode
> Client written in C# using the Apache.NMS.ActiveMQ client, configured in failover mode. (machine C)
> When stopping manually the service in one computer(A for eg), the switch is done without any problems. C uses B to send the data. The admin console shows he has one consumer.
> Turning the service on and doing the same step in the other computer works great too (the client failovers to the recovered broker again without any problems: C is connected to A now)
> Unplugging the network cable in A does not cause C to switch to B again. Looking at the admin console there are no consumers connected to B.
> Looking the logs of B:
> jvm 1 | WARN | Could not start network bridge between: vm://10.216.1.66 and: tcp://10.216.1.101:61616 due to: java.net.ConnectException: Connection timed out: connect
> This should have raised a ConnectionInterruptedListener event. Logs shoes nothing such happens

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AMQNET-211) ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode

2009-11-23T05:17:52Z

[ https://issues.apache.org/activemq/browse/AMQNET-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56021#action_56021 ]

Sebastien Rodriguez commented on AMQNET-211:
--------------------------------------------

Yes, this happens when unplugging the network cable from the broker used by the client in the network of brokers.
The failover works great when shut downing the broker

> ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode
> ----------------------------------------------------------------------------------------------
>
> Key: AMQNET-211
> URL: https://issues.apache.org/activemq/browse/AMQNET-211
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
> Affects Versions: 1.2.0
> Environment: ActiveMQ 5.3 stable release. tested also with ActiveMQ 5.4 Nightly build
> Apache.NMS 1.2.0.1778
> Apache.NMS.ActiveMQ.dll 1.2.0.1778
> Reporter: Sebastien Rodriguez
> Assignee: Jim Gomes
> Attachments: activemq.xml
>
>
> The problem comes when I set up the following configuration:
> Network of brokers (2 brokers, A and B) in failover mode
> Client written in C# using the Apache.NMS.ActiveMQ client, configured in failover mode. (machine C)
> When stopping manually the service in one computer(A for eg), the switch is done without any problems. C uses B to send the data. The admin console shows he has one consumer.
> Turning the service on and doing the same step in the other computer works great too (the client failovers to the recovered broker again without any problems: C is connected to A now)
> Unplugging the network cable in A does not cause C to switch to B again. Looking at the admin console there are no consumers connected to B.
> Looking the logs of B:
> jvm 1 | WARN | Could not start network bridge between: vm://10.216.1.66 and: tcp://10.216.1.101:61616 due to: java.net.ConnectException: Connection timed out: connect
> This should have raised a ConnectionInterruptedListener event. Logs shoes nothing such happens

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AMQNET-211) ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode

2009-11-23T05:13:52Z

[ https://issues.apache.org/activemq/browse/AMQNET-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56020#action_56020 ]

Timothy Bish commented on AMQNET-211:
-------------------------------------

So this only happens when you pull the network plug, but works fine when you shutdown a broker? It should like a symptom of not having an inactivity monitor yet in NMS.ActiveMQ.

> ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode
> ----------------------------------------------------------------------------------------------
>
> Key: AMQNET-211
> URL: https://issues.apache.org/activemq/browse/AMQNET-211
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
> Affects Versions: 1.2.0
> Environment: ActiveMQ 5.3 stable release. tested also with ActiveMQ 5.4 Nightly build
> Apache.NMS 1.2.0.1778
> Apache.NMS.ActiveMQ.dll 1.2.0.1778
> Reporter: Sebastien Rodriguez
> Assignee: Jim Gomes
> Attachments: activemq.xml
>
>
> The problem comes when I set up the following configuration:
> Network of brokers (2 brokers, A and B) in failover mode
> Client written in C# using the Apache.NMS.ActiveMQ client, configured in failover mode. (machine C)
> When stopping manually the service in one computer(A for eg), the switch is done without any problems. C uses B to send the data. The admin console shows he has one consumer.
> Turning the service on and doing the same step in the other computer works great too (the client failovers to the recovered broker again without any problems: C is connected to A now)
> Unplugging the network cable in A does not cause C to switch to B again. Looking at the admin console there are no consumers connected to B.
> Looking the logs of B:
> jvm 1 | WARN | Could not start network bridge between: vm://10.216.1.66 and: tcp://10.216.1.101:61616 due to: java.net.ConnectException: Connection timed out: connect
> This should have raised a ConnectionInterruptedListener event. Logs shoes nothing such happens

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AMQNET-211) ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode

2009-11-23T04:19:52Z

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

Sebastien Rodriguez updated AMQNET-211:
---------------------------------------

Attachment: activemq.xml

ActiveMQ configuration file

> ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode
> ----------------------------------------------------------------------------------------------
>
> Key: AMQNET-211
> URL: https://issues.apache.org/activemq/browse/AMQNET-211
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
> Affects Versions: 1.2.0
> Environment: ActiveMQ 5.3 stable release. tested also with ActiveMQ 5.4 Nightly build
> Apache.NMS 1.2.0.1778
> Apache.NMS.ActiveMQ.dll 1.2.0.1778
> Reporter: Sebastien Rodriguez
> Assignee: Jim Gomes
> Attachments: activemq.xml
>
>
> The problem comes when I set up the following configuration:
> Network of brokers (2 brokers, A and B) in failover mode
> Client written in C# using the Apache.NMS.ActiveMQ client, configured in failover mode. (machine C)
> When stopping manually the service in one computer(A for eg), the switch is done without any problems. C uses B to send the data. The admin console shows he has one consumer.
> Turning the service on and doing the same step in the other computer works great too (the client failovers to the recovered broker again without any problems: C is connected to A now)
> Unplugging the network cable in A does not cause C to switch to B again. Looking at the admin console there are no consumers connected to B.
> Looking the logs of B:
> jvm 1 | WARN | Could not start network bridge between: vm://10.216.1.66 and: tcp://10.216.1.101:61616 due to: java.net.ConnectException: Connection timed out: connect
> This should have raised a ConnectionInterruptedListener event. Logs shoes nothing such happens

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Are JIRA issue flooding your inbox?

2009-11-23T04:19:26Z

I think a good middle ground is that we time box how long we let an
issue without a unit test sit around before it's kicked. If the
original reporter or another contributor has not provided a unit test
in a month, we should close it out.

On Sat, Nov 21, 2009 at 11:32 AM, Bruce Snyder <bruce.snyder@...> wrote:

> On Sat, Nov 21, 2009 at 12:38 AM, Rob Davies <rajdavies@...> wrote:
>> I attempt weeding every few months - trouble is - its a jungle ;)
>
> Agreed, which is why I'm trying to get everyone to look at a few. Then
> we can move on to the 5.4.0 issues using the same scrutiny.
>
>> A lot of
>> the unresolved issues will take a lot of time to validate - as they do have
>> steps to reproduce - but they aren't junit tests
>
> HIram and I talked about that briefly. We agreed that we need to be
> more strict about this. Hiram is in favor of kicking any issue that
> doesn't have a test. I wouldn't go that far, my threshold is a
> requirement of steps to reproduce. So if neither of those are
> available, and the issue seems sufficiently unclear, just kick it.
>
>> Can you make the filter public btw ? I can't see it
>
> Sorry about that, it's now shared.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
>

--
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://fusesource.com/

[jira] Updated: (AMQNET-211) ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode

2009-11-23T04:17:56Z

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

Sebastien Rodriguez updated AMQNET-211:
---------------------------------------

Affects Version/s: (was: 1.3.0)
1.2.0

error in the NMS client version

> ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode
> ----------------------------------------------------------------------------------------------
>
> Key: AMQNET-211
> URL: https://issues.apache.org/activemq/browse/AMQNET-211
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
> Affects Versions: 1.2.0
> Environment: ActiveMQ 5.3 stable release. tested also with ActiveMQ 5.4 Nightly build
> Apache.NMS 1.2.0.1778
> Apache.NMS.ActiveMQ.dll 1.2.0.1778
> Reporter: Sebastien Rodriguez
> Assignee: Jim Gomes
>
> The problem comes when I set up the following configuration:
> Network of brokers (2 brokers, A and B) in failover mode
> Client written in C# using the Apache.NMS.ActiveMQ client, configured in failover mode. (machine C)
> When stopping manually the service in one computer(A for eg), the switch is done without any problems. C uses B to send the data. The admin console shows he has one consumer.
> Turning the service on and doing the same step in the other computer works great too (the client failovers to the recovered broker again without any problems: C is connected to A now)
> Unplugging the network cable in A does not cause C to switch to B again. Looking at the admin console there are no consumers connected to B.
> Looking the logs of B:
> jvm 1 | WARN | Could not start network bridge between: vm://10.216.1.66 and: tcp://10.216.1.101:61616 due to: java.net.ConnectException: Connection timed out: connect
> This should have raised a ConnectionInterruptedListener event. Logs shoes nothing such happens

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AMQNET-211) ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode

2009-11-23T04:17:56Z

ConnectionInterruptedListener doesnt raise the event when broker network dies in failover mode
----------------------------------------------------------------------------------------------

Key: AMQNET-211
URL: https://issues.apache.org/activemq/browse/AMQNET-211
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ, NMS
Affects Versions: 1.3.0
Environment: ActiveMQ 5.3 stable release. tested also with ActiveMQ 5.4 Nightly build
Apache.NMS 1.2.0.1778
Apache.NMS.ActiveMQ.dll 1.2.0.1778
Reporter: Sebastien Rodriguez
Assignee: Jim Gomes

The problem comes when I set up the following configuration:
Network of brokers (2 brokers, A and B) in failover mode
Client written in C# using the Apache.NMS.ActiveMQ client, configured in failover mode. (machine C)

When stopping manually the service in one computer(A for eg), the switch is done without any problems. C uses B to send the data. The admin console shows he has one consumer.
Turning the service on and doing the same step in the other computer works great too (the client failovers to the recovered broker again without any problems: C is connected to A now)
Unplugging the network cable in A does not cause C to switch to B again. Looking at the admin console there are no consumers connected to B.

Looking the logs of B:
jvm 1 | WARN | Could not start network bridge between: vm://10.216.1.66 and: tcp://10.216.1.101:61616 due to: java.net.ConnectException: Connection timed out: connect

This should have raised a ConnectionInterruptedListener event. Logs shoes nothing such happens

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AMQ-2505) Problem with servicing broker messages when client hostName contains "language specific" characters (org.apache.activemq.util.IdGenerator problem)

2009-11-23T02:53:52Z

Problem with servicing broker messages when client hostName contains "language specific" characters (org.apache.activemq.util.IdGenerator problem)
--------------------------------------------------------------------------------------------------------------------------------------------------

Key: AMQ-2505
URL: https://issues.apache.org/activemq/browse/AMQ-2505
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.2.0
Environment: Windows XP SP2
Reporter: Pawel Sniezek

When name of the activeMQ client machine contains "language specific" letters (e.g. "Gł_Ksiegowa") communication fails:
"Caused by: java.io.IOException: Failed to broker message: ID:Gł_Ksiegowa-1407-1256558735734-0:2:3:1:1 in container: java.io.UTFDataFormatException: bad string "

To resolve the problem in our system we've changed org.apache.activemq.util.IdGenerator code - we replaced line:

"hostName = InetAddress.getLocalHost().getHostName();"

with:

"hostName = InetAddress.getLocalHost().getHostAddress();"

The whole exception below:

ERROR 2009-10-26 13:07:30,781 [AWT-EventQueue-0] - Local JMS transaction failed to commit; nested exception is javax.jms.JMSException: POST COMMIT FAILED
org.springframework.jms.connection.SynchedLocalTransactionFailedException: Local JMS transaction failed to commit; nested exception is javax.jms.JMSException: POST COMMIT FAILED
at org.springframework.jms.connection.ConnectionFactoryUtils$JmsResourceSynchronization.processResourceAfterCommit(ConnectionFactoryUtils.java:408)
at org.springframework.transaction.support.ResourceHolderSynchronization.afterCommit(ResourceHolderSynchronization.java:74)
at org.springframework.transaction.support.TransactionSynchronizationUtils.invokeAfterCommit(TransactionSynchronizationUtils.java:114)
at org.springframework.transaction.support.TransactionSynchronizationUtils.triggerAfterCommit(TransactionSynchronizationUtils.java:100)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerAfterCommit(AbstractPlatformTransactionManager.java:931)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:774)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:701)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:635)
at info.fingo.asist.gui.controls.periodslist.status.ReportStatusHelper$$EnhancerByCGLIB$$2dab363.changeReportsStatus(<generated>)
at info.fingo.asist.action.ChangeReportStatusAction.asistActionPerformed(ChangeReportStatusAction.java:30)
at info.fingo.asist.action.MultiReportAction.asistActionPerformed(MultiReportAction.java:80)
at info.fingo.asist.action.AsistAction.fireAsistActionPerformed(AsistAction.java:297)
at info.fingo.asist.action.AsistAction.actionPerformed(AsistAction.java:322)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: javax.jms.JMSException: POST COMMIT FAILED
at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1244)
at org.apache.activemq.TransactionContext.commit(TransactionContext.java:263)
at org.apache.activemq.ActiveMQSession.commit(ActiveMQSession.java:502)
at org.springframework.jms.connection.JmsResourceHolder.commitAll(JmsResourceHolder.java:182)
at org.springframework.jms.connection.ConnectionFactoryUtils$JmsResourceSynchronization.processResourceAfterCommit(ConnectionFactoryUtils.java:405)
... 43 more
Caused by: javax.transaction.xa.XAException: POST COMMIT FAILED
at org.apache.activemq.transaction.LocalTransaction.commit(LocalTransaction.java:77)
at org.apache.activemq.broker.TransactionBroker.commitTransaction(TransactionBroker.java:154)
at org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:94)
at org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:94)
at org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:104)
at org.apache.activemq.broker.TransportConnection.processCommitTransactionOnePhase(TransportConnection.java:424)
at org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:99)
at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:294)
at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:185)
at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:65)
at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:133)
at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122)
at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84)
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: java.io.IOException: Failed to broker message: ID:Gł_Ksiegowa-1407-1256558735734-0:2:3:1:1 in container: java.io.UTFDataFormatException: bad string
at org.apache.activemq.broker.region.IndirectMessageReference.incrementReferenceCount(IndirectMessageReference.java:103)
at org.apache.activemq.broker.region.QueueSubscription.dispatch(QueueSubscription.java:170)
at org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:129)
at org.apache.activemq.broker.region.policy.RoundRobinDispatchPolicy.dispatch(RoundRobinDispatchPolicy.java:58)
at org.apache.activemq.broker.region.Queue.dispatch(Queue.java:520)
at org.apache.activemq.broker.region.Queue.access$600(Queue.java:75)
at org.apache.activemq.broker.region.Queue$3.afterCommit(Queue.java:341)
at org.apache.activemq.transaction.Transaction.fireAfterCommit(Transaction.java:83)
at org.apache.activemq.transaction.LocalTransaction.commit(LocalTransaction.java:71)
... 14 more
Caused by: java.io.IOException: Failed to broker message: ID:Gł_Ksiegowa-1407-1256558735734-0:2:3:1:1 in container: java.io.UTFDataFormatException: bad string
at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:31)
at org.apache.activemq.store.jdbc.JDBCMessageStore.getMessage(JDBCMessageStore.java:107)
at org.apache.activemq.store.ProxyMessageStore.getMessage(ProxyMessageStore.java:48)
at org.apache.activemq.broker.region.IndirectMessageReference.incrementReferenceCount(IndirectMessageReference.java:95)
... 22 more
Caused by: java.io.UTFDataFormatException: bad string
at org.apache.activemq.util.DataByteArrayInputStream.readUTF(DataByteArrayInputStream.java:277)
at org.apache.activemq.openwire.v2.BaseDataStreamMarshaller.looseUnmarshalString(BaseDataStreamMarshaller.java:536)
at org.apache.activemq.openwire.v2.ConnectionIdMarshaller.looseUnmarshal(ConnectionIdMarshaller.java:113)
at org.apache.activemq.openwire.OpenWireFormat.looseUnmarshalNestedObject(OpenWireFormat.java:445)
at org.apache.activemq.openwire.v2.BaseDataStreamMarshaller.looseUnmarsalCachedObject(BaseDataStreamMarshaller.java:454)
at org.apache.activemq.openwire.v2.LocalTransactionIdMarshaller.looseUnmarshal(LocalTransactionIdMarshaller.java:117)
at org.apache.activemq.openwire.OpenWireFormat.looseUnmarshalNestedObject(OpenWireFormat.java:445)
at org.apache.activemq.openwire.v2.BaseDataStreamMarshaller.looseUnmarsalCachedObject(BaseDataStreamMarshaller.java:454)
at org.apache.activemq.openwire.v2.MessageMarshaller.looseUnmarshal(MessageMarshaller.java:195)
at org.apache.activemq.openwire.v2.ActiveMQMessageMarshaller.looseUnmarshal(ActiveMQMessageMarshaller.java:101)
at org.apache.activemq.openwire.v2.ActiveMQObjectMessageMarshaller.looseUnmarshal(ActiveMQObjectMessageMarshaller.java:101)
at org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:349)
at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:204)
at org.apache.activemq.store.jdbc.JDBCMessageStore.getMessage(JDBCMessageStore.java:104)
... 24 more

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AMQ-2504) Synchronize time without modifying the system date.

2009-11-22T17:03:54Z

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

Adam Walczak updated AMQ-2504:
------------------------------

Description:
I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.

Scenario:

1. Servers system date is sync'ed with an NTP server.

2. Clients retrieve their time difference from the NTP server

3. The client set ActiveMq...setTimeDifferenceToServer(...)

4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()

I think it also would be an good idea to wrapper the System.getCurrentMillis() in a internal ActiveMQ method and never call it again directly. This would allow the above modifications and perhaps a to transit to System.nanoTime() to indicate millis in the future which is far more accurate (getCurrentMillis() has a 0-20ms error range).

was:
I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.

Scenario:

1. Servers system date is sync'ed with an NTP server.

2. Clients retrieve their time difference from the NTP server

3. The client set ActiveMq...setTimeDifferenceToServer(...)

4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()

I also would be an good idea I think to wrapper the System.getCurrentMillis() in a internal ActiveMQ method and never call it again directly. This would allow the above modifications and perhaps a to transit to System.nanoTime() to indicate millis in the future which is far more accurate (getCurrentMillis() has a 0-20ms error range).

> Synchronize time without modifying the system date.
> ---------------------------------------------------
>
> Key: AMQ-2504
> URL: https://issues.apache.org/activemq/browse/AMQ-2504
> Project: ActiveMQ
> Issue Type: Improvement
> Components: JMS client
> Reporter: Adam Walczak
>
> I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.
> Scenario:
> 1. Servers system date is sync'ed with an NTP server.
> 2. Clients retrieve their time difference from the NTP server
> 3. The client set ActiveMq...setTimeDifferenceToServer(...)
> 4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()
> I think it also would be an good idea to wrapper the System.getCurrentMillis() in a internal ActiveMQ method and never call it again directly. This would allow the above modifications and perhaps a to transit to System.nanoTime() to indicate millis in the future which is far more accurate (getCurrentMillis() has a 0-20ms error range).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AMQ-2504) Synchronize time without modifying the system date.

2009-11-22T17:03:53Z

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

Adam Walczak updated AMQ-2504:
------------------------------

Description:
I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.

Scenario:

1. Servers system date is sync'ed with an NTP server.

2. Clients retrieve their time difference from the NTP server

3. The client set ActiveMq...setTimeDifferenceToServer(...)

4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()

I also would be an good idea I think to wrapper the System.getCurrentMillis() in a internal ActiveMQ method and never call it again directly. This would allow the above modifications and perhaps a to transit to System.nanoTime() to indicate millis in the future which is far more accurate (getCurrentMillis() has a 0-20ms error range).

was:
I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.

Scenario:

1. Servers system date is sync'ed with an NTP server.

2. Clients retrieve their time difference from the NTP server

3. The client set ActiveMq...setTimeDifferenceToServer(...)

4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()

> Synchronize time without modifying the system date.
> ---------------------------------------------------
>
> Key: AMQ-2504
> URL: https://issues.apache.org/activemq/browse/AMQ-2504
> Project: ActiveMQ
> Issue Type: Improvement
> Components: JMS client
> Reporter: Adam Walczak
>
> I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.
> Scenario:
> 1. Servers system date is sync'ed with an NTP server.
> 2. Clients retrieve their time difference from the NTP server
> 3. The client set ActiveMq...setTimeDifferenceToServer(...)
> 4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()
> I also would be an good idea I think to wrapper the System.getCurrentMillis() in a internal ActiveMQ method and never call it again directly. This would allow the above modifications and perhaps a to transit to System.nanoTime() to indicate millis in the future which is far more accurate (getCurrentMillis() has a 0-20ms error range).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AMQ-2504) Synchronize time without modifying the system date.

2009-11-22T04:29:53Z

Synchronize time without modifying the system date.
---------------------------------------------------

Key: AMQ-2504
URL: https://issues.apache.org/activemq/browse/AMQ-2504
Project: ActiveMQ
Issue Type: Improvement
Components: JMS client
Reporter: Adam Walczak

I have a proposal to create a global variable in ActiveMQ's internals which alters the value of System.getCurrentMillis(). Thanks to this we should be able to synchronize clients connected to a JMS server (equipped with an additional NTP server for example) with out modifying their system dates.

Scenario:

1. Servers system date is sync'ed with an NTP server.

2. Clients retrieve their time difference from the NTP server

3. The client set ActiveMq...setTimeDifferenceToServer(...)

4. Every call for system millis in ActiveMQ sources looks like this: System.getCurrentMillis() + ActiveMq...getTimeDifferenceToServer()

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Weblogic integration

2009-11-21T17:12:19Z

JMS provides a standard for how your code talks to a messaging
provider, but not how two messaging providers talk to each other. In
fact there is no good way to transfer messages between the WebLogic
JMS provider and ActiveMQ (or between any other two JMS providers, for
that matter). You would have to use a bridge that essentially listens
on WebLogic destinations and reposts messages to ActiveMQ or vice
versa. I wouldn't recommend that.

The better way would be to completely ignore the WebLogic JMS
features. You can deploy the ActiveMQ resource adapter in your
WebLogic application EAR and configure any MDBs in your application to
receive messages from ActiveMQ via that resource adapter. You could
also arrange for any connection factories and destinations in your
application to point to ActiveMQ via that resource adapter. I think
that would be the most reliable way to have a Java EE application use
ActiveMQ.

Thanks,
Aaron

On Fri, Nov 20, 2009 at 6:32 PM, Dickyp <rickplatt2002@...> wrote:

>
> Aaron
>
> I have a weblogic server which will be the JMS provider connected to a
> remote ActiveMQ server, the weblogic server will contain MDBs to process
> incoming messages from the ActiveMq server,and generate outgoing messages to
> the the ActiveMQ server.
>
> I thought I would just have to configure a bridge on my weblogic server to
> the remote ActiveMq server.
>
> Is the point about JMS that there is a standard and messages should flow
> between any platform independant of the message brokers used.
>
> Please remeber I am new to this area, certainly in production environment.
> And appreciate any advice or help you can provide.
> Richard
>
>
> ammulder wrote:
>>
>> Can you explain exactly what you're trying to achieve? For instance,
>> will you use the WebLogic JMS provider at all? Are you trying to
>> bridge between WebLogic JMS and ActiveMQ? Or do you want to use
>> strictly ActiveMQ, where your application sends messages only to
>> ActiveMQ, and MDBs or something get invoked directly from ActiveMQ?
>> What kind of components will be sending and receiving messages? Are
>> you using a Java EE stack (MDBs) or Spring or something else?
>>
>> I ask all this because the integration strategy would be somewhat
>> different for all of these cases.
>>
>> Thanks,
>> Aaron
>>
>> On Fri, Nov 20, 2009 at 10:15 AM, Dickyp <rickplatt2002@...>
>> wrote:
>>>
>>> Bruce
>>>
>>> Yes I did, but seemed to relate more to installing ActiveMQ on a weblogic
>>> server itself, rather than processing messages from an ActiveMQ server on
>>> a
>>> weblogic server.
>>>
>>> Thanks for the input anyways.
>>>
>>> Richard
>>>
>>>
>>>
>>> bsnyder wrote:
>>>>
>>>> On Wed, Nov 18, 2009 at 11:07 AM, Dickyp <rickplatt2002@...>
>>>> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> I am pretty new to J2ee and JMS, but can anybody point me in the
>>>>> direction
>>>>> of integration of activemq and weblogic (11). I am running JMS on my
>>>>> weblogic server and want to integrate to external activemq server.
>>>>>
>>>>> I knwo I need to configure an external bridge to the 3rd party message
>>>>> provider, but assume some classes may be required specifically for
>>>>> activemq.
>>>>>
>>>>> Any help appreciated.
>>>>
>>>> Have you looked at the doc on the website about this?:
>>>>
>>>> http://activemq.apache.org/weblogic-integration.html
>>>>
>>>> Bruce
>>>> --
>>>> perl -e 'print
>>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>>>> );'
>>>>
>>>> ActiveMQ in Action: http://bit.ly/2je6cQ
>>>> Blog: http://bruceblog.org/
>>>> Twitter: http://twitter.com/brucesnyder
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Weblogic-integration-tp26412743p26442658.html
>>> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Weblogic-integration-tp26412743p26451916.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
>

Re: Are JIRA issue flooding your inbox?

2009-11-21T08:32:55Z

On Sat, Nov 21, 2009 at 12:38 AM, Rob Davies <rajdavies@...> wrote:
> I attempt weeding every few months - trouble is - its a jungle ;)

Agreed, which is why I'm trying to get everyone to look at a few. Then
we can move on to the 5.4.0 issues using the same scrutiny.

> A lot of
> the unresolved issues will take a lot of time to validate - as they do have
> steps to reproduce - but they aren't junit tests

HIram and I talked about that briefly. We agreed that we need to be
more strict about this. Hiram is in favor of kicking any issue that
doesn't have a test. I wouldn't go that far, my threshold is a
requirement of steps to reproduce. So if neither of those are
available, and the issue seems sufficiently unclear, just kick it.

> Can you make the filter public btw ? I can't see it

Sorry about that, it's now shared.

Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder

Re: Are JIRA issue flooding your inbox?

2009-11-20T23:38:53Z

I attempt weeding every few months - trouble is - its a jungle ;) A
lot of the unresolved issues will take a lot of time to validate - as
they do have steps to reproduce - but they aren't junit tests
Can you make the filter public btw ? I can't see it

On 21 Nov 2009, at 02:30, Bruce Snyder wrote:

> Today I attacked JIRA with the goal of weeding out issues that no
> longer apply. I worked through about 150 issues, closing many old and
> unrelated issues, recategorizing others. Some of those issues (only 31
> of them) have been marked with a version named NEEDS_REVIEWED. I've
> created and shared a filter for these issues here:
>
> https://issues.apache.org/activemq/secure/IssueNavigator.jspa?mode=hide&requestId=11516
>
> These issues need further attention. So I'm asking that you take a bit
> to review just a few of those issues with the following items in mind:
>
> 1) Does the issue have a patch? If so, please dig in enough to
> determine if the issue is still valid.
> 2) Does the issue have steps to reproduce? If so, please dig in to
> determine if the issue is still valid.
> 2) Are there votes and watches on the issue indicating popularity? If
> so, reconsider before closing an issue.
>
> With all of us pitching into to do a little bit of work, the task will
> get done faster. The goal of this exercise is to:
>
> 1) Mark issues for 5.4.0 if they still apply
> 2) Close issues that no longer apply
> 3) Close issues that don't have enough info to reproduce
> 4) Recategorize issues that simply request a feature with no other
> info as type Wish
>
> Let me know if you have any problems or questions.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!
> G;6%I;\"YC;VT*"
> );'
>
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder

Rob Davies
http://twitter.com/rajdavies
I work here: http://fusesource.com
My Blog: http://rajdavies.blogspot.com/
I'm writing this: http://www.manning.com/snyder/

Are JIRA issue flooding your inbox?

2009-11-20T18:30:19Z

Today I attacked JIRA with the goal of weeding out issues that no
longer apply. I worked through about 150 issues, closing many old and
unrelated issues, recategorizing others. Some of those issues (only 31
of them) have been marked with a version named NEEDS_REVIEWED. I've
created and shared a filter for these issues here:

https://issues.apache.org/activemq/secure/IssueNavigator.jspa?mode=hide&requestId=11516

These issues need further attention. So I'm asking that you take a bit
to review just a few of those issues with the following items in mind:

1) Does the issue have a patch? If so, please dig in enough to
determine if the issue is still valid.
2) Does the issue have steps to reproduce? If so, please dig in to
determine if the issue is still valid.
2) Are there votes and watches on the issue indicating popularity? If
so, reconsider before closing an issue.

With all of us pitching into to do a little bit of work, the task will
get done faster. The goal of this exercise is to:

1) Mark issues for 5.4.0 if they still apply
2) Close issues that no longer apply
3) Close issues that don't have enough info to reproduce
4) Recategorize issues that simply request a feature with no other
info as type Wish

Let me know if you have any problems or questions.

Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder