search

unicesi / amelia

:airplane: DSL for deploying distributed systems, with custom commands to compile and execute FraSCAti applications
GNU Lesser General Public License v3.0
2 stars 3 forks source link

Execution Frozen #17

Closed juan3036 closed 7 years ago

juan3036 commented 8 years ago

Hi @jachinte

I'm getting a new issue with the latest version of the library. When the program is running normally and it has to start the deployment of the components, it gets freezed, that is, it "stops" at the "new working directory" stage and nothing else happens, there is not error neither with Amelia Classes nor Frascati deployment (I checked the sessions logs and the amelia's log). It just gets freezed, as you can see in the image.

I post an issue because this happened to me twice today.

Thansk for your attention.

Regards. screenshot from 2016-04-17 12_40_40

jachinte commented 8 years ago

We saw (cc. @kllara) this behavior last week, but we thought it was related to #14. Now, if you run your project again, it will happen again at the same point? or it is unpredictable? Even when it is unpredictable, does it happen at the same point? I did a minor change a few days ago when Karen reported #12. I appreciate your help, hopefully this bug is one of the last, we're getting there :+1:

juan3036 commented 8 years ago

Hi.

The behavior is unpredictable (I didn't get this error for a long time ago, just with the new version). If I run the project again it can execute normally for a time and then happens (or not) what I described. The two times it happens to me, it "stops" at the same point (described above and image). I dont think that it is related with the omission of a Descriptor or Dependencies order because, as I mentioned before it can works it cannot. Additionally, I haven't make any changes to my deployment classes different to the library.

jachinte commented 8 years ago

I understand, what I meant is that I introduced that bug when trying to solve #12 (I touched the dependencies mechanism), and we first thought it was related to #14. Are you realizing tests right now? To revert the change I mentioned, and see the result.

juan3036 commented 8 years ago

Yes, I'm working right now. haha I didn't understand at first. Apology

juan3036 commented 8 years ago

Thanks . It seems that the problem is solved now.

jachinte commented 7 years ago

One year later, I could reproduce the issue and solve it 🎉 Just for the record, the problem was that Observable.setChanged and Observable.notifyObservers were being invoked at the same time from different threads on the same CommandDescriptor, which causes one or several dependencies to miss the notification. For example:

...
[Thread-44] DONE: cd /tmp
[Thread-51] NOTIFIED: curl -L -o jdk-6u23-linux-x64.bin ...jdk-6u23-linux-x64.bin NEW COUNT: 0
[Thread-50] NOTIFIED: curl -L -o jdk-6u23-linux-x64.bin ...jdk-6u23-linux-x64.bin NEW COUNT: 0
MAIN SIGNAL: 37
[Thread-50] DONE: curl -L -o jdk-6u23-linux-x64.bin ...jdk-6u23-linux-x64.bin
[Thread-31] NOTIFIED: chmod a+x jdk-6u23-linux-x64.bin NEW COUNT: 1
[Thread-30] NOTIFIED: chmod a+x jdk-6u23-linux-x64.bin NEW COUNT: 1
MAIN SIGNAL: 36
[Thread-51] DONE: curl -L -o jdk-6u23-linux-x64.bin ...jdk-6u23-linux-x64.bin
MAIN SIGNAL: 35

In that case, threads Thread-30 and Thread-31 were not notified by Thread-51. Therefore, subsequent dependencies are not released and execution gets frozen.