Skip to content

All posts

Bug fix, , 1 min read

Two fixes in 7.14-beta.1 worth knowing about

Processor filters could leave a stream permanently unprocessed, and bitmap-lookup ran its values together. Both are fixed in 7.14-beta.1.

Most of 7.14-beta.1 is new work on processing and AI. It also carries two fixes that change behaviour you may be relying on, one of them without knowing it.

A stream that was never processed (#5683)

Symptom. A processor filter could silently skip a stream, leaving it permanently unprocessed. Nothing reported an error, and the stream simply never got a task.

Cause. This was a race. When task creation read the highest stream id, a stream with a lower id could still be in the middle of being committed. Task creation moved past it, and never came back.

Fix. Task creation is now bounded by the highest stream id seen on the previous poll, so a stream still being committed is picked up next time round. The cost is up to one poll interval of extra latency before a new stream gets a task. If you would rather have the old behaviour, turn it off with stroom.processor.useMaxMetaIdFromPreviousPoll.

If you have ever found a stream sitting unprocessed with no errors against it, this is a likely explanation.

bitmap-lookup values ran together (#5713)

Symptom. The bitmap-lookup XSLT function returned the values of the matched bit positions concatenated with no delimiter. The documentation said they were space delimited.

Fix. The values are now space delimited, as documented. A new optional sixth argument sets a different delimiter (#1890).

Check your XSLT. If you wrote code that works around the old output, it will see spaces now. The fix came from an external contributor, complete with new tests, which is exactly how an open-source project should work.

How it works, in detail: Docs: Processor Filters and Tasks

Want this running on your own data? The engineers who built it can help.