[
https://issues.apache.org/jira/browse/EDGENT-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere updated EDGENT-382:
-----------------------------------
Attachment: DlabossExceptionTest.java
Sample program that can demonstrate the behavior of the various cases
> A RuntimeException thrown while processing a tuple brings down the whole
> topology
> ---------------------------------------------------------------------------------
>
> Key: EDGENT-382
> URL: https://issues.apache.org/jira/browse/EDGENT-382
> Project: Edgent
> Issue Type: Bug
> Components: Runtime
> Reporter: Dale LaBossiere
> Attachments: DlabossExceptionTest.java
>
>
> I encountered the above in the context of the WIoTP connector, and
> there may be a problem there as well, but it’s trivial to demonstrate the
> problem in a more general context.
> i.e., a RuntimeException thrown from a Topology.poll(), generate(), source()
> or from an unisolated user function implementation downstream of the source,
> like a map() or sink()'s function, causes the topology to immediately
> terminate. That typically causes the process to terminate.
> It's unclear to me which parts of the runtime should be doing what with
> respect to this.
> Things need to be more resilient in the face of transient errors,
> particularly wrt transient connector problems. As an example
> MqttPublisher.accept() achieved resiliency in the face of transient
> connection problems by logging instead of throwing. IotpDevice connector
> just throws... which at a certain level is OK/desirable... if the runtime
> were to handle resiliency issues.
> Note, a RuntimeException from a Topology.events() supplier or even a
> downstream function doesn't result in topology termination. That's because
> the runtime thread blocking awaiting the next supplied tuple doesn't see the
> RuntimeException. And for the downstream case, the stream is Isolated so
> again the runtime thread doesn't see the exception. That said, the thread
> internal to Isolate silently terminates in the face of a downstream
> exception. ugh. (Barrier looks to have a similar problem).
> There needs to be some clear / prominent doc on all of this, what the design
> / behavior is supposed to be, and then we can address any issues in the light
> of that understanding.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
