[
https://issues.apache.org/jira/browse/NIFI-4169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
