[jira] [Commented] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171035#comment-16171035 ] Y Wikander commented on NIFI-4169: -- [~ijokarumawak], # I did not take offense to the squash. # I checked that my name and email address are valid in the commit message. > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Assignee: Y Wikander > Labels: patch > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch, > 0002-websocket-PutWebSocket-enhance-broadcast-support.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169452#comment-16169452 ] Y Wikander commented on NIFI-4169: -- [~ijokarumawak]. I tested it. Yes, it covers the use case I was interested in. > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Assignee: Y Wikander > Labels: patch > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch, > 0002-websocket-PutWebSocket-enhance-broadcast-support.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[
https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Y Wikander updated NIFI-4169:
-
Comment: was deleted
(was: Patch submittal for this issue:
[^0002-websocket-PutWebSocket-enhance-broadcast-support.patch]
Suggested checkin note:
{noformat}
PutWebsocket; enhance broadcast support
- Add relationship 'session unknown'.
Allows flowfiles where the session is no longer valid to be
dropped vs. needing to analyze the attributes of a
'failure' relationship.
Note: Available for use by non-broadcast flowfiles.
- Change broadcast success behavior; such that if a flowfile
cannot be sent to any destination the flowfile
will transfer to relationship 'failure'.
- Change broadcast failure behavior; such that if a flowfile
can be sent to at least one destination the flowfile will
transfer to relationship 'success'.
For each failed broadcast destination, a new flowfile is
cloned (via a fowfile FORK) with a relationship of
'failure' (so that it can be routed back into the
processor).
Note that on later 'success' or 'session unknown' results, the
flowfile is dropped (via a terminate relationship) because
sending it on would cause a duplicate (since we're a clone).
- Add attribute 'websocket.broadcast' which is used to track
failed broadcast flowfiles when they are reprocessed by this
processor.
- Change attribute websocket.local.address and
websocket.remote.address values under broadcast success
condition; to contain a comma separated list of addresses
when the flowfile was successfully sent.
- Update documentation with information on how to use
broadcast functionality.
{noformat}
)
> PutWebSocket processor with blank WebSocket session id attribute cannot
> transfer to failure queue
> -
>
> Key: NIFI-4169
> URL: https://issues.apache.org/jira/browse/NIFI-4169
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Y Wikander
>Priority: Critical
> Labels: patch
> Fix For: 1.3.0
>
> Attachments:
> 0001-websocket-when-sendMessage-fails-under-blank-session.patch,
> 0002-websocket-PutWebSocket-enhance-broadcast-support.patch
>
>
> If a PutWebSocket processor is setup with a blank WebSocket session id
> attribute (see NIFI-3318; Send message from PutWebSocket to all connected
> clients) and it is not connected to a websocket server it will log the
> failure and mark the flowfile with Success (rather than Failure) -- and the
> data is effectively lost.
> If there are multiple connected clients, and some succeed and others fail,
> routing Failure back into the PutWebSocket could result in duplicate data to
> some clients.
> Other NiFi processors seem to err on the side of "at least once".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Y Wikander updated NIFI-4169: - Fix Version/s: 1.3.0 Status: Patch Available (was: Open) Patch submittal for this issue: [^0002-websocket-PutWebSocket-enhance-broadcast-support.patch] > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Fix For: 1.3.0 > > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch, > 0002-websocket-PutWebSocket-enhance-broadcast-support.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[
https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16134648#comment-16134648
]
Y Wikander edited comment on NIFI-4169 at 8/21/17 2:43 AM:
---
Patch submittal for this issue:
[^0002-websocket-PutWebSocket-enhance-broadcast-support.patch]
Suggested checkin note:
{noformat}
PutWebsocket; enhance broadcast support
- Add relationship 'session unknown'.
Allows flowfiles where the session is no longer valid to be
dropped vs. needing to analyze the attributes of a
'failure' relationship.
Note: Available for use by non-broadcast flowfiles.
- Change broadcast success behavior; such that if a flowfile
cannot be sent to any destination the flowfile
will transfer to relationship 'failure'.
- Change broadcast failure behavior; such that if a flowfile
can be sent to at least one destination the flowfile will
transfer to relationship 'success'.
For each failed broadcast destination, a new flowfile is
cloned (via a fowfile FORK) with a relationship of
'failure' (so that it can be routed back into the
processor).
Note that on later 'success' or 'session unknown' results, the
flowfile is dropped (via a terminate relationship) because
sending it on would cause a duplicate (since we're a clone).
- Add attribute 'websocket.broadcast' which is used to track
failed broadcast flowfiles when they are reprocessed by this
processor.
- Change attribute websocket.local.address and
websocket.remote.address values under broadcast success
condition; to contain a comma separated list of addresses
when the flowfile was successfully sent.
- Update documentation with information on how to use
broadcast functionality.
{noformat}
was (Author: ywik):
Patch submittal for this issue:
[^0002-websocket-PutWebSocket-enhance-broadcast-support.patch]
> PutWebSocket processor with blank WebSocket session id attribute cannot
> transfer to failure queue
> -
>
> Key: NIFI-4169
> URL: https://issues.apache.org/jira/browse/NIFI-4169
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Y Wikander
>Priority: Critical
> Labels: patch
> Fix For: 1.3.0
>
> Attachments:
> 0001-websocket-when-sendMessage-fails-under-blank-session.patch,
> 0002-websocket-PutWebSocket-enhance-broadcast-support.patch
>
>
> If a PutWebSocket processor is setup with a blank WebSocket session id
> attribute (see NIFI-3318; Send message from PutWebSocket to all connected
> clients) and it is not connected to a websocket server it will log the
> failure and mark the flowfile with Success (rather than Failure) -- and the
> data is effectively lost.
> If there are multiple connected clients, and some succeed and others fail,
> routing Failure back into the PutWebSocket could result in duplicate data to
> some clients.
> Other NiFi processors seem to err on the side of "at least once".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[
https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Y Wikander updated NIFI-4169:
-
Attachment: 0002-websocket-PutWebSocket-enhance-broadcast-support.patch
Patch submittal for this issue:
[^0002-websocket-PutWebSocket-enhance-broadcast-support.patch]
Suggested checkin note:
{noformat}
PutWebsocket; enhance broadcast support
- Add relationship 'session unknown'.
Allows flowfiles where the session is no longer valid to be
dropped vs. needing to analyze the attributes of a
'failure' relationship.
Note: Available for use by non-broadcast flowfiles.
- Change broadcast success behavior; such that if a flowfile
cannot be sent to any destination the flowfile
will transfer to relationship 'failure'.
- Change broadcast failure behavior; such that if a flowfile
can be sent to at least one destination the flowfile will
transfer to relationship 'success'.
For each failed broadcast destination, a new flowfile is
cloned (via a fowfile FORK) with a relationship of
'failure' (so that it can be routed back into the
processor).
Note that on later 'success' or 'session unknown' results, the
flowfile is dropped (via a terminate relationship) because
sending it on would cause a duplicate (since we're a clone).
- Add attribute 'websocket.broadcast' which is used to track
failed broadcast flowfiles when they are reprocessed by this
processor.
- Change attribute websocket.local.address and
websocket.remote.address values under broadcast success
condition; to contain a comma separated list of addresses
when the flowfile was successfully sent.
- Update documentation with information on how to use
broadcast functionality.
{noformat}
> PutWebSocket processor with blank WebSocket session id attribute cannot
> transfer to failure queue
> -
>
> Key: NIFI-4169
> URL: https://issues.apache.org/jira/browse/NIFI-4169
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Y Wikander
>Priority: Critical
> Labels: patch
> Attachments:
> 0001-websocket-when-sendMessage-fails-under-blank-session.patch,
> 0002-websocket-PutWebSocket-enhance-broadcast-support.patch
>
>
> If a PutWebSocket processor is setup with a blank WebSocket session id
> attribute (see NIFI-3318; Send message from PutWebSocket to all connected
> clients) and it is not connected to a websocket server it will log the
> failure and mark the flowfile with Success (rather than Failure) -- and the
> data is effectively lost.
> If there are multiple connected clients, and some succeed and others fail,
> routing Failure back into the PutWebSocket could result in duplicate data to
> some clients.
> Other NiFi processors seem to err on the side of "at least once".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16102702#comment-16102702 ] Y Wikander commented on NIFI-4169: -- [~ijokarumawak], I found adding getSessionIds() to class WebSocketMessageRouter to be a simpler approach than creating a sendBroadcastMessage(). I moved broadcasting support into PutWebSocket (and pulled it out of WebSocketMessageRouter.sendMessage). Documentation changes and Unit Tests remain. PutWebSocket documentation on how to use broadcasting, let alone that there were two different types, is lacking. I'll try to rectify that. > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (NIFI-4170) PutWebSocket processor does not support 'Penalty duration'' setting
[ https://issues.apache.org/jira/browse/NIFI-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Y Wikander updated NIFI-4170: - Fix Version/s: 1.3.0 Status: Patch Available (was: Open) Patch submittal for this issue. See [^0001-websocket-PutWebSocket-processor-support-Penalty-dur.patch] > PutWebSocket processor does not support 'Penalty duration'' setting > --- > > Key: NIFI-4170 > URL: https://issues.apache.org/jira/browse/NIFI-4170 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Minor > Labels: patch > Fix For: 1.3.0 > > Attachments: > 0001-websocket-PutWebSocket-processor-support-Penalty-dur.patch, > 0002-websocket-PutWebSocket-processor-support-Penalty-dur.patch > > > PutWebSocket processor does not support 'Penalty duration' setting. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (NIFI-4170) PutWebSocket processor does not support 'Penalty duration' and 'Yield duration' settings
[ https://issues.apache.org/jira/browse/NIFI-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Y Wikander updated NIFI-4170: - Description: PutWebSocket processor does not support 'Penalty duration' setting. (was: PutWebSocket processor does not support 'Penalty duration' and 'Yield duration' settings. I'm assuming that calling content.yield() will also cover 'Penalty duration'.) > PutWebSocket processor does not support 'Penalty duration' and 'Yield > duration' settings > > > Key: NIFI-4170 > URL: https://issues.apache.org/jira/browse/NIFI-4170 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Minor > Labels: patch > Attachments: > 0001-websocket-PutWebSocket-processor-support-Penalty-dur.patch, > 0002-websocket-PutWebSocket-processor-support-Penalty-dur.patch > > > PutWebSocket processor does not support 'Penalty duration' setting. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (NIFI-4170) PutWebSocket processor does not support 'Penalty duration'' setting
[ https://issues.apache.org/jira/browse/NIFI-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Y Wikander updated NIFI-4170: - Summary: PutWebSocket processor does not support 'Penalty duration'' setting (was: PutWebSocket processor does not support 'Penalty duration' and 'Yield duration' settings) > PutWebSocket processor does not support 'Penalty duration'' setting > --- > > Key: NIFI-4170 > URL: https://issues.apache.org/jira/browse/NIFI-4170 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Minor > Labels: patch > Attachments: > 0001-websocket-PutWebSocket-processor-support-Penalty-dur.patch, > 0002-websocket-PutWebSocket-processor-support-Penalty-dur.patch > > > PutWebSocket processor does not support 'Penalty duration' setting. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16091078#comment-16091078 ] Y Wikander commented on NIFI-4169: -- [~ijokarumawak], regarding your [comment|https://issues.apache.org/jira/browse/NIFI-4169?focusedCommentId=16087053=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16087053]. I think that adding a sendBroadcastMessage() function to WebSocketMessageRouter and removing broadcast support from sendMessage() (in the same class) would work better. sendBroadcastMessage() would return a list that PutWebSocket class would use find out the session id, Exception, etc. -- for each failed session id. This would allow the PutWebSocket class to make better informed decisions about cloning the flowfile, what attributes to set (and with what). It seems to me that just changing the PutWebSocket class, as you suggested, would be hiding to much information from itself. > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16091061#comment-16091061 ] Y Wikander commented on NIFI-4169: -- [~ijokarumawak], [your|https://issues.apache.org/jira/browse/NIFI-4169?focusedCommentId=16087053=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16087053] suggestion. > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Y Wikander updated NIFI-4169: - Comment: was deleted (was: [~ijokarumawak], [your|https://issues.apache.org/jira/browse/NIFI-4169?focusedCommentId=16087053=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16087053] suggestion. ) > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (NIFI-4170) PutWebSocket processor does not support 'Penalty duration' and 'Yield duration' settings
[ https://issues.apache.org/jira/browse/NIFI-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Y Wikander updated NIFI-4170: - Attachment: 0001-websocket-PutWebSocket-processor-support-Penalty-dur.patch See attached patch [^0001-websocket-PutWebSocket-processor-support-Penalty-dur.patch]. I never found a reason to yield the Processor, only penalize the flowfile. Each flowfile drives which path the Processor is to take. Therefor, there's never a reason to yield - because you don't know (at the time) if the flowfile behind the one being processed is going to the same place, such that it will probably incur the same config error. Looks like the title of the Issue needs "Yield" removed. > PutWebSocket processor does not support 'Penalty duration' and 'Yield > duration' settings > > > Key: NIFI-4170 > URL: https://issues.apache.org/jira/browse/NIFI-4170 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Minor > Labels: patch > Attachments: > 0001-websocket-PutWebSocket-processor-support-Penalty-dur.patch, > 0002-websocket-PutWebSocket-processor-support-Penalty-dur.patch > > > PutWebSocket processor does not support 'Penalty duration' and 'Yield > duration' settings. > I'm assuming that calling content.yield() will also cover 'Penalty duration'. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16088077#comment-16088077 ] Y Wikander commented on NIFI-4169: -- After reviewing [this|https://issues.apache.org/jira/browse/NIFI-4169?focusedCommentId=16083331=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16083331] and [this|https://issues.apache.org/jira/browse/NIFI-4169?focusedCommentId=16083547=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16083547] comment, here's my current thoughts... PutWebSocket needs to support the following types of inbound flowfiles: # ListenWebSocket, non-broadcast (has websocket.session.id attribute) # ListenWebSocket, broadcast (no websocket.session.id attribute); broadcast list can be more than 1 # ConnectWebSocket, broadcast (no websocket.session.id attribute); broadcast will be up to 1 # 1 and ( 2 or 3 ) I think that only #3 - the one I'm interested in - is the one that cannot afford data loss (because NiFi is the source of the data). The theory is, that since the others asked for the data, they are expecting it. So if they don't get it they will ask for it again. #3 can't afford data loss because the endpoint is being pushed to. To accomplish that, consider the following logic: - if no websocket.session.id attribute -- Transfer the incoming FlowFile to success if it's sent to at least one target. -- Transfer the incoming FlowFile to failure if it's not send to any target. -- Continue looping through sessions even if one throws Exception -- Catch Exception while in the loop, then generate (e.g. clone) FlowFile to send to 'failure' relationship. Embed failed websocket session id to 'websocket.session.id' FlowFile attribute. Also add attribute 'websocket.broadcast'. - else -- Try to transfer the incoming FlowFile --- if attribute 'websocket.broadcast' exists and ( success or session.unknown ) then terminate relationship (on the FlowFile) --- transfer to session.unknown, success or failure (based on results) - end The purpose of attribute 'websocket.broadcast' it to catch the clones; because if you don't they will transfer to success -- but we don't want that because the original flowfile has already been send down the success road (earlier). While not necessary for what I'm trying to accomplish... Another relationship would be added called 'session unknown'. It represents that the session id no longer exists. This would allow #1 and #2 usages to check Automatically Terminate Relationship. In this way those usages can throw the flowfiles away easily vs. trying to process failure reasons which would otherwise loop in failure forever. > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16084238#comment-16084238 ] Y Wikander edited comment on NIFI-4169 at 7/12/17 4:09 PM: --- Had this crazy idea. In the spirit of "simplifying" PutWebSocket... What if there was a different processor - BroadcastWebSocket - who's job it was to attach websocket.session.id and such. Namely all the things that PutWebSocket needs to sends a message (like when non-broadcast is involved). The broadcast logic would be removed from PutWebSocket. You'd route the message flow from x --> BroadcastWebSocket --> PutWebSocket. BroadcastWebSocket would add an attribute noting that it's a broadcast style message -- in case you wanted to handle errors in PutWebSocket differently. BroadcastWebSocket would transfer to 'failure' if the broadcast list was empty - so one could point it back in (to BroadcastWebSocket) to try again -- if you couldn't afford the data loss. When the user routes PutWebSocket failures they would have the option to route that back to itself (to retry the same sessionsId) *or* to BroadcastWebSocket to get the _current_ list of broadcast recipients. The downside of being routed back to BroadcastWebSocket is that there could be x number of flowfiles with the same data contents coming back (because BroadcastWebSocket created x number of flowfiles). Transmission problems could grow the number of flowfiles exponentially. And think of the poor data recipient -- getting the same message multiple times. In my use case I was using ConnectWebSocket and PutWebSocket; such that - I presume that - the sessionId would change when ConnectWebSocket closed and opened the connection. Such that retrying the same sessionId would always fail. Hence my interest in being able to get the current list of broadcast recipients -- which in my case would be 1. was (Author: ywik): Had this crazy idea. In the spirit of "simplifying" PutWebSocket... What if there was a different processor - BroadcastWebSocket - who's job it was to attach websocket.session.id and such. Namely all the things that PutWebSocket needs to sends a message (like when non-broadcast is involved). The broadcast logic would be removed from PutWebSocket. You'd route the message flow from x --> BroadcastWebSocket --> PutWebSocket. BroadcastWebSocket would add an attribute noting that it's a broadcast style message -- in case you wanted to handle errors in PutWebSocket differently. BroadcastWebSocket would transfer to 'failure' if the broadcast list was empty - so one could point it back in (to BroadcastWebSocket) to try again -- if you couldn't afford the data loss. When the user routes PutWebSocket failures they would have the option to route that back to itself (to retry the same sessionsId) *or* to BroadcastWebSocket to get the _current_ list of broadcast recipients. The downside of being routed back to BroadcastWebSocket is that there could be x number of flowfiles with the same data contents coming back (because BroadcastWebSocket created x number of flowfiles). Transmission problems could grow the number of flowfiles exponentially. And think of the poor data recipient -- getting the same message multiple times. In my use case I was using ConnectWebSocket and PutWebSocket; such that - I presume - that the sessionId would change when ConnectWebSocket closed and opened the connection. Such that retrying the same sessionId would always fail. Hence my interest in being able to get the current list of broadcast recipients -- which in my case would be 1. > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16084238#comment-16084238 ] Y Wikander edited comment on NIFI-4169 at 7/12/17 4:08 PM: --- Had this crazy idea. In the spirit of "simplifying" PutWebSocket... What if there was a different processor - BroadcastWebSocket - who's job it was to attach websocket.session.id and such. Namely all the things that PutWebSocket needs to sends a message (like when non-broadcast is involved). The broadcast logic would be removed from PutWebSocket. You'd route the message flow from x --> BroadcastWebSocket --> PutWebSocket. BroadcastWebSocket would add an attribute noting that it's a broadcast style message -- in case you wanted to handle errors in PutWebSocket differently. BroadcastWebSocket would transfer to 'failure' if the broadcast list was empty - so one could point it back in (to BroadcastWebSocket) to try again -- if you couldn't afford the data loss. When the user routes PutWebSocket failures they would have the option to route that back to itself (to retry the same sessionsId) *or* to BroadcastWebSocket to get the _current_ list of broadcast recipients. The downside of being routed back to BroadcastWebSocket is that there could be x number of flowfiles with the same data contents coming back (because BroadcastWebSocket created x number of flowfiles). Transmission problems could grow the number of flowfiles exponentially. And think of the poor data recipient -- getting the same message multiple times. In my use case I was using ConnectWebSocket and PutWebSocket; such that - I presume - that the sessionId would change when ConnectWebSocket closed and opened the connection. Such that retrying the same sessionId would always fail. Hence my interest in being able to get the current list of broadcast recipients -- which in my case would be 1. was (Author: ywik): Had this crazy idea. In the spirit of "simplifying" PutWebSocket... What if there was a different processor - BroadcastWebSocket - who's job it was to attach websocket.session.id and such. Namely all the things that PutWebSocket needs to sends a message (like when non-broadcast is involved). The broadcast logic would be removed from PutWebSocket. You'd route the message flow from x --> BroadcastWebSocket --> PutWebSocket. BroadcastWebSocket would add an attribute noting that it's a broadcast style message -- in case you wanted to handle errors in PutWebSocket differently. BroadcastWebSocket would transfer to 'failure' if the broadcast list was empty - so one could point it back in (to BroadcastWebSocket) to try again -- if you couldn't afford the data loss. When the user routes PutWebSocket failures they would have the option to route that back to itself (to retry the same sessionsId) *or* to BroadcastWebSocket to get the _current_ list of broadcast recipients. The downside of being routed back to BroadcastWebSocket is that there could be x number of flowfiles with the same data contents coming back (because BroadcastWebSocket created x number of flowfiles). Transmission problems could grow the number of flowfiles exponentially. And think of the poor data recipient -- getting the same message multiple times. - - - - In my use case I was using ConnectWebSocket and PutWebSocket; such that - I presume - that the sessionId would change when ConnectWebSocket closed and opened the connection. Such that retrying the same sessionId would always fail. Hence my interest in being able to get the current list of broadcast recipients -- which in my case would be 1. > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16084238#comment-16084238 ] Y Wikander edited comment on NIFI-4169 at 7/12/17 4:08 PM: --- Had this crazy idea. In the spirit of "simplifying" PutWebSocket... What if there was a different processor - BroadcastWebSocket - who's job it was to attach websocket.session.id and such. Namely all the things that PutWebSocket needs to sends a message (like when non-broadcast is involved). The broadcast logic would be removed from PutWebSocket. You'd route the message flow from x --> BroadcastWebSocket --> PutWebSocket. BroadcastWebSocket would add an attribute noting that it's a broadcast style message -- in case you wanted to handle errors in PutWebSocket differently. BroadcastWebSocket would transfer to 'failure' if the broadcast list was empty - so one could point it back in (to BroadcastWebSocket) to try again -- if you couldn't afford the data loss. When the user routes PutWebSocket failures they would have the option to route that back to itself (to retry the same sessionsId) *or* to BroadcastWebSocket to get the _current_ list of broadcast recipients. The downside of being routed back to BroadcastWebSocket is that there could be x number of flowfiles with the same data contents coming back (because BroadcastWebSocket created x number of flowfiles). Transmission problems could grow the number of flowfiles exponentially. And think of the poor data recipient -- getting the same message multiple times. In my use case I was using ConnectWebSocket and PutWebSocket; such that - I presume - that the sessionId would change when ConnectWebSocket closed and opened the connection. Such that retrying the same sessionId would always fail. Hence my interest in being able to get the current list of broadcast recipients -- which in my case would be 1. was (Author: ywik): Had this crazy idea. In the spirit of "simplifying" PutWebSocket... What if there was a different processor - BroadcastWebSocket - who's job it was to attach websocket.session.id and such. Namely all the things that PutWebSocket needs to sends a message (like when non-broadcast is involved). The broadcast logic would be removed from PutWebSocket. You'd route the message flow from x --> BroadcastWebSocket --> PutWebSocket. BroadcastWebSocket would add an attribute noting that it's a broadcast style message -- in case you wanted to handle errors in PutWebSocket differently. BroadcastWebSocket would transfer to 'failure' if the broadcast list was empty - so one could point it back in (to BroadcastWebSocket) to try again -- if you couldn't afford the data loss. When the user routes PutWebSocket failures they would have the option to route that back to itself (to retry the same sessionsId) *or* to BroadcastWebSocket to get the _current_ list of broadcast recipients. The downside of being routed back to BroadcastWebSocket is that there could be x number of flowfiles with the same data contents coming back (because BroadcastWebSocket created x number of flowfiles). Transmission problems could grow the number of flowfiles exponentially. And think of the poor data recipient -- getting the same message multiple times. In my use case I was using ConnectWebSocket and PutWebSocket; such that - I presume - that the sessionId would change when ConnectWebSocket closed and opened the connection. Such that retrying the same sessionId would always fail. Hence my interest in being able to get the current list of broadcast recipients -- which in my case would be 1. > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16084238#comment-16084238 ] Y Wikander commented on NIFI-4169: -- Had this crazy idea. In the spirit of "simplifying" PutWebSocket... What if there was a different processor - BroadcastWebSocket - who's job it was to attach websocket.session.id and such. Namely all the things that PutWebSocket needs to sends a message (like when non-broadcast is involved). The broadcast logic would be removed from PutWebSocket. You'd route the message flow from x --> BroadcastWebSocket --> PutWebSocket. BroadcastWebSocket would add an attribute noting that it's a broadcast style message -- in case you wanted to handle errors in PutWebSocket differently. BroadcastWebSocket would transfer to 'failure' if the broadcast list was empty - so one could point it back in (to BroadcastWebSocket) to try again -- if you couldn't afford the data loss. When the user routes PutWebSocket failures they would have the option to route that back to itself (to retry the same sessionsId) *or* to BroadcastWebSocket to get the _current_ list of broadcast recipients. The downside of being routed back to BroadcastWebSocket is that there could be x number of flowfiles with the same data contents coming back (because BroadcastWebSocket created x number of flowfiles). Transmission problems could grow the number of flowfiles exponentially. And think of the poor data recipient -- getting the same message multiple times. - - - - In my use case I was using ConnectWebSocket and PutWebSocket; such that - I presume - that the sessionId would change when ConnectWebSocket closed and opened the connection. Such that retrying the same sessionId would always fail. Hence my interest in being able to get the current list of broadcast recipients -- which in my case would be 1. > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16083447#comment-16083447 ] Y Wikander commented on NIFI-4169: -- Could you expand on your last bullet point? Are you suggesting cloning each flowfile that fails to a flowfile with the specific 'websocket.session.id' as an attribute? If not, what if the flowfile failed to send to more than _one_ websocket session? 'websocket.session.id' would contain a comma separated list? What would someone actually _do_ with the websocket.session.id value? Have PutWebSocket use it to control which session id(s) to attempt to send to again if it was routed back into PutWebSocket as 'failure'? > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4170) PutWebSocket processor does not support 'Penalty duration' and 'Yield duration' settings
[ https://issues.apache.org/jira/browse/NIFI-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16083420#comment-16083420 ] Y Wikander commented on NIFI-4170: -- I'll pursue your line of thinking. The discussion turning to processor level misconfiguration makes me ponder the Validators. Not that I really wanted to go deep into the weeds; but would Validators be the "correct" way? Such that the processor would be stopped and the yellow warning symbol would show up in the GUI. This is presuming that Users would be more interested in pursuing those (warning) messages vs. assumed transitory error messages that will probably go away on their own (if you wait long enough). To that end, can Validators be triggered _while_ a processor is running? And, does a processor stop itself as part this action? > PutWebSocket processor does not support 'Penalty duration' and 'Yield > duration' settings > > > Key: NIFI-4170 > URL: https://issues.apache.org/jira/browse/NIFI-4170 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Y Wikander >Priority: Minor > Labels: patch > Attachments: > 0002-websocket-PutWebSocket-processor-support-Penalty-dur.patch > > > PutWebSocket processor does not support 'Penalty duration' and 'Yield > duration' settings. > I'm assuming that calling content.yield() will also cover 'Penalty duration'. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4170) PutWebSocket processor does not support 'Penalty duration' and 'Yield duration' settings
[ https://issues.apache.org/jira/browse/NIFI-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081601#comment-16081601 ] Y Wikander commented on NIFI-4170: -- I'm challenged to agree to just 'yield' under the single condition set you requested. >From what I can tell, the other reasons for failure are related to bad >configuration of the PutWebSocket processor; related to Broadcast support. And >that they won't go away until a human fixes it. > PutWebSocket processor does not support 'Penalty duration' and 'Yield > duration' settings > > > Key: NIFI-4170 > URL: https://issues.apache.org/jira/browse/NIFI-4170 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0, 1.4.0 >Reporter: Y Wikander >Priority: Minor > Labels: patch > Fix For: 1.3.0, 1.4.0 > > Attachments: > 0002-websocket-PutWebSocket-processor-support-Penalty-dur.patch > > > PutWebSocket processor does not support 'Penalty duration' and 'Yield > duration' settings. > I'm assuming that calling content.yield() will also cover 'Penalty duration'. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16081570#comment-16081570 ] Y Wikander commented on NIFI-4169: -- I think that it might be a bit more than I planned on chewing. Looking at PutFTP, PutSFTP, PublishAMQP, PublishMQTT they all use 'failure' as a "can't send to the destination". And it's what the non-broadcasting section of the processor does. What makes broadcasting different? In practice, would one really be broadcasting to a list that contained more than one? As this part I'm hazy on. When does a list come into play? Re the code comments: 1. From testing; the list becomes empty for a while, before it's added to again. I presumed that the ConnectWebSocket closed the session after it's timeout interval, then opened it up again. Such that some flowfiles routed to 'success' even though they never were sent (because the for loop had nothing to do). 2. I could imagine trying to send to as many WebSocketSession entries that it could, and cache up different Exceptions. But then you have to pick which single Exception is more exceptional to report back. And, back to my question, would one really be broadcasting to a list under normal circumstances? > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0, 1.4.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Fix For: 1.3.0, 1.4.0 > > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
[ https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Y Wikander updated NIFI-4169: - Component/s: (was: Core Framework) Extensions > PutWebSocket processor with blank WebSocket session id attribute cannot > transfer to failure queue > - > > Key: NIFI-4169 > URL: https://issues.apache.org/jira/browse/NIFI-4169 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0, 1.4.0 >Reporter: Y Wikander >Priority: Critical > Labels: patch > Fix For: 1.3.0, 1.4.0 > > Attachments: > 0001-websocket-when-sendMessage-fails-under-blank-session.patch > > > If a PutWebSocket processor is setup with a blank WebSocket session id > attribute (see NIFI-3318; Send message from PutWebSocket to all connected > clients) and it is not connected to a websocket server it will log the > failure and mark the flowfile with Success (rather than Failure) -- and the > data is effectively lost. > If there are multiple connected clients, and some succeed and others fail, > routing Failure back into the PutWebSocket could result in duplicate data to > some clients. > Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (NIFI-4170) PutWebSocket processor does not support 'Penalty duration' and 'Yield duration' settings
[ https://issues.apache.org/jira/browse/NIFI-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Y Wikander updated NIFI-4170: - Component/s: (was: Core Framework) Extensions > PutWebSocket processor does not support 'Penalty duration' and 'Yield > duration' settings > > > Key: NIFI-4170 > URL: https://issues.apache.org/jira/browse/NIFI-4170 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0, 1.4.0 >Reporter: Y Wikander >Priority: Minor > Labels: patch > Fix For: 1.3.0, 1.4.0 > > Attachments: > 0002-websocket-PutWebSocket-processor-support-Penalty-dur.patch > > > PutWebSocket processor does not support 'Penalty duration' and 'Yield > duration' settings. > I'm assuming that calling content.yield() will also cover 'Penalty duration'. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (NIFI-4170) PutWebSocket processor does not support 'Penalty duration' and 'Yield duration' settings
Y Wikander created NIFI-4170: Summary: PutWebSocket processor does not support 'Penalty duration' and 'Yield duration' settings Key: NIFI-4170 URL: https://issues.apache.org/jira/browse/NIFI-4170 Project: Apache NiFi Issue Type: Improvement Components: Core Framework Affects Versions: 1.3.0, 1.4.0 Reporter: Y Wikander Priority: Minor Fix For: 1.4.0, 1.3.0 Attachments: 0002-websocket-PutWebSocket-processor-support-Penalty-dur.patch PutWebSocket processor does not support 'Penalty duration' and 'Yield duration' settings. I'm assuming that calling content.yield() will also cover 'Penalty duration'. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (NIFI-4169) PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue
Y Wikander created NIFI-4169: Summary: PutWebSocket processor with blank WebSocket session id attribute cannot transfer to failure queue Key: NIFI-4169 URL: https://issues.apache.org/jira/browse/NIFI-4169 Project: Apache NiFi Issue Type: Improvement Components: Core Framework Affects Versions: 1.3.0, 1.4.0 Reporter: Y Wikander Priority: Critical Fix For: 1.4.0, 1.3.0 Attachments: 0001-websocket-when-sendMessage-fails-under-blank-session.patch If a PutWebSocket processor is setup with a blank WebSocket session id attribute (see NIFI-3318; Send message from PutWebSocket to all connected clients) and it is not connected to a websocket server it will log the failure and mark the flowfile with Success (rather than Failure) -- and the data is effectively lost. If there are multiple connected clients, and some succeed and others fail, routing Failure back into the PutWebSocket could result in duplicate data to some clients. Other NiFi processors seem to err on the side of "at least once". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
