On Thu, Aug 27, 2009 at 12:40 PM, Simon Laws<[email protected]> wrote:
> On Thu, Aug 27, 2009 at 12:01 PM, ant elder<[email protected]> wrote:
>> On Thu, Aug 27, 2009 at 11:29 AM, ant elder<[email protected]> wrote:
>>> On Thu, Aug 27, 2009 at 11:19 AM, Simon Laws<[email protected]> 
>>> wrote:
>>>>> Nothing is throwing any "target not found" type exceptions. And
>>>>
>>>> It's currently an AxisFault. To make this make sense in this special
>>>> binding.sca case you'll have to reinstate the binding.sca invoker [1]
>>>> to trap the exception and wrap it with something that the RuntimeWire
>>>> can spot.
>>>>
>>>> Simon
>>>>
>>>
>>> In the testcase this is all local with two nodes within the single jvm
>>> so using the local sca binding not the WS based one so there's no
>>> AxisFault.
>>>
>>>  ...ant
>>>
>>
>> To make this a bit clearer, this is the stack trace of the reference
>> invocation just before it fails:
>>
>> Thread [main] (Suspended (breakpoint at line 42 in StatelessScopeContainer))
>>        StatelessScopeContainer<KEY>.getWrapper(KEY) line: 42
>>        JavaImplementationInvoker.invoke(Message) line: 100
>>        PassByValueInterceptor.invoke(Message) line: 61
>>        SCABindingInvoker.invoke(Message) line: 61
>>        PassByValueInterceptor.invoke(Message) line: 61
>>        JDKInvocationHandler.invoke(InvocationChain, Object[], RuntimeWire,
>> EndpointReference) line: 277
>>        JDKInvocationHandler.invoke(Object, Method, Object[]) line: 142
>>        $Proxy10.sayHello(String) line: not available
>>        HelloworldImpl.sayHello(String) line: 40
>>        NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
>> available [native method]
>>        NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
>>        DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
>>        Method.invoke(Object, Object...) line: 597
>>        JavaImplementationInvoker.invoke(Message) line: 136
>>        PassByValueInterceptor.invoke(Message) line: 61
>>        SCABindingInvoker.invoke(Message) line: 61
>>        PassByValueInterceptor.invoke(Message) line: 61
>>        JDKInvocationHandler.invoke(InvocationChain, Object[], RuntimeWire,
>> EndpointReference) line: 277
>>        JDKInvocationHandler.invoke(Object, Method, Object[]) line: 142
>>        $Proxy10.sayHello(String) line: not available
>>        StopStartNodesTestCaseFIXME.testCalculator() line: 76
>>
>> That scope container at the top is actually in a STOPPED state but
>> nothing in the getWrapper call path checks that so eventually it gets
>> an NPE. We could (should) change that so it notices the scope
>> container is stopped and throws an exception. The
>> SCABindingInvoker.invoke call could then catch that exception and do
>> something, I guess thats where you're suggesting inserting the
>> initInvocationChains call. If the service node has been moved from
>> being local to be remote we actually need to change the
>> SCABindingInvoker impl from being the local sca binding to be the
>> remote one. I wonder if we need a new generic SCA binding impl that
>> can handle both local and remote invocations based on whether the
>> endpoint is local or remote.
>>
>>   ...ant
>>
>
> Sounds right to me. Catch the exception in the
> SCABindingInvoker.invoke and turn it into something the runtime wire
> understands.  If you rebuild the chains it should rebuild the binding
> invoker etc. for you based on the configuration of the endpoint
> reference.
>
> Simon
>

Ok I've committed some changes to get that working for the
StopStartNodesTestCase. Its limited to that specific scenario and
seems quite fragile, it wont be working for different scopes,
different wiring, callbacks, non-java implementations etc, and I
expect its causing wire rebuilds when it catches exceptions for other
errors not related to the service node being restarted. I'm wondering
if it wouldn't be more robust to do the earlier suggestion of just
having the sca binding look up the endpoint from the endpoint registry
on each invocation.

   ...ant

Reply via email to