Originally we did think to introduce async model to CloudStack
orchestration engine, using queues, event notifications etc to make the
system more loosely-coupled and use much less thread resources with async
programming. However, due the large code base we already have and
synchronous programming is everywhere, it end up to where we are now.
Async programing is also not async-method based programming, you may view
it as over-engineering, it is truly un-completed engineering in my
opinion. The same goes to the VMSync refactoring as well, job framework is
refactored to support putting a job on hold and waking it up upon events
but in reality, you will still see that we just hold a thread waiting for
completion. So we definitely still have a lot of work to do for CloudStack
to continuously evolve itself
Kelven
On 1/28/14, 4:52 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> wrote:
>It seems in the cases that I've observed this pattern that we don't
>actually do anything asynchronously. We call a method that has the word
>"Async" in it typically, but this method does everything in sequence and
>then returns a "future" object. The calling code then calls get() on the
>future object, which returns immediately because everything was executed
>in
>sequence in the "Async" method.
>
>I was curious, were we planning on making many of these operations truly
>asynchronous in the future?
>
>If not, I wonder if there's a bit of over-engineering going on here? If
>they are always going to be done synchronously, we could just call the
>"callback" method after calling the "async" method.
>
>Thoughts on this?
>
>Thanks :)
>
>
>On Tue, Jan 28, 2014 at 3:42 PM, Kelven Yang <kelven.y...@citrix.com>
>wrote:
>
>> I originally thought to just ask developer to use plain string literals,
>> it has better readability but it can't take advantage of IDE provided
>> refactoring (callback method renames), it ended up to this crazy
>>approach.
>> Hopefully one day Java may provide C# delegate like feature, then all
>> these hacking tricks can go away
>>
>> Kelven
>>
>> On 1/28/14, 2:29 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com>
>> wrote:
>>
>> >I see...just for chaining purposes. In some places I notice we chain
>>this
>> >and in others we don't.
>> >
>> >Thanks for the clarification!
>> >
>> >
>> >On Tue, Jan 28, 2014 at 3:13 PM, Kelven Yang <kelven.y...@citrix.com>
>> >wrote:
>> >
>> >> This is to support fluent coding style to chain all the callback
>>setup
>> >> calls in one line. Using caller.getTarget().callbackMethod() alone
>>may
>> >> cause people to think the statement as a logic requirement and
>>actually
>> >>it
>> >> is not but hackings.
>> >>
>> >> It is like to setup a function pointer in C or delegate in C#, but
>>it is
>> >> kind of alien in Java world since Java does not have language level
>> >> support for this yet.
>> >>
>> >> Kelven
>> >>
>> >> On 1/28/14, 11:06 AM, "Mike Tutkowski" <mike.tutkow...@solidfire.com>
>> >> wrote:
>> >>
>> >> >Thanks Kelven
>> >> >
>> >> >Yeah, that code is pretty crazy. :)
>> >> >
>> >> >I followed that the getTarget() method actually dynamically extends
>>a
>> >> >class
>> >> >and allows us to inject logic in the new class that enables us to
>>save
>> >> >createVolumeFromBaseImageCallBack as the method we want to invoke
>>when
>> >>our
>> >> >async operation has completed.
>> >> >
>> >> >It does provide the benefit that you don't have to pass in a string
>> >>that
>> >> >represents the method name.
>> >> >
>> >> >What I was actually wondering about, though, is why we surround
>> >> >caller.getTarget().createVolumeFromBaseImageCallBack(null, null);
>>with
>> >> >caller.setCallback();?
>> >> >
>> >> >It seems that setCallback() ignores the input parameter and just
>> >>returns
>> >> >"this";
>> >> >
>> >> >Wouldn't caller.getTarget().createVolumeFromBaseImageCallBack(null,
>> >>null);
>> >> >by itself work exactly the same way?
>> >> >
>> >> >
>> >> >On Tue, Jan 28, 2014 at 11:57 AM, Kelven Yang
>> >> ><kelven.y...@citrix.com>wrote:
>> >> >
>> >> >> Mike,
>> >> >>
>> >> >> This is a very dirty hack that I personally hate it. This is the
>> >>hack to
>> >> >> utilize Eclipse¹s (or other smart IDE) to do auto-completion for
>>you
>> >>to
>> >> >> find the right callback method.
>> >> >>
>> >> >> if you write
>> >> >>
>> >> >> caller.getTarget().createVolumeFromBaseImageCallBack(null,
>>null);
>> >> >>
>> >> >> Java will interprete it as a standalone method call,
>> >> >>
>> >> >>
>> >> >> If you write as below, it tries to tell that this is to setup a
>> >> >>callback,
>> >> >> to return this in caller.setCallback is to let you continue to use
>> >> >>fluent
>> >> >> style to callback setups
>> >> >>
>> >> >> caller.setCallback(
>> >> >> caller.getTarget().createVolumeFromBaseImageCallBack(null, null)
>>);,
>> >> >>
>> >> >> Behind scene, it uses CGLIB for dispatcher to figure out which
>> >>method is
>> >> >> the callback without requiring developer to give it as literal
>>string
>> >> >>
>> >> >>
>> >> >> AsyncMethod pattern is used commonly in parallel algorithms to
>> >> >>dynamically
>> >> >> branch out sub-calculations, I think it does not fit well in
>> >>CloudStack,
>> >> >> and also due to the lack of language feature in Java, this
>>hacking
>> >> >> technique makes the code really hard to read
>> >> >>
>> >> >> Kelven
>> >> >>
>> >> >> On 1/27/14, 6:55 PM, "Mike Tutkowski"
>><mike.tutkow...@solidfire.com>
>> >> >> wrote:
>> >> >>
>> >> >> >Hi,
>> >> >> >
>> >> >> >I've been looking at our callback pattern.
>> >> >> >
>> >> >> >Can someone explain why we always seem to do this?:
>> >> >> >
>> >> >>
>> >>
>>
>>>>>>>caller.setCallback(caller.getTarget().createVolumeFromBaseImageCallB
>>>>>>>ac
>> >>>>>k(
>> >> >>>nu
>> >> >> >ll,
>> >> >> >null));
>> >> >> >
>> >> >> >When setCallback is implemented like this:
>> >> >> >
>> >> >> >public AsyncCallbackDispatcher<T, R> setCallback(Object useless)
>>{
>> >> >> >
>> >> >> > return this;
>> >> >> >
>> >> >> > }
>> >> >> >
>> >> >> >Why not just this?:
>> >> >> >
>> >> >> >caller.getTarget().createVolumeFromBaseImageCallBack(null, null);
>> >> >> >
>> >> >> >Thanks!
>> >> >> >
>> >> >> >--
>> >> >> >*Mike Tutkowski*
>> >> >> >*Senior CloudStack Developer, SolidFire Inc.*
>> >> >> >e: mike.tutkow...@solidfire.com
>> >> >> >o: 303.746.7302
>> >> >> >Advancing the way the world uses the
>> >> >> >cloud<http://solidfire.com/solution/overview/?video=play>
>> >> >> >* *
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >--
>> >> >*Mike Tutkowski*
>> >> >*Senior CloudStack Developer, SolidFire Inc.*
>> >> >e: mike.tutkow...@solidfire.com
>> >> >o: 303.746.7302
>> >> >Advancing the way the world uses the
>> >> >cloud<http://solidfire.com/solution/overview/?video=play>
>> >> >*(tm)*
>> >>
>> >>
>> >
>> >
>> >--
>> >*Mike Tutkowski*
>> >*Senior CloudStack Developer, SolidFire Inc.*
>> >e: mike.tutkow...@solidfire.com
>> >o: 303.746.7302
>> >Advancing the way the world uses the
>> >cloud<http://solidfire.com/solution/overview/?video=play>
>> >*(tm)*
>>
>>
>
>
>--
>*Mike Tutkowski*
>*Senior CloudStack Developer, SolidFire Inc.*
>e: mike.tutkow...@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud<http://solidfire.com/solution/overview/?video=play>
>*(tm)*
