🎉 🎉 RAPIDMINER 9.10 IS OUT!!! 🎉🎉

Download the latest version helping analytics teams accelerate time-to-value for streaming and IIOT use cases.

CLICK HERE TO DOWNLOAD

NOTE: IF YOU WISH TO REPORT A NEW BUG, PLEASE POST A NEW QUESTION AND TAG AS "BUG REPORT". THANK YOU.

Development: AbstractModel is not thread safe

landland RapidMiner Certified Analyst, RapidMiner Certified Expert, Member Posts: 2,531   Unicorn
Dear Dev team of RapidMiner,
I just found a problem in the API of RapidMiner. While one part of the api assumes that AbstractModels are indeed read-only and so not really creates a copy but merely returns a reference to the same object, the actual implementation has states. These states are just for apply time and should be avoided in my understanding, as using it in multi threading environment creates several timing based NPEs. In my situation I want to apply the same model in a parallized loop. But when doing so, the model will be set the current operator who is applying it as a state rather than passing it as part of the method call. As this is done by many parallel threads, it is inconsistent for each thread. One thread might just set it to null after the null check of another thread causing the following NPE.
The quick and bad solution would be to make the copy actually work and provide a copy of the model, perhaps just a wrapper around the still unchanged object to avoid copying multiple GB of SVM model...
The better way would be to refactor the entire API of models (and IOObjects) to separate between process flow and application logic and actual content...
I just want to let you know that, as there's no way for us to work around thate except writing into repository and de-serializing from there.

Greetings,
 Sebastian
Tagged:
0
0 votes

Sent to Engineering · Last Updated

RM-4228

Sign In or Register to comment.