Nabble - ActiveMQ

[jira] Resolved: (AMQNET-111) Constructor for Apache.NMS.ActiveMQ.Connection invokes transport.Start()

2008-09-05T17:35:52Z

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

Jim Gomes resolved AMQNET-111.
------------------------------

Assignee: Jim Gomes (was: James Strachan)
Fix Version/s: 1.0
Resolution: Fixed

Changed default value of started for the Connection to false.

> Constructor for Apache.NMS.ActiveMQ.Connection invokes transport.Start()
> ------------------------------------------------------------------------
>
> Key: AMQNET-111
> URL: https://issues.apache.org/activemq/browse/AMQNET-111
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ Client
> Reporter: Mark Keenan
> Assignee: Jim Gomes
> Priority: Minor
> Fix For: 1.0
>
>
> I have observed that messages are received on a connection before the connection is started.
> Please see this Spring.NET forum post for details:
> http://forum.springframework.net/showpost.php?p=13233&postcount=4

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

From forum: ActiveMQ - Dev

svn commit: r692594 - in /activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk: ./ src/main/csharp/Connection.cs

2008-09-05T17:33:22Z

Author: jgomes
Date: Fri Sep 5 17:33:21 2008
New Revision: 692594

URL: http://svn.apache.org/viewvc?rev=692594&view=rev
Log:
Change default value for started to false.
Fixes [AMQNET-111]. (See https://issues.apache.org/activemq/browse/AMQNET-111)

Modified:
activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk/ (props changed)
activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk/src/main/csharp/Connection.cs

Propchange: activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk/
------------------------------------------------------------------------------
--- svn:mergeinfo (added)
+++ svn:mergeinfo Fri Sep 5 17:33:21 2008
@@ -0,0 +1 @@
+/activemq/activemq-dotnet/Apache.NMS.ActiveMQ/tags/1.0.0:692591

Modified: activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk/src/main/csharp/Connection.cs
URL: http://svn.apache.org/viewvc/activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk/src/main/csharp/Connection.cs?rev=692594&r1=692593&r2=692594&view=diff
==============================================================================
--- activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk/src/main/csharp/Connection.cs (original)
+++ activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk/src/main/csharp/Connection.cs Fri Sep 5 17:33:21 2008
@@ -44,7 +44,7 @@
private long sessionCounter = 0;
private long temporaryDestinationCounter = 0;
private long localTransactionCounter;
- private readonly AtomicBoolean started = new AtomicBoolean(true);
+ private readonly AtomicBoolean started = new AtomicBoolean(false);
private bool disposed = false;

public Connection(Uri connectionUri, ITransport transport, ConnectionInfo info)

From forum: ActiveMQ - Commits

svn commit: r692592 - in /activemq/activemq-dotnet: ./ Apache.NMS.ActiveMQ/trunk/ Apache.NMS.EMS/tags/1.0.0/ Apache.NMS.EMS/trunk/ Apache.NMS.MSMQ/tags/1.0.0/ Apache.NMS.MSMQ/trunk/ Apache.NMS/tags/1.0.0/ Apache.NMS/tags/1.0.0/src/main/csharp/Util/ Apa...

2008-09-05T17:27:12Z

Author: jgomes
Date: Fri Sep 5 17:27:12 2008
New Revision: 692592

URL: http://svn.apache.org/viewvc?rev=692592&view=rev
Log:
Set bugtraq integration properties at top level of repository tree.

Modified:
activemq/activemq-dotnet/ (props changed)
activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk/ (props changed)
activemq/activemq-dotnet/Apache.NMS.EMS/tags/1.0.0/ (props changed)
activemq/activemq-dotnet/Apache.NMS.EMS/trunk/ (props changed)
activemq/activemq-dotnet/Apache.NMS.MSMQ/tags/1.0.0/ (props changed)
activemq/activemq-dotnet/Apache.NMS.MSMQ/trunk/ (props changed)
activemq/activemq-dotnet/Apache.NMS/tags/1.0.0/ (props changed)
activemq/activemq-dotnet/Apache.NMS/tags/1.0.0/src/main/csharp/Util/ (props changed)
activemq/activemq-dotnet/Apache.NMS/trunk/ (props changed)
activemq/activemq-dotnet/Apache.NMS/trunk/src/main/csharp/Util/ (props changed)

Propchange: activemq/activemq-dotnet/
------------------------------------------------------------------------------
bugtraq:label = Issue#:

Propchange: activemq/activemq-dotnet/
------------------------------------------------------------------------------
--- bugtraq:message (added)
+++ bugtraq:message Fri Sep 5 17:27:12 2008
@@ -0,0 +1 @@
+Fixes [AMQNET-%BUGID%]. (See https://issues.apache.org/activemq/browse/AMQNET-%BUGID%)

Propchange: activemq/activemq-dotnet/
------------------------------------------------------------------------------
bugtraq:url = https://issues.apache.org/activemq/browse/AMQNET-%BUGID%

Propchange: activemq/activemq-dotnet/
------------------------------------------------------------------------------
--- svn:ignore (added)
+++ svn:ignore Fri Sep 5 17:27:12 2008
@@ -0,0 +1 @@
+target

Propchange: activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk/
('bugtraq:label' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk/
('bugtraq:message' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk/
('bugtraq:url' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.ActiveMQ/trunk/
('svn:ignore' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.EMS/tags/1.0.0/
('bugtraq:label' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.EMS/tags/1.0.0/
('bugtraq:message' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.EMS/tags/1.0.0/
('bugtraq:url' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.EMS/tags/1.0.0/
('svn:ignore' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.EMS/trunk/
('bugtraq:label' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.EMS/trunk/
('bugtraq:message' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.EMS/trunk/
('bugtraq:url' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.EMS/trunk/
('svn:ignore' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.MSMQ/tags/1.0.0/
('bugtraq:label' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.MSMQ/tags/1.0.0/
('bugtraq:message' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.MSMQ/tags/1.0.0/
('bugtraq:url' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.MSMQ/tags/1.0.0/
('svn:ignore' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.MSMQ/trunk/
('bugtraq:label' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.MSMQ/trunk/
('bugtraq:message' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.MSMQ/trunk/
('bugtraq:url' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.MSMQ/trunk/
('svn:ignore' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS/tags/1.0.0/
('bugtraq:label' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS/tags/1.0.0/
('bugtraq:message' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS/tags/1.0.0/
('bugtraq:url' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS/tags/1.0.0/
('svn:ignore' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS/tags/1.0.0/src/main/csharp/Util/
('bugtraq:label' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS/trunk/
('bugtraq:label' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS/trunk/
('bugtraq:message' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS/trunk/
('bugtraq:url' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS/trunk/
('svn:ignore' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS/trunk/src/main/csharp/Util/
('bugtraq:label' removed)

From forum: ActiveMQ - Commits

svn commit: r692591 - in /activemq/activemq-dotnet/Apache.NMS.ActiveMQ/tags/1.0.0: ./ src/main/csharp/Connection.cs

2008-09-05T17:25:13Z

Author: jgomes
Date: Fri Sep 5 17:25:13 2008
New Revision: 692591

URL: http://svn.apache.org/viewvc?rev=692591&view=rev
Log:
Change default value for started to false.
Fixes [AMQNET-111]. (See https://issues.apache.org/activemq/browse/AMQNET-111)

Modified:
activemq/activemq-dotnet/Apache.NMS.ActiveMQ/tags/1.0.0/ (props changed)
activemq/activemq-dotnet/Apache.NMS.ActiveMQ/tags/1.0.0/src/main/csharp/Connection.cs

Propchange: activemq/activemq-dotnet/Apache.NMS.ActiveMQ/tags/1.0.0/
('bugtraq:label' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.ActiveMQ/tags/1.0.0/
('bugtraq:message' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.ActiveMQ/tags/1.0.0/
('bugtraq:url' removed)

Propchange: activemq/activemq-dotnet/Apache.NMS.ActiveMQ/tags/1.0.0/
('svn:ignore' removed)

Modified: activemq/activemq-dotnet/Apache.NMS.ActiveMQ/tags/1.0.0/src/main/csharp/Connection.cs
URL: http://svn.apache.org/viewvc/activemq/activemq-dotnet/Apache.NMS.ActiveMQ/tags/1.0.0/src/main/csharp/Connection.cs?rev=692591&r1=692590&r2=692591&view=diff
==============================================================================
--- activemq/activemq-dotnet/Apache.NMS.ActiveMQ/tags/1.0.0/src/main/csharp/Connection.cs (original)
+++ activemq/activemq-dotnet/Apache.NMS.ActiveMQ/tags/1.0.0/src/main/csharp/Connection.cs Fri Sep 5 17:25:13 2008
@@ -44,7 +44,7 @@
private long sessionCounter = 0;
private long temporaryDestinationCounter = 0;
private long localTransactionCounter;
- private readonly AtomicBoolean started = new AtomicBoolean(true);
+ private readonly AtomicBoolean started = new AtomicBoolean(false);
private bool disposed = false;

public Connection(Uri connectionUri, ITransport transport, ConnectionInfo info)

From forum: ActiveMQ - Commits

[jira] Commented: (AMQ-1849) Slave threads increasing when sending to temporary queue

2008-09-05T14:47:52Z

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

Hans Bausewein commented on AMQ-1849:
-------------------------------------

That's good news!

I'll test it, monday.

> Slave threads increasing when sending to temporary queue
> --------------------------------------------------------
>
> Key: AMQ-1849
> URL: https://issues.apache.org/activemq/browse/AMQ-1849
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.2.0
> Environment: Pure master/slave
> JBoss 4.0.5 GA (on Java 1.5.0_14)
> few days old ActiveMQ 5.2.0-SNAPSHOT (on Java "1.6.0_06")
> Reporter: Hans Bausewein
> Assignee: Gary Tully
> Fix For: 5.2.0
>
> Attachments: activemqjee-0.0.2-src.tar.gz, jboss.log
>
>
> Deployed the attached TextMDB (modified JBoss example) to our JBoss 4.0.5 GA server (cluster).
> - send a message to "queue.A" with Reply To set to "queue.REPLY_A"
> The TextMDB bean:
> - creates a temporary queue with NON_PERSISTENT delivery mode
> - forwards message body to "queue.B" and sets the reply queue to this temporary queue
> - another (or the same) instance of TextMDB replies and adds some text, replies to the temporary queue
> - the first TextMDB replies to "queue.REPLY_A"
> Works fine, except that every time a temporary queue message is sent, the number of threads on the slave increases by 3.
> On the master the threads are destroyed after a while, but on the slave they persist, growing to "OutOfMemoryError: unable to create new native thread"
> Temporary queue Thread Name example: TempQueue: ID:{HOSTNAME}-59619-1215591084487-0:16:5
> + 2 topic threads
> That thread ID can be found ActiveMQ messages in the attached JBoss log.
> Have I created a bug im my code or have I found a bug in the ActiveMQ server?

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

From forum: ActiveMQ - Dev

[jira] Resolved: (AMQ-1849) Slave threads increasing when sending to temporary queue

2008-09-05T13:53:52Z

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

Gary Tully resolved AMQ-1849.
-----------------------------

Fix Version/s: 5.2.0
Resolution: Fixed

temp queues are now cleaned up in the slave.

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

From forum: ActiveMQ - Dev

[jira] Reopened: (AMQ-1489) discoveryUri in transportConnector and uri in networkConnector partially ignored if multicast

2008-09-05T13:43:52Z

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

Gary Tully reopened AMQ-1489:
-----------------------------

bunch of unit test failures (14) with this fix, needs some investigation. eg BrokerServiceTest
java.net.UnknownHostException: group-1220646703756: group-1220646703756
at java.net.InetAddress.getAllByName0(InetAddress.java:1145)
at java.net.InetAddress.getAllByName(InetAddress.java:1072)
at java.net.InetAddress.getAllByName(InetAddress.java:1008)
at java.net.InetAddress.getByName(InetAddress.java:958)
at org.apache.activemq.transport.discovery.multicast.MulticastDiscoveryAgent.start(MulticastDiscoveryAgent.java:300)
at org.apache.activemq.network.DiscoveryNetworkConnector.handleStart(DiscoveryNetworkConnector.java:164)
at org.apache.activemq.network.NetworkConnector$1.doStart(NetworkConnector.java:56)
at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:53)
at org.apache.activemq.network.NetworkConnector.start(NetworkConnector.java:197)
at org.apache.activemq.broker.BrokerService.startAllConnectors(BrokerService.java:1873)
at org.apache.activemq.broker.BrokerService.start(BrokerService.java:480)
at org.apache.activemq.broker.BrokerServiceTest.testAddRemoveNetworkWithJMX(BrokerServiceTest.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

> discoveryUri in transportConnector and uri in networkConnector partially ignored if multicast
> ---------------------------------------------------------------------------------------------
>
> Key: AMQ-1489
> URL: https://issues.apache.org/activemq/browse/AMQ-1489
> Project: ActiveMQ
> Issue Type: Bug
> Components: Connector
> Affects Versions: 4.1.1, 5.0.0
> Reporter: Gerald Loeffler
> Assignee: Rob Davies
> Fix For: 5.2.0
>
> Attachments: patchfile.txt
>
>
> This bug relates to the MulticastDiscoveryAgent and was discovered when
> 1. the discoveryUri of a transportConnector is a multicast-uri such as
> {code:xml}
> <transportConnector uri="..." discoveryUri="multicast://239.3.7.0:37000" />
> {code}
> or
> 2. the uri of a networkConnector is a multicast-uri such as
> {code:xml}
> <networkConnector name="..." uri="multicast://239.3.7.0:37000">
> {code}
> In these cases, the uri is partially ignored by the MulticastDiscoveryAgent: the host-name of the uri (239.3.7.0) is extracted and used as the group name by the MulticastDiscoveryAgent. But the actual multicast group IP is always 239.255.2.3 and the multicast port is always 6155, regardless of what the actual uri is in the configuration.
> The reason for this is that MulticastDiscoveryAgentFactory creates a new MulticastDiscoveryAgent and sets the group based on the uri's host, but fails to set the discoveryURI itself. MulticastDiscoveryAgentFactory should be corrected to do this:
> {code:java}
> MulticastDiscoveryAgent rc = new MulticastDiscoveryAgent();
> rc.setDiscoveryURI(uri); // missing
> rc.setGroup(uri.getHost());
> {code}
> Without the above setting of the discoveryURI the MulticastDiscoveryAgent always uses the DEFAULT_DISCOVERY_URI_STRING which is "multicast://239.255.2.3:6155", explaining the erroneous behaviour described above.
> kind regards,
> gerald
> http://www.gerald-loeffler.net

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

From forum: ActiveMQ - Dev

svn commit: r692539 - in /activemq/trunk/activemq-core/src: main/java/org/apache/activemq/broker/ft/ main/java/org/apache/activemq/broker/region/ test/java/org/apache/activemq/advisory/

2008-09-05T13:40:14Z

Author: gtully
Date: Fri Sep 5 13:40:14 2008
New Revision: 692539

URL: http://svn.apache.org/viewvc?rev=692539&view=rev
Log:
fix for AMQ-1849 with test, also master slave pendingdispatch messages were being ignored, test shows this

Added:
activemq/trunk/activemq-core/src/test/java/org/apache/activemq/advisory/MasterSlaveTempQueueMemoryTest.java (with props)
Modified:
activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/ft/MasterBroker.java
activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/region/PrefetchSubscription.java

Modified: activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/ft/MasterBroker.java
URL: http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/ft/MasterBroker.java?rev=692539&r1=692538&r2=692539&view=diff
==============================================================================
--- activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/ft/MasterBroker.java (original)
+++ activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/ft/MasterBroker.java Fri Sep 5 13:40:14 2008
@@ -28,6 +28,7 @@
import org.apache.activemq.command.ConnectionControl;
import org.apache.activemq.command.ConnectionInfo;
import org.apache.activemq.command.ConsumerInfo;
+import org.apache.activemq.command.DestinationInfo;
import org.apache.activemq.command.ExceptionResponse;
import org.apache.activemq.command.Message;
import org.apache.activemq.command.MessageAck;
@@ -176,7 +177,7 @@
/**
* Removes a producer.
*
- * @param context the enviorment the operation is being executed under.
+ * @param context the environment the operation is being executed under.
* @param info
* @throws Exception
*/
@@ -190,7 +191,7 @@
*
* @param context
* @param info
- * @return the assocated subscription
+ * @return the associated subscription
* @throws Exception
*/
public Subscription addConsumer(ConnectionContext context, ConsumerInfo info) throws Exception {
@@ -211,6 +212,13 @@
sendAsyncToSlave(info);
}

+ public void removeDestinationInfo(ConnectionContext context, DestinationInfo info) throws Exception {
+ super.removeDestinationInfo(context, info);
+ if (info.getDestination().isTemporary()) {
+ sendAsyncToSlave(info);
+ }
+
+ }
/**
* begin a transaction
*

Modified: activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/region/PrefetchSubscription.java
URL: http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/region/PrefetchSubscription.java?rev=692539&r1=692538&r2=692539&view=diff
==============================================================================
--- activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/region/PrefetchSubscription.java (original)
+++ activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/region/PrefetchSubscription.java Fri Sep 5 13:40:14 2008
@@ -429,7 +429,7 @@
* @return
*/
public boolean isFull() {
- return isSlave() || dispatched.size() - prefetchExtension >= info.getPrefetchSize();
+ return dispatched.size() - prefetchExtension >= info.getPrefetchSize();
}

/**

Added: activemq/trunk/activemq-core/src/test/java/org/apache/activemq/advisory/MasterSlaveTempQueueMemoryTest.java
URL: http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/advisory/MasterSlaveTempQueueMemoryTest.java?rev=692539&view=auto
==============================================================================
--- activemq/trunk/activemq-core/src/test/java/org/apache/activemq/advisory/MasterSlaveTempQueueMemoryTest.java (added)
+++ activemq/trunk/activemq-core/src/test/java/org/apache/activemq/advisory/MasterSlaveTempQueueMemoryTest.java Fri Sep 5 13:40:14 2008
@@ -0,0 +1,68 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.activemq.advisory;
+
+import org.apache.activemq.broker.BrokerService;
+import org.apache.activemq.broker.region.RegionBroker;
+
+public class MasterSlaveTempQueueMemoryTest extends TempQueueMemoryTest {
+ String masterBindAddress = "tcp://localhost:61616";
+ String slaveBindAddress = "tcp://localhost:62616";
+ BrokerService slave;
+
+ /*
+ * add a slave broker
+ * @see org.apache.activemq.EmbeddedBrokerTestSupport#createBroker()
+ */
+ @Override
+ protected BrokerService createBroker() throws Exception {
+ // bindAddress is used by super.createBroker
+ bindAddress = masterBindAddress;
+ BrokerService master = super.createBroker();
+ master.setBrokerName("master");
+ bindAddress = slaveBindAddress;
+ slave = super.createBroker();
+ slave.setBrokerName("slave");
+ slave.setMasterConnectorURI(masterBindAddress);
+ bindAddress = masterBindAddress;
+ return master;
+ }
+
+ @Override
+ protected void startBroker() throws Exception {
+ super.startBroker();
+ slave.start();
+ }
+
+ @Override
+ public void testLoadRequestReply() throws Exception {
+ super.testLoadRequestReply();
+
+ // some checks on the slave
+ AdvisoryBroker ab = (AdvisoryBroker) slave.getBroker().getAdaptor(
+ AdvisoryBroker.class);
+
+ assertEquals("the temp queues should not be visible as they are removed", 1, ab.getAdvisoryDestinations().size());
+
+ RegionBroker rb = (RegionBroker) slave.getBroker().getAdaptor(
+ RegionBroker.class);
+
+ //serverDestination +
+ assertEquals(6, rb.getDestinationMap().size());
+ }
+
+}

Propchange: activemq/trunk/activemq-core/src/test/java/org/apache/activemq/advisory/MasterSlaveTempQueueMemoryTest.java
------------------------------------------------------------------------------
svn:eol-style = native

Propchange: activemq/trunk/activemq-core/src/test/java/org/apache/activemq/advisory/MasterSlaveTempQueueMemoryTest.java
------------------------------------------------------------------------------
svn:keywords = Rev Date

From forum: ActiveMQ - Commits

Discuss: strong naming of NMS assemblies

2008-09-05T13:12:09Z

I would like to get people's feedback on strong naming of the NMS
assemblies. I am working on releasing NMS 1.0, and this is now a
priority issue. I would like to hear some arguments for having strong
named assemblies, other than "Microsoft recommends it."

I think strong naming these assemblies causes more problems than any
potential benefits. I would like to turn off the strong naming, and
go with the standard weak naming.

Thoughts/arguments for/against?

From forum: ActiveMQ - User

Re: Scalability of 'Networks of Brokers'

2008-09-05T12:21:59Z

Sounds like a nightmare to me. Maybe I don't understand what you're trying
to accomplish, but I think something like Hadoop would be a better fit for
this kind of problem.

Bryan

On Fri, Sep 5, 2008 at 12:10 PM, Martin_Cornelius <
Martin.Cornelius@...> wrote:

>
> Hi all,
>
> i am currently evaluating the scalability of Networks of ActiveMQ Brokers
> with a large number of brokers. The actual drive behind this evaluation: I
> have to design a distributed system that is completely serverless. It shall
> be possible to switch of any of the machines in the system without alloying
> the distributed functionality. The number of active machines in the system
> might vary from only 2 to about 100.
>
> My current idea: Have an (presumably embedded) ActiveMQ Broker running on
> any of the machines, and let all this Brokers form a 'Network of Brokers'
> (abbreviated NOB in the follwing)
>
> So far, i found that in an NOB a message is forwarded only to those brokers
> where at least one client has subscribed to the topic resp. queue the
> message is sent to. Really fine. If a client subscribes to a queue, the
> broker where the subscription is made sends a single short control-message
> to all other brokers of the NOB. That would still allow for thousands of
> brokers, fine again.
>
> However, i just realized one fact that may compromise scalabilty: If a
> client subscribes to a topic, the broker where the subscription is done
> sends a not-so-short control-message to all other brokers. So far not too
> bad, but now comes the problem: Every broker seems to react on this
> control-message by sending another not-so-short control-message to all
> other
> brokers. This means, if N brokers are present, every subscription to a
> topic
> results in about (N-1)*N*2 control-messages (The additional factor two
> comes
> from the fact, that the final recipient-broker seems to send another
> response control-message). BTW, The length of the control-messages being
> sent seems to be closely related to the string length of the topic name.
>
> I have verified this behaviour with only up to 6 brokers, so i'm not
> totally
> shure if it will extrapolate to a larger number, but i suspect it does.
> This
> would mean, that with e.g. 100 Brokers every subscription to a topic would
> result in 100*99*2 control messages being sent. If a single control message
> has about 400 bytes (what i observed), this means a single subscription to
> a
> topic would result in about 8 Megabyte network traffic. This might even be
> sustainable, but the quadratic order kills scalabilty -- with 1000 Brokers
> we would have to transfer about 1 Gigabyte, what is no longer feasible.
>
> Finally, my questions: Is there any configuration option by which this
> quadratic order can be avoided, is my idea simply foolish, or are my
> conclusions wrong ? Note that i gained my conclusions more or less
> 'empirically' using wireshark.
>
> thanks for any advice, Martin
>
> --
> View this message in context:
> http://www.nabble.com/Scalability-of-%27Networks-of-Brokers%27-tp19335699p19335699.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

From forum: ActiveMQ - User

[jira] Created: (AMQNET-111) Constructor for Apache.NMS.ActiveMQ.Connection invokes transport.Start()

2008-09-05T12:07:52Z

Constructor for Apache.NMS.ActiveMQ.Connection invokes transport.Start()
------------------------------------------------------------------------

Key: AMQNET-111
URL: https://issues.apache.org/activemq/browse/AMQNET-111
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ Client
Reporter: Mark Keenan
Assignee: James Strachan
Priority: Minor

I have observed that messages are received on a connection before the connection is started.

Please see this Spring.NET forum post for details:

http://forum.springframework.net/showpost.php?p=13233&postcount=4

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

From forum: ActiveMQ - Dev

How do I implement a message timeout pattern?

2008-09-05T11:40:20Z

I will be sending a message to a queue that is to be consumed by a php
client. I then want to get a NEW status message created and sent to a
statusChannel with 5 minutes. If I do not get a new message in 5 minutes, I
want to take action.

---
Thank You…

Mick Knutson
BASE Logic, inc.
(415) 354-4215

Website: http://baselogic.com
Blog: http://baselogic.com/blog
BLiNC Magazine: http://blincmagazine.com
Linked IN: http://linkedin.com/in/mickknutson
DJ Mick: http://djmick.com
MySpace: http://myspace.com/mickknutson
Vacation Rental: http://tahoe.baselogic.com

From forum: ActiveMQ - User

Re: Scalability of 'Networks of Brokers'

2008-09-05T11:31:29Z

Instead of using such a potentially large network of 'embedded' brokers, could you use a smaller cluster of 'standalone' brokers? A single broker is capable of handling many clients and throwing in a master/slave configuration along with 'failover' connectors for the clients should provide the necessary high availability.

Joe
http://www.ttmsolutions.com

Martin_Cornelius wrote:

Hi all,

i am currently evaluating the scalability of Networks of ActiveMQ Brokers with a large number of brokers. The actual drive behind this evaluation: I have to design a distributed system that is completely serverless. It shall be possible to switch of any of the machines in the system without alloying the distributed functionality. The number of active machines in the system might vary from only 2 to about 100.
My current idea: Have an (presumably embedded) ActiveMQ Broker running on any of the machines, and let all this Brokers form a 'Network of Brokers' (abbreviated NOB in the follwing)

So far, i found that in an NOB a message is forwarded only to those brokers where at least one client has subscribed to the topic resp. queue the message is sent to. Really fine. If a client subscribes to a queue, the broker where the subscription is made sends a single short control-message to all other brokers of the NOB. That would still allow for thousands of brokers, fine again.

However, i just realized one fact that may compromise scalabilty: If a client subscribes to a topic, the broker where the subscription is done sends a not-so-short control-message to all other brokers. So far not too bad, but now comes the problem: Every broker seems to react on this control-message by sending another not-so-short control-message to all other brokers. This means, if N brokers are present, every subscription to a topic results in about (N-1)*N*2 control-messages (The additional factor two comes from the fact, that the final recipient-broker seems to send another response control-message). BTW, The length of the control-messages being sent seems to be closely related to the string length of the topic name.

I have verified this behaviour with only up to 6 brokers, so i'm not totally shure if it will extrapolate to a larger number, but i suspect it does. This would mean, that with e.g. 100 Brokers every subscription to a topic would result in 100*99*2 control messages being sent. If a single control message has about 400 bytes (what i observed), this means a single subscription to a topic would result in about 8 Megabyte network traffic. This might even be sustainable, but the quadratic order kills scalabilty -- with 1000 Brokers we would have to transfer about 1 Gigabyte, what is no longer feasible.

Finally, my questions: Is there any configuration option by which this quadratic order can be avoided, is my idea simply foolish, or are my conclusions wrong ? Note that i gained my conclusions more or less 'empirically' using wireshark.

thanks for any advice, Martin

From forum: ActiveMQ - User

[jira] Created: (CAMEL-880) Headers lost when using scriptBuilder to set headers dynamically

2008-09-05T11:23:52Z

Headers lost when using scriptBuilder to set headers dynamically
----------------------------------------------------------------

Key: CAMEL-880
URL: https://issues.apache.org/activemq/browse/CAMEL-880
Project: Apache Camel
Issue Type: Bug
Components: camel-script
Affects Versions: 1.4.0
Reporter: James Mello

When running a dynamic script evaluation in a setHeader, the header is lost as the Pipeline chain uses the data from the out body as the source of headers.

So trying to figure this out, I looked into the source, and found that if the getOut is not null, the out message is used to set the header in the setHeader processor. Unfortunately in the script engine this block of code always ensures that it's NOT null.

script builder class line 520 of Camel 1.4

ScriptContext context = engine.getContext();
int scope = ScriptContext.ENGINE_SCOPE;
context.setAttribute("context", exchange.getContext(), scope);
context.setAttribute("exchange", exchange, scope);
context.setAttribute("request", exchange.getIn(), scope);
context.setAttribute("response", exchange.getOut(), scope);

The place were the out message is used is here in the Pipeline class at line 79

if (first) {
first = false;
} else {
nextExchange = createNextExchange(processor, nextExchange);
}

The specifics of my setup were:

Used spring with the following configuration:

<camel:camelContext>
<camel:route>
<camel:from uri="jms://LLAQueue?disableReplyTo=true" />
<camel:setHeader headerName="activity.type">
<camel:jxpath>exchange.getIn().getBody().getExerciseHighLevelActivity().getActivityType()</camel:jxpath>
</camel:setHeader>
<camel:choice>
<camel:when>
<camel:javaScript>
exchange.getIn().getHeader('activity.type') == 3
</camel:javaScript>
<camel:transform>
<camel:javaScript>
exchange.getIn().getBody().getData() !=
undefined ?
exchange.getIn().getBody().getData() : ""
</camel:javaScript>
</camel:transform>
<camel:to uri="log:info?showAll=true" />
</camel:when>
</camel:choice>
</camel:route>
</camel:camelContext>

I did not test this problem with other exchange types, just the JMS type.

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

From forum: Camel - Development

RE: Potential bug with setHeader and scripts?

2008-09-05T11:23:00Z

I added the spring configuration to a JIRA, unfortunately I don't have time right now to dedicate to putting together a unit test. If you need further details though, please feel free to email.

Claus Ibsen wrote:

Hi

Yeah I guess the best is to look if the exchange is out capable (ExchangeHelper.isOutCapable - I think) and then only set the response context.

We would like to look and fix it. The best is to log a ticket in JIRA and if possible some code showing the problem, such as a route example, unit test or the like.

Med venlig hilsen

Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk

-----Original Message-----
From: Kingjamm [mailto:kingjamm@zoji.com]
Sent: 5. september 2008 19:17
To: camel-user@activemq.apache.org
Subject: Potential bug with setHeader and scripts?

So trying to figure this out, I looked into the source, and found that if the
getOut is not null, the out message is used to set the header in the
setHeader processor. Unfortunately in the script engine this block of code
always ensures that it's NOT null.

script builder class line 520 of Camel 1.4

ScriptContext context = engine.getContext();
int scope = ScriptContext.ENGINE_SCOPE;
context.setAttribute("context", exchange.getContext(), scope);
context.setAttribute("exchange", exchange, scope);
context.setAttribute("request", exchange.getIn(), scope);
context.setAttribute("response", exchange.getOut(), scope);

The place were the out message is used is here in the Pipeline class at line
79

if (first) {
first = false;
} else {
nextExchange = createNextExchange(processor, nextExchange);
}

Is the correct behavior to call the getOut in the scripbuilder with an
argument of false or is there something more subtle going on here?
--
View this message in context: http://www.nabble.com/Potential-bug-with-setHeader-and-scripts--tp19335805s22882p19335805.html
Sent from the Camel - Users mailing list archive at Nabble.com.

From forum: Camel - Users

Re: Configuring activemq queues

2008-09-05T11:19:37Z

I got it fixed. Thank you for the help!

James.Strachan wrote:

How many brokers do you want to run and why? The quick answer is -
just run one broker and make all the clients connect to it.

2008/9/4 Srkanth <mu.srikanth@gmail.com>:
>
> Hi,
> I have activemq installed on my machine and another developer's
> machine. The message producer is on another machine and the consumer is on
> my machine. So, the messages that are put by the producer are appearing on
> his console but not appearing in my queue. How do I configure activemq to
> use the queues on his local machine?
>
> Any help is appreciated
> --
> View this message in context: http://www.nabble.com/Configuring-activemq-queues-tp19321481p19321481.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com

From forum: ActiveMQ - User

Re: [VOTE] Release ActiveMQ-CPP 2.2.1

2008-09-05T11:07:41Z

On Fri, Sep 5, 2008 at 6:03 AM, Timothy Bish <tabish121@...> wrote:

> Hi everyone,
> Well its that time again, its time to call a vote for the release of
> ActiveMQ-CPP v2.2.1. This version has many bug fixes, performance
> enhancements, and some new features as well.
>
> The source bundle for the release candidate can be found here:
> http://people.apache.org/~tabish/activemq-cpp-2.2.1-RC2-src.tar.gz
>
> And here's the wiki page for the release:
> http://activemq.apache.org/cms/activemq-cpp-221-release.html
>
> Please cast your votes:
>
> [ ] +1 Release the source as Apache ActiveMQ-CPP 2.2.1
> [ ] -1 Veto the release (provide specific comments)

+1

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

Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/

Blog: http://bruceblog.org/

From forum: ActiveMQ - Dev