Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Wed, 2 Feb 2011 22:25:28 +0000 (UTC)
From: "Arthur Naseef (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: 
 <274970827.6090.1296685528951.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <4290097.257801296193063262.JavaMail.jira@thor>
Subject: [jira] Commented: (AMQ-3166) client calls to createProducer() and
 send() successful even though BrokerFilter methods throw exceptions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Arthur Naseef commented on AMQ-3166:
------------------------------------

Research found the following:
   - The exceptions are being sent over the transport from the broker to the client
   - Client handling does not propogate the exception back through send() or commit() calls

It appears this is caused by the producer using async sends.  Looking at ActiveMQSession:

            if (sendTimeout <= 0 && !msg.isResponseRequired() && !connection.isAlwaysSyncSend() &&
                (!msg.isPersistent() || connection.isUseAsyncSend() || txid != null)) {
                this.connection.asyncSendPacket(msg);

msg.isResponseRequire() defaults to false for most transport commands, including Message.  Taking advantage of the "isAlwaysSyncSend()" logic above, the following works-around the issue (when clients can be modified to use it):

                org.apache.activemq.ActiveMQConnectionFactory   conn_fact;
                ...
                conn_fact.setAlwaysSyncSend(true);

Attempts to use URI parameters, and searches through the code for URI parameters, have yielded no working solutions there.  If the connection URL could include a setting such as "?connection.alwaysSyncSend=true" would make this problem easier to solve since most clients use a configurable connection string.

However, with all of that said, it seems that transacted sends - as well as creating producers - should be synchronous.  That can be solved by taking out the "txid != null" logic.

For further performance improvement over transacted sends, if a client wants batch sending, which is not part of the JMS standard, it makes sense to require clients to use ActiveMQ-specific features.  Perhaps a batchSend() method followed by batchComplete().


> client calls to createProducer() and send() successful even though BrokerFilter methods throw exceptions
> --------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-3166
>                 URL: https://issues.apache.org/jira/browse/AMQ-3166
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker, JMS client
>    Affects Versions: 5.4.2
>            Reporter: Arthur Naseef
>
> Client calls to createProducer() always return without an error even though a BrokerFilter's addProducer() method throws an exception on the request. In contrast, createConsumer() throws an exception, as expected, when BrokerFilter's addConsumer() throws an exception.
> Clients using transacted sessions always return successfully from send() when a BrokerFilter's send() method throws an exception.
> Below is a broker configuration file using <authorizationPlugin> to illustrate the problem.
> To reproduce the problem With this configuration, a test client only needs to connect with user = "user" and password = "password", and then attempt to produce messages with a transacted session to any queue other than ABC (e.g. DEF).
> Tracing the cause of the issue has lead to finding that the client code for creating a producer uses an Async send for the producer information.  The analogous code for consumers uses a Sync send.
> I will work on a patch.  It would be very helpful to have feedback on the operation of the bus and the best way to resolve this problem.  Based on my research, it seems that createProducer() should be using a Sync send in place of the Async one.  Not yet sure about send().  Another possibility is to move the security operations to earlier in the internal broker flow.
> === SAMPLE BROKER XML ===
> <beans
>   xmlns="http://www.springframework.org/schema/beans"
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
>   http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd">
>     <broker xmlns="http://activemq.apache.org/schema/core"
>             brokerName="localhost"
>             dataDirectory="${activemq.base}/data"
>             destroyApplicationContextOnStop="true" >
>         <persistenceAdapter>
>             <kahaDB directory="${activemq.base}/data/kahadb"/>
>         </persistenceAdapter>
>         
>         <plugins>
>           <simpleAuthenticationPlugin anonymousAccessAllowed="true">
>               <users>
>                   <authenticationUser username="user" password="password"
>                       groups="users"/>
>               </users>
>           </simpleAuthenticationPlugin>
>           <authorizationPlugin>
>               <map>
>                   <authorizationMap>
>                     <authorizationEntries>
>                       <authorizationEntry queue="ABC" read="users" write="users" admin="users" />
>                       <authorizationEntry topic="ActiveMQ.Advisory.>" read="users" write="users" admin="users" />
>                     </authorizationEntries>
>                   </authorizationMap>
>               </map>
>           </authorizationPlugin>
>         </plugins>
>         <transportConnectors>
>             <transportConnector name="openwire" uri="tcp://0.0.0.0:61616"/>
>         </transportConnectors>
>     </broker>
> </beans>

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira