apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (APEXMALHAR-2434) JMSTransactionableStore uses Session.createQueue() which fails
Date Thu, 27 Apr 2017 01:09:04 GMT

    [ 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:


    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:


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 <oliver@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

View raw message