Hi,
Is it possible to halt the normal data flow (preferably with a transformer), and ensure that a certain transformer receives and processes one feature at a time before the next feature is provided to it ? Some sort of "semaphore" or "street light" functionality ?
I have a custom transformer that works perfectly, but its logic is only valid on a single feature.
Plan B is to redo the logic, but if the above is possible, it would be much simpler.
Cheers.
Lars
Hi
For non-blocking transformers it is already so: only one feature is treated at a time.
Does your custom transformer use blocking transformers and/or Group By's, maybe?
One workaround could be to move your custom transformer to a separate workspace and call it using the WorkspaceRunner. That way only one single feature is processed at a time. Just be aware that it will take a fair bit longer to run the workspace, as starting and stopping FME for each feature creates a lot of overhead.
David
When I've had to process a single feature at a time in a custom transformer I've added a unique id attribute (counter), published the Parallel Processing Group-By as a published parameter and set it to the uniqueID.
Note if you have a lot of features, you need to keep the parallel-processing level set to No-Parallelism, because windows has a hard limit on the number of sockets that can be opened simultaneously by a single process.
Also depending on the complexity of your custom transformer, the overhead of the parallel processing is more costly than the savings of running in parallel.
another method is to use a custom transformer and indexes.
Synchronising the inedex with input you can have a object feed to the custom and after processing within the custoim raise the index. etc.
When I've had to process a single feature at a time in a custom transformer I've added a unique id attribute (counter), published the Parallel Processing Group-By as a published parameter and set it to the uniqueID.
Note if you have a lot of features, you need to keep the parallel-processing level set to No-Parallelism, because windows has a hard limit on the number of sockets that can be opened simultaneously by a single process.
Also depending on the complexity of your custom transformer, the overhead of the parallel processing is more costly than the savings of running in parallel.
This fixed my issue.
For me, the leap was to look at the transformer's parameters to find Parallel Processing and Group By. Also, I added a FeatureHolder before the custom transformer and set Group Processing > Group By to create the counter attribute.