-
Notifications
You must be signed in to change notification settings - Fork 5
Fixes #10677: Datasources plugin call continuously datasource url even after delete #23
Conversation
28d0c23
to
e6758c1
Compare
PR rebased |
@@ -199,8 +215,6 @@ class DataSourceRepoImpl( | |||
|
|||
} | |||
private[this] def updateDataSourceScheduler(source: DataSource, delay: Option[FiniteDuration]): Unit = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, the problem was most likely here: that method is not synchronized, and was used on non sync method. So what could have happened:
[context $1]
- stop source.id $0,
[switch context to $2] - stop source.id $0,
- create dss $2
- save dss $2
- start dss $2
[switch context $1] - create dss $1
- save dss $1
- start dss $1
So now, both $1 and $2 run, but only $1 is know for rudder. This is bad.
@@ -242,7 +256,7 @@ class DataSourceRepoImpl( | |||
* on update, we need to stop the corresponding optionnaly existing | |||
* scheduler, and update with the new one. | |||
*/ | |||
override def save(source : DataSource) : Box[DataSource] = synchronized { | |||
override def save(source : DataSource) : Box[DataSource] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think it shold stay synchronized (but not 100% sure)
e6758c1
to
5717e0e
Compare
PR rebased |
1 similar comment
PR rebased |
5717e0e
to
065cc78
Compare
private[this] def stop(id: DataSourceId) = { | ||
DataSourceLogger.debug(s"Stopping data source with id '${id.value}'") | ||
internal.get(id) match { | ||
case None => s"Data source with id ${id.value} was not found running" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this text doesn't go anywhere, unless i'm mistaken. Shouldn't it go to a logger ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes :)
065cc78
to
09ecda3
Compare
PR rebased |
OK, merging this PR |
https://www.rudder-project.org/redmine/issues/10677
That pull request correct a nasty race condition. I was not able to reproduce it live, but the race is clearly there.
I could just have added synchronized on updateDataSourceScheduler, but it would have been bugs wainting to flourish, so I prefered to encapsulate all the must-be synchronized methods dealing with our mutable var in a synchronized object.
To sum up: mutable var are bad. Mutable vars combined with threads are a can of worms, the worms being able to fly and kill any life on a touch. And yes, you have to unknot the thing.