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().createVolumeFromBaseImageCallBac
> >>>>>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)*
