[
https://issues.apache.org/jira/browse/NIFI-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493975#comment-15493975
]
Oleg Zhurakousky edited comment on NIFI-2774 at 9/15/16 5:12 PM:
-----------------------------------------------------------------
Ok, will make it configurable.
However there are few caveats to keep in mind;
While Session defines 4 different QoS modes, one is related to transactions
(_SESSION_TRANSACTED_) which itself brings a whole other level of JMS
integration (i.e., transaction managers, XA etc).
Also, given that this new JMS support oriented to be portable across multiple
providers, JMS specifications allows for custom QoS modes while implementing
Session. This means that aside from the 4 defined by JMS specification there
may be other once specific to providers. It is just an integer value known to
Session implementation.
So, for now I advocate for excluding the support for _SESSION_TRANSACTED_ since
it is primarily designed for integrating with third party transaction managers
while from the QoS perspective pertaining to this particular issue would
accomplish the same as _CLIENT_ACKNOWLEDGE_.
Given that QoS value used is just an integer and to support provider specific
QoS the new configuration field will be of Integer type defaulting to 2
(_CLIENT_ACKNOWLEDGE_), thus allowing provider specific QoS values be used.
However, since we don't know if those custom QoS modes will require additional
configuration options I am somewhat reluctant to do even that, which means IMHO
the best we can do at he moment is expose *only* 3 QoS modes defined by JMS
spec - _CLIENT_ACKNOWLEDGE - default, AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE_.
was (Author: ozhurakousky):
Ok, will make it configurable.
However there are few caveats to keep in mind;
While Session defines 4 different QoS modes, one is related to transactions
(_SESSION_TRANSACTED_) which itself brings a whole other level of JMS
integration (i.e., transaction managers, XA etc).
Also, given that this new JMS support oriented to be portable across multiple
providers, JMS specifications allows for custom QoS modes while implementing
Session. This means that aside from the 4 defined by JMS specification there
may be other once specific to providers. It is just an integer value known to
Session implementation.
So, for now I advocate for excluding the support for _SESSION_TRANSACTED_ since
it is primarily designed for integrating with third party transaction managers
while from the QoS perspective pertaining to this particular issue would
accomplish the same as _CLIENT_ACKNOWLEDGE_.
Given that QoS value used is just an integer and to support provider specific
QoS the new configuration field will be of Integer type defaulting to 2
(_CLIENT_ACKNOWLEDGE_), thus allowing provider specific QoS values be used.
However, since we don't know if those custom QoS modes will require additional
configuration options I am somewhat reluctant to do even that, which means IMHO
the best we can do at he moment is expose *only* 3 QoS modes defined by JMS
spec - _CLIENT_ACKNOWLEDGE - default, AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE.
> ConsumeJMS processor losses messages on NiFi restart
> ----------------------------------------------------
>
> Key: NIFI-2774
> URL: https://issues.apache.org/jira/browse/NIFI-2774
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 1.0.0, 0.7.0
> Reporter: Christopher McDermott
> Assignee: Oleg Zhurakousky
> Priority: Critical
> Fix For: 1.1.0, 0.8.0
>
> Attachments: 2774.patch
>
>
> ConsumeJMS processor uses auto-acknowledge mode. Unlike the deprecated
> GetJMSQueue processor it does not provide a way to specify a different ACK
> mode (i.e. client-acknowledge.) Using auto-acknowledge, acknowledges message
> receipt from JMS *before* the messages are actually added to the flow. This
> leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in
> the processor configuration like is allowed by the GetJMSQueue processor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
