Picon
Favicon

[jira] [Created] (AMQ-3711) Credentials are not propagated correctly when passed through the ActiveMQConnectionFactory constructor in the CPP client API (However, it works correctly when passed through the createConnection method)

Credentials are not propagated correctly when passed through the ActiveMQConnectionFactory
constructor in the CPP client API (However, it works correctly when passed through the createConnection method)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: AMQ-3711
                 URL: https://issues.apache.org/jira/browse/AMQ-3711
             Project: ActiveMQ
          Issue Type: Bug
          Components: CMS (C++ client)
    Affects Versions: 5.5.1
         Environment: RHEL4 on both client and server 

I am using CMS v3.4.1
            Reporter: Bhooshan Mogal
            Priority: Minor

I tried to connect to the an ActiveMQ server using the C++ client API. However, when I pass the credentials
(username and password) only through the ActiveMQConnectionFactory  constructor and not through the
createConnection method, the password is not shows up as null in the server logs.
So,

 auto_ptr<ActiveMQConnectionFactory> connectionFactory(
                new ActiveMQConnectionFactory( brokerURI, "username", "password" ) );
            try{
                connection = connectionFactory->createConnection();
                connection->start();
            } catch( CMSException& e ) {
                e.printStackTrace();
                throw e;
            }
(Continue reading)

Picon
Favicon

[jira] [Created] (AMQ-3710) Activemq broker hangs

Activemq broker hangs
---------------------

                 Key: AMQ-3710
                 URL: https://issues.apache.org/jira/browse/AMQ-3710
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker
    Affects Versions: 5.4.2
         Environment: cent os linux version 5, 64 bit os, java 1.6 update 21
            Reporter: Krishnadasan T S
            Priority: Blocker

I am using activeMQ 5.4.2 as separate process in my production. more than 2000 topics and 600 clients are
connecting to broker. Heap size (Old generation) area is taking nearly 1 gb memory. Total memory
allocated to jvm is 2.5 gb.

  Activemq is getting hanged 2 or 3 time in a day. by monitoring in JMX console What we noticed is that at that
instance of time nearly 100 new threads are created and all these threads are NIO related threads. Once It
happened at the time of GC(we gave a perform gc from jmx for testing). It also happened at normal time also.

can you give any suggestion about what can be the issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Picon
Favicon

[jira] [Created] (AMQ-3709) Patch to fix invalid XHTML in web-console's 404 and 500 pages

Patch to fix invalid XHTML in web-console's 404 and 500 pages
-------------------------------------------------------------

                 Key: AMQ-3709
                 URL: https://issues.apache.org/jira/browse/AMQ-3709
             Project: ActiveMQ
          Issue Type: Bug
          Components: activemq-camel
         Environment: This is really N/A for this issue, but we are on Linux (RHEL6) VMs.
            Reporter: Adrian Michael Nida
         Attachments: activemq.patch

We created a monitor that utilizes calls to the web-console to determine stuck messages.  Occasionally,
requests come back 404 (because the message disappears between calls) and the monitor dies because the
XHTML for that page is invalid.  This patch makes the 404 and 500 pages valid in the eyes of the w3c markup
validation service.

Note: I'm placing the patch here because I do not see a place to upload it on this form.  If it appears later, I
will attached.

Index: activemq-web-console/src/main/webapp/500.html
===================================================================
--- activemq-web-console/src/main/webapp/500.html	(revision 1242141)
+++ activemq-web-console/src/main/webapp/500.html	(working copy)
@@ -22,8 +22,7 @@

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 

-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
(Continue reading)

Picon
Favicon

[jira] [Created] (AMQ-3708) Run-time Setting of Destination Prefix

Run-time Setting of Destination Prefix
--------------------------------------

                 Key: AMQ-3708
                 URL: https://issues.apache.org/jira/browse/AMQ-3708
             Project: ActiveMQ
          Issue Type: Improvement
          Components: CMS (C++ client)
    Affects Versions: 5.5.1
         Environment: All
            Reporter: Mark Rappoport
            Priority: Minor
             Fix For: NEEDS_REVIEWED

Some STOMP-aware message brokers (such as HornetQ) want their destinations prefixed in a manner
different from "/queue/" or "/topic/". HornetQ, for example, wants it to be "jms.queue." or "jms.topic.".

To address this, I've made some changes to StompHelper, adding the following URI parameters:

* wireFormat.queuePrefix - defaults to "/queue/"
* wireFormat.topicPrefix - defaults to "/topic/"
* wireFormat.tempQueuePrefix - defaults to "/temp-queue/"
* wireFormat.tempTopicPrefix - defaults to "/temp-topic/"

My patch, however, fails to utilize the framework laid out by the StompWireformatProperties class, as the
current code structure makes it very hard. Regardless, I've tested it with the SimpleProducer example
(make sure you provide guest/guest as auth params if you're running a vanilla HornetQ) and it seems to work fine.

The patch is against the activemq-cpp-3.4.1 tag as trunk wouldn't compile; some formatting issues may be
present as well.
(Continue reading)

Picon
Favicon

[jira] [Created] (AMQ-3707) Dynamic Failover Client Connection Params Broker Side Attribute

Dynamic Failover Client Connection Params Broker Side Attribute
---------------------------------------------------------------

                 Key: AMQ-3707
                 URL: https://issues.apache.org/jira/browse/AMQ-3707
             Project: ActiveMQ
          Issue Type: New Feature
          Components: Broker
            Reporter: Scott England-Sullivan
             Fix For: 5.6.0

Given that dynamic failover allows for the addition and removal of brokers from a list of available
connections at the client, I would suggest that an attribute be made available on the broker to define what
connection options a client should use when connecting to a given broker.

Therefore a client with the following list of connections:

Client connect string
* failover://(tcp://somebrokerA:61616,tcp://somebrokerB:61616)

And a broker with the following
* (NEW) *clusterClientsConnectionParams="useCompression=true"*

Would result in a client with the following connection list:
* tcp://somebrokerA:61616?clusterClientsConnectionParams="useCompression=true"
* tcp://somebrokerB:61616?clusterClientsConnectionParams="useCompression=true"

And should a new broker be added to the cluster (if this option was set on each broker):
* tcp://somebrokerA:61616?clusterClientsConnectionParams="useCompression=true"
* tcp://somebrokerB:61616?clusterClientsConnectionParams="useCompression=true"
(Continue reading)

io42 | 8 Feb 18:32
Favicon

Supressing PostgreSQL exceptions for creating tables when tables already exist

I have a postgres data store working that persists ActiveMQ messages, but
every time that I run my system (which starts up an embedded broker) I get a
lot of long exception messages asserting that my JDBC tables could not be
created because they could already exist.  Is there any way to suppress
these exception details from showing up in the logging?  This issue already
appears to have been previously identified
(https://issues.apache.org/jira/browse/AMQ-3189), but I have yet to discover
if anyone has come up with a solution or workaround.  Below is some of the
sample output I keeps seeing.

Example output:

08 Feb 2012 11:22:13 - Could not create JDBC tables; they could already
exist. Failure was: CREATE TABLE ACTIVEMQ_MSGS(ID BIGINT NOT NULL, CONTAINER
VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ BIGINT, EXPIRATION BIGINT,
MSG BYTEA, PRIMARY KEY ( ID ) ) Message: ERROR: relation "activemq_msgs"
already exists SQLState: 42P07 Vendor code: 0
08 Feb 2012 11:22:13 - Failure details: ERROR: relation "activemq_msgs"
already exists
org.postgresql.util.PSQLException: ERROR: relation "activemq_msgs" already
exists
08 Feb 2012 11:22:13 - Failure details: ERROR: current transaction is
aborted, commands ignored until end of transaction block
org.postgresql.util.PSQLException: ERROR: current transaction is aborted,
commands ignored until end of transaction block
        at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2102)
        at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1835)
        at
(Continue reading)

Picon
Favicon

[jira] [Created] (AMQ-3706) Dynamic Failover Randomize is Not Evenly Balanced

Dynamic Failover Randomize is Not Evenly Balanced
-------------------------------------------------

                 Key: AMQ-3706
                 URL: https://issues.apache.org/jira/browse/AMQ-3706
             Project: ActiveMQ
          Issue Type: Sub-task
          Components: Broker
    Affects Versions: 5.5.0
            Reporter: Scott England-Sullivan
             Fix For: 5.6.0

When using dynamic failover with randomize enabled, clients are not consistently rebalanced in an even
manner.  A test case is added that allows a minimum of 25% per broker on a three broker test and 40%
distribution on a 2 broker test.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Picon
Gravatar

Build failed in Jenkins: ActiveMQ #876

See <https://builds.apache.org/job/ActiveMQ/876/changes>

Changes:

[tabish] fix and test for: https://issues.apache.org/jira/browse/AMQ-3705

------------------------------------------
[...truncated 15095
lines...]
<https://builds.apache.org/job/ActiveMQ/ws/activemq-optional/src/main/java/org/apache/activemq/transport/http/HttpTunnelServlet.java>:[166,85]
cannot find symbol
symbol  : class HttpServletResponse
location: class
org.apache.activemq.transport.http.HttpTunnelServlet
<https://builds.apache.org/job/ActiveMQ/ws/activemq-optional/src/main/java/org/apache/activemq/transport/http/HttpTunnelServlet.java>:[181,60]
cannot find symbol
symbol  : class HttpServletRequest
location: class
org.apache.activemq.transport.http.HttpTunnelServlet
<https://builds.apache.org/job/ActiveMQ/ws/activemq-optional/src/main/java/org/apache/activemq/transport/http/HttpTunnelServlet.java>:[181,88]
cannot find symbol
symbol  : class HttpServletResponse
location: class
org.apache.activemq.transport.http.HttpTunnelServlet
<https://builds.apache.org/job/ActiveMQ/ws/activemq-optional/src/main/java/org/apache/activemq/transport/ws/StompServlet.java>:[22,20]
package javax.servlet does not
exist
<https://builds.apache.org/job/ActiveMQ/ws/activemq-optional/src/main/java/org/apache/activemq/transport/ws/StompServlet.java>:[23,25]
package javax.servlet.http does not
exist
(Continue reading)

Picon
Favicon

[jira] [Created] (AMQ-3705) When a Destination is removed all the Advisory Topics for that destination should be removed also

When a Destination is removed all the Advisory Topics for that destination should be removed also
-------------------------------------------------------------------------------------------------

                 Key: AMQ-3705
                 URL: https://issues.apache.org/jira/browse/AMQ-3705
             Project: ActiveMQ
          Issue Type: Improvement
          Components: Broker
    Affects Versions: 5.5.1
            Reporter: Timothy Bish
            Assignee: Timothy Bish
            Priority: Minor
             Fix For: 5.6.0

Currently when a destination is removed the only two Destination specific advisory destination that are
removed are the Consumer and Producer advisory topics, if any of the other advisories are enabled and an
advisory destination created we don't clean those up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Picon
Favicon

[jira] [Created] (AMQNET-369) Seems like there is a race condition that can lead to an InvalidDestinationException for tempoary queues after failover has resumed

Seems like there is a race condition that can lead to an InvalidDestinationException for tempoary queues
after failover has resumed
-----------------------------------------------------------------------------------------------------------------------------------

                 Key: AMQNET-369
                 URL: https://issues.apache.org/jira/browse/AMQNET-369
             Project: ActiveMQ .Net
          Issue Type: Bug
    Affects Versions: 1.5.3
            Reporter: Frank Gynnild
            Assignee: Jim Gomes

If I repeat the test below I sometimes get a:
Apache.NMS.InvalidDestinationException: Cannot publish to a deleted Destination: temp-queue://ID:Duracell-61594-634642411329432145-1:0:1

Test:
1. Start Message bus
2. Start server code.
3. Stop Message bus
4. Start Message bus
5. Start client code.

The client/server uses the request/response pattern.

I don't have a unit test since it doesn't happen all the time. But if happens often enough that I am sure there
is a race condition bug here
somewhere. And I think it's in NMS since I can see these log lines:

AdvisoryConsumer adding: temp-queue://ID:Duracell-61594-634642411329432145-1:0:1

(Continue reading)

Hiram Chirino | 7 Feb 15:54
Picon
Gravatar

Re: Apollo's scalability

Hi Connie,

On Mon, Feb 6, 2012 at 7:07 PM, Connie Yang <cyberconnie@...> wrote:

> Hello Hiram,
>
> Scalability in a cluster is important to us and I'm trying to get a good
> understanding of it in Apollo...
>
> In this InfoQ article, http://www.infoq.com/news/2011/12/apollo-benchmarks,
> you mentioned the use of ZK to partition destinations across the cluster
> and hide the partitioning by rerouting messaging operations to the correct
> partitions in the upcoming version of Apollo.
>
>    - Is this work in flight?  If yes, when will this be available?
>
>
It complicated, but should work.  It still highly experimental but now that
the core broker has been released and is stable, I should be able to
dedicate more time to working on this problem.  Perhaps by the end of the
year we will have something folks can start trying out.

>
>    - With the ZK and re-routing approach, is forwarding necessary?
>
>
Well, if the clients are smart enough to talk to ZK to figure out which
broker they should be operating against, this would be the
most efficient option, but I'm going to assume that they are not that
smart.  Another way to look at it is, if you want your client machines to
(Continue reading)


Gmane