Conversations conversation for chianti

[Jim Marino <jm...@myromatours.com>]

Ignacio and I had a chat on non-blocking and conversational support  
today for those interested:


isilval__: hi jmarino, you there?
[11:25am] jmarino: hey Igancio, will you be around in 30mins? I'm otp
[11:25am] isilval__: sure, I'll be here
[11:38am] isilval__ left the chat room. ("Trillian (http:// 
www.ceruleanstudios.com")
[11:48am] isilval__ joined the chat room.
[11:48am] jmarino: Hi Ignacio
[11:48am] isilval__: hi Jim, had to rebootm, but I'm back
[11:48am] isilval__: reboot ...
[11:49am] jmarino: k I'm free if you are to chat
[11:49am] isilval__: yes, I was thinking about starting to prototype  
local stateless callbacks in chianti based on the discussion so far
[11:50am] jmarino: yea that sounds good. Do you want to walk through  
a couple cases now and we can discuss?
[11:50am] jmarino: I looked at your preso more on the plane back  
yesterday
[11:50am] isilval__: sure, you have something in mind?
[11:51am] jmarino: sure I have a few questions maybe we could start  
there?
[11:51am] isilval__: ok
[11:51am] jmarino: just as a warning I'm a bit jet-lagged so I may be  
a bit incoherent
[11:51am] isilval__: yeah, jet lag can do that to you ...
[11:52am] jmarino: so the first question was regarding the need for a  
non-blocking invoke on the target invoker. I'm wondering if we need  
that or we can use what is there and return void
[11:52am] jmarino: the reason I ask is I'm trying to limit the number  
of combinations
[11:53am] isilval__: right, except that the method in TargetInvoker  
returns Object
[11:53am] jmarino: yes so I was thinking just null, which is never  
returned to the client
[11:53am] isilval__: and the actual target invoker may want to be  
able to tell the difference to know what to do
[11:54am] isilval__: in the local case it may want to dispatch to the  
work manager
[11:55am] jmarino: the target invoker (ti for short so I don't have  
to type) is created by the target side. So, wouldn't always be local  
or always be remote?
[11:55am] jmarino: for example, the target is a component or it is a  
reference
[11:56am] isilval__: hmm, maybe I misunderstand, I thought the ti was  
configured into the wire invocation handler
[11:56am] jmarino: it is but it is determined by the target. The ti  
is created by the target and then put on the client side
[11:57am] jmarino: the runtime does this when it connects the two  
sides of the wire
[11:57am] isilval__: ah, ok
[11:57am] jmarino: the ti is then passed in the invocation as part of  
the message
[11:57am] jmarino: at the end, there is an interceptor which pulls it  
from the message and invokes the ti
[11:58am] isilval__: ok, but it still needs to know that this  
invocation unwinds right away and does not wait for the target
[11:58am] jmarino: right so the ti is per operation as well
[11:58am] jmarino: it should know that when it is created by the runtime
[11:59am] isilval__: ah yes, I remember being a bit confused about  
that in the code
[11:59am] isilval__: ok, so then there would be different kinds for  
different types of operations
[11:59am] jmarino: yea it is kind of complex. it would be good to see  
if we can simplify some things as we go through this too
[11:59am] jmarino: yes different kinds per operation
[11:59am] isilval__: but they all implement only one invoke
[12:00pm] isilval__: that sounds doable
[12:00pm] isilval__: as long as we can capture the variability
[12:01pm] isilval__: we can go as you propose and see how far it  
takes us
[12:01pm] jmarino: yea hopefully we can do that. Right now we create  
a target invoker by passing a java.lang.Method. This may be  
problematic....
[12:01pm] jmarino: we may need to have a generic representation of  
the operation, including whether it is async
[12:02pm] jmarino: if that is the case, then we can fix that as we go  
through
[12:02pm] isilval__: right now it can tell by introspecting its  
interface and checking whether it has a callback annotation ...
[12:03pm] isilval__: that could be messy
[12:03pm] jmarino: yea I think that is problematic...
[12:03pm] jmarino: one is the knowledge of the annotation. The other  
is for non-Java
[12:03pm] jmarino: I think we need to have a general service contract  
representation
[12:04pm] jmarino: so for instance, on Component we have  
TargetInvoker createTargetInvoker(String serviceName, Method  
operation); which is a problem
[12:04pm] isilval__: is that something that can be deferred?
[12:04pm] jmarino: we could. As long as we can differentiate the  
async vs. sync
[12:04pm] jmarino: Looking at it, I'm not sure we can though
[12:05pm] isilval__: you mean in general?
[12:06pm] jmarino: If we can defer it, I think it would be good to do  
that. The problem I'm starting to think about is how does the  
Component know it is an async or sync operation that it is creating  
the ti for.
[12:07pm] isilval__: well the service interface must have a callback  
associated with it
[12:07pm] jmarino: yes. I think the problem is say for  
org.apache.tuscany.spi.component.Reference....
[12:07pm] isilval__: can we get at the service interface from the name?
[12:08pm] jmarino: let me check something quickly...
[12:09pm] jmarino: sorry.. was just digging through code
[12:09pm] jmarino: ok we do have ServiceContract
[12:10pm] jmarino: we could get it from there
[12:10pm] jmarino: for example  
org.apache.tuscany.core.implementation.JavaServiceContract
[12:10pm] jmarino: there's a WSDL one as well
[12:12pm] jmarino: does that make sense?
[12:12pm] isilval__: not sure why Reference is involved
[12:12pm] jmarino: a Reference can also create a ti (Reference ==  
ExternalService )
[12:12pm] jmarino: can you open  
org.apache.tuscany.spi.component.Reference ?
[12:12pm] isilval__: ah yes
[12:13pm] isilval__: ok
[12:13pm] jmarino: that has createTargetInvoker(String serviceName,  
Method operation); as well
[12:13pm] jmarino: operation is represented as a Method
[12:13pm] jmarino: eventually, we should probably change that to  
something more generic
[12:14pm] jmarino: originally we had a generic one, went to methods  
because it was simpler and now I think it may be problematic
[12:14pm] isilval__: so the client is creating a ti for the async  
invocation of an operation with a callback
[12:15pm] isilval__: and it needs to create an async ti
[12:15pm] jmarino: what happens is the runtime processes a model in a  
couple of steps...
[12:15pm] jmarino: the first is to load from XML to an in-memory model
[12:15pm] isilval__: right
[12:15pm] jmarino: then the model is processed and built (the  
builders)...
[12:16pm] jmarino: at that point the components are created with  
inbound and outbound wires...
[12:16pm] isilval__: so it's the in-memory model of the client  
component that is creating the ti
[12:16pm] jmarino: the wires are not connected. they are basically  
dangling
[12:16pm] isilval__: right
[12:16pm] jmarino: then there is the connect phase which attaches  
inbound and oputbound
[12:16pm] jmarino: at that point the tis are created
[12:17pm] jmarino: one other thing may happen
[12:17pm] jmarino: if the ti is optimizable, the  
WireInvocationHandler may clone it and hold on to it on the proxy
[12:17pm] jmarino: that is at the first invoke
[12:17pm] jmarino: if it is not cacheable, it just uses the "master" ti
[12:18pm] isilval__: sounds like it could be cacheable
[12:18pm] jmarino: for many things it can. For some things it can't.  
E.g. if I call from a module-->session scope component it can't be  
cached
[12:18pm] jmarino: the other way around it can be
[12:18pm] isilval__: I see
[12:19pm] jmarino: so I'm wondering whether we see how far using  
Method will take us and if we need to change it we can
[12:20pm] jsdelfino joined the chat room.
[12:20pm] jsdelfino left the chat room.
[12:21pm] jmarino: what do you think?
[12:21pm] isilval__: yeah we can try that
[12:22pm] jmarino: k have another question. You mentioned about  
redoing the one way. Could you explain a little?
[12:22pm] isilval__: well, one-way does something similar and it may  
also vary depending on local/remote
[12:23pm] isilval__: ie, it may not need to spawn a new thread if remote
[12:23pm] jmarino: so since the ti is always determined by the target  
we should be ok right?
[12:23pm] isilval__: sounds like it
[12:24pm] isilval__: perhaps that could be our very first baby step
[12:24pm] isilval__: to see if we can redo one-way this way
[12:24pm] jmarino: that would be good.
[12:24pm] isilval__: and then we'll deal with the actual callback
[12:24pm] isilval__: let me try to prototype that
[12:25pm] jmarino: so we have an AsyncInterceptor in there. Youd'  
change it to a ti?
[12:25pm] isilval__: right
[12:26pm] isilval__: instead of spawning right away, the ti would  
spawn right before the invoke
[12:26pm] isilval__: ie, the invocation chains would happen sync'ly
[12:27pm] jmarino: right
[12:27pm] jmarino: would we start with a local Java component or try  
a remote thing?
[12:28pm] isilval__: for one-way, the local seems to be the more  
involved
[12:28pm] jmarino: k so which do you prefer to start with?
[12:28pm] isilval__: local
[12:29pm] jmarino: k so we'll have to change JavaAtomicComponent  
around a little
[12:29pm] jmarino: and there is a PojoInvoker
[12:29pm] isilval__: PojoInvoker can stay as it is for sync
[12:30pm] jmarino: yes right
[12:30pm] isilval__: and we could something like AsyncPojoInvoker
[12:30pm] jmarino: yep
[12:30pm] jmarino: I've got a few changes to commit in it related to  
constructor injection tonight. Perhaps I could get those in tonight  
and then you start prototyping. I'll apply patches for you
[12:31pm] isilval__: sounds good
[12:31pm] jmarino: k what I can also do is make sure I'm on IRC and  
GoogleTalk since I imagine there will be a bunch of questions that  
come up
[12:31pm] jmarino: do you use googletalk?
[12:31pm] isilval__: I'll be in tomorrow and monday and then out on  
vacation tue-fri next week
[12:32pm] isilval__: yes, that would be good
[12:32pm] jmarino: k I'll be here tomorrow and monday to. I'm back in  
San Fran now
[12:32pm] jmarino: k so I'll check those things in tonight and we'll  
keep moving through this
[12:32pm] isilval__: sounds good
[12:33pm] jmarino: also, do you mind if I post this to the list since  
Meeraj and Jeremy were also interested?
[12:33pm] isilval__: I was going to ask about that
[12:33pm] isilval__: sure, that would be good
[12:34pm] jmarino: Jeremy is on the Axis binding right now but I  
think we may be able to get him to deal with some of the Method  
stuff. Meeraj had some interest as well...there's certainly enough  
work to go around
[12:34pm] isilval__: I'm still seeing build issues with binding  
integration test
[12:34pm] jmarino: oh jaxb?
[12:34pm] isilval__: yeah
[12:35pm] jmarino: I don't know what happened there. You may just  
want to comment it out and post the problem to the list. I can take a  
look at it or Jeremy or Raymond will
[12:35pm] jmarino: I think Sun's maven repo is iffy
[12:36pm] isilval__: yeah, I'll take another look at that thread to  
make sure I'm not missing anything and post to the list if I still  
can't build
[12:36pm] jmarino: k in the meantime I'll be on IRC here if you have  
questions
[12:36pm] isilval__: great, thx
[12:36pm] jmarino: thanks too for jumping in
[12:37pm] isilval__: sure, should be fun
[12:37pm] jmarino: yea looking forward to seeing this get in since I  
think it is going to be one of the "wow" features
[12:38pm] isilval__: cool
[12:38pm] jmarino: k ttyl
[12:38pm] isilval__: ttfn

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org