[
https://issues.apache.org/jira/browse/APEXMALHAR-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15985831#comment-15985831
]
ASF GitHub Bot commented on APEXMALHAR-2434:
--------------------------------------------
GitHub user oliverwnk opened a pull request:
https://github.com/apache/apex-malhar/pull/612
APEXMALHAR-2434 Fix JMSTransactionableStore by using deterministic qu…
…eueName + messageSelector
@sanjaypujare please review
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/oliverwnk/apex-malhar
APEXMALHAR-2434.FixJMSTransactionableStore
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/apex-malhar/pull/612.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #612
----
commit e5942b6f05cfd981aa0ed8b4c03096e25f6f9c63
Author: Oliver Winke <oli...@datatorrent.com>
Date: 2017-04-27T01:06:48Z
APEXMALHAR-2434 Fix JMSTransactionableStore by using deterministic
queueName + messageSelector
----
> JMSTransactionableStore uses Session.createQueue() which fails
> --------------------------------------------------------------
>
> Key: APEXMALHAR-2434
> URL: https://issues.apache.org/jira/browse/APEXMALHAR-2434
> Project: Apache Apex Malhar
> Issue Type: Bug
> Reporter: Sanjay M Pujare
>
> JMSTransactionableStore needs to create a queue for storing metadata
> (lastWindowId etc) that will work across invocations to support fault
> tolerance and idempotency.
> However as the createQueue Javadocs says: "Note that this method is not for
> creating the physical queue. The physical creation of queues is an
> administrative task and is not to be initiated by the JMS API." This causes a
> failure in actual tests with a production JMS based broker (such as IBM
> MQSeries). We will need to fix this in one of the following ways:
> - using an alternative store (HDFS or JDBC)
> - allow the user to specify a name for this metadata queue via a property
> - generate the name in a deterministic fashion from the subject of the queue
> The last 2 alternatives assume that the application user has created this
> metadata queue ahead of time from the admin console. We will need to document
> this in the malhar docs. The last alternative looks most attractive except if
> there are multiple JMS output operators (say partitions of an operator)
> writing to the same queue (subject) we will have to use some additional logic
> for them to share this single metadata queue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
