On 09/22/11 - 09:39:00AM, Chris Lalancette wrote:
On 09/21/11 - 08:57:28PM, Ian Main wrote:
> From: Chris Lalancette <clalance(a)redhat.com>
>
> I modified Chris' patch to use a thread instead of fork. This pushes
> the communications with deltacloud into a thread which can take as long
> as it needs to complete the start.
>
> In the future we may want to put a retry in here too.
>
> Signed-off-by: Ian Main <imain(a)redhat.com>
> ---
> src/app/util/taskomatic.rb | 67 +++++++++++++++++++++++++++----------------
> 1 files changed, 42 insertions(+), 25 deletions(-)
I tried this patch out, but it is not really working for me.
1) When I tried to launch a 4 instance deployable, it seemed to deadlock the
rails application. There are comments in the Active Record postgresql adapter
to the affect that you need to set config.allow_concurrency to true before
using threads. After I hacked up the activerecord code to manually set async
to false, it no longer deadlocked. I'm guessing we need to set that
^^^^^
Gah. Above should be "true"
configuration somewhere, but the old methods of doing so seem to have
been
deprecated.
2) Even with 1) hacked around, my instances never got out of the NEW state.
dbomatic ignores any instances in the NEW or STOPPED state at the moment, so
that part of it makes sense. What does not make sense, however, is that the
taskomatic thread should have updated the instance state to PENDING before it
exited. It seems to mean that the instance.save! at the end of the thread
doesn't seem to be getting executed, which doesn't fill me with confidence.
3) I'm getting a lot of stack traces in deltacloud-core when trying to launch
these multi-instance deployables. That may be totally unrelated to this
particular patch, but it bears looking into.
--
Chris Lalancette
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel
--
Chris Lalancette