[ https://issues.jboss.org/browse/TEIID-2676?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2676: --------------------------------------- Ah, I glanced and must have assumed that you were reusable. The issue here is still really one of strictness - more deeply it's an issue of how the client and source events interact with the processing state machine. The client will always proactively fetch the next batch after the first batch (of a single row) is delivered, it signals it wants more results. In the not forkable scenario, this is occurring with the state machine is in the executing state. The state machine will transition into "more work" as it's assumed this is generally an asynch process from execution and we don't know where we are at in the execution cycle - it's a purposeful simplification to keep the state machine unaware of whether the work event is related to results processing or from a source. Then when the translator throws a non-strict DNA it will be immediately handle since you are not forkable and the engine will see the "more work" state and immediately try to continue executing. When forkable, essentially the execution state machine is transitioning out of execution prior to processing the DNA, such that it will be interpreted the way you expect. So the best recommendation in general is to use a strict DNA to prevent any spurious wake up from triggering a processing that you don't expect. Otherwise we'd likely have to differentiate more between the "more work" events, which isn't appealing. That represents that your plan (which is now asynch from the Execution) will transition into a different state by the time the DNA or results have been delivered, such that it more results are requested by the client -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira