[
https://issues.apache.org/jira/browse/AMQ-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918453#comment-13918453
]
Arthur Naseef commented on AMQ-3166:
------------------------------------
If transacted-sends were always sent Synchronously from the client to the
broker, this problem would go away as the clients would immediately receive the
exception on the send. In that case, I wouldn't bother with marking the
transaction as failed since (a) there's really no need, and (b) the client
could easily decide to go forward and commit in spite of the single send
failure (i.e. more complex transacted use-cases would be supported).
My only concern with making that change is the potential impact to performance.
I'll give it a try and see how much impact it has.
> 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, 5.5.0
> Reporter: Arthur Naseef
> Assignee: Arthur Naseef
> Attachments: AMQ3166Test.java, AMQ3166Test.java,
> FailedTransactionTracking.java, FailedTransactionTrackingPlugin.java
>
>
> 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 was sent by Atlassian JIRA
(v6.2#6252)
