You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Mark Combellack (JIRA)" <tu...@ws.apache.org> on 2007/10/19 16:42:50 UTC

[jira] Created: (TUSCANY-1860) Tuscany does not support performing call backs using a separate thread to the original invoking thread

Tuscany does not support performing call backs using a separate thread to the original invoking thread
------------------------------------------------------------------------------------------------------

                 Key: TUSCANY-1860
                 URL: https://issues.apache.org/jira/browse/TUSCANY-1860
             Project: Tuscany
          Issue Type: Improvement
          Components: Java SCA Core Runtime
    Affects Versions: Java-SCA-1.0
         Environment: SVN Head revision #586349
Linux
            Reporter: Mark Combellack
             Fix For: Java-SCA-Next


The current implementation of Tuscany does not allow a Component implementation to invoke the call back using a separate thread.


Consider the scenario:

    1) Client invokes a method on a Service.
    2) The Service obtains the CallableReference of the client using @Callback
    3) The Service spawns a new thread and passes the CallableReference to the thread
    4) The original calling thread from the client returns
Meanwhile - the newly spawned thread:
    5) Does some stuff
    6) Invokes the getService() on the CallableReference to get a proxy to the client
    7) Invokes the callback method on the proxy to the client
    8) The client will have it's  callback method invoked
    9) The separate thread ends as it's job is done.
 

The problem is with the way that Tuscany uses ThreadLocal to store the callback location. The newly spawned thread will not have the callback location attached to it's ThreadLocal.

The above scenario will fail at step 7 with the following exception:

Exception in thread "Timer-0" org.osoa.sca.ServiceRuntimeException: No callback wire found for /
	at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:63)
	at $Proxy12.eventNotification(Unknown Source)
	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl.receiveEvent(EventProcessorServiceImpl.java:114)
	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl.access$0(EventProcessorServiceImpl.java:102)
	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl$EventGenerator$EventGeneratorTimerTask.run(EventProcessorServiceImpl.java:193)
	at java.util.TimerThread.mainLoop(Timer.java:512)
	at java.util.TimerThread.run(Timer.java:462)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


[jira] Assigned: (TUSCANY-1860) Tuscany does not support performing call backs using a separate thread to the original invoking thread

Posted by "Simon Nash (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Simon Nash reassigned TUSCANY-1860:
-----------------------------------

    Assignee: Simon Nash

> Tuscany does not support performing call backs using a separate thread to the original invoking thread
> ------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-1860
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1860
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: Java SCA Core Runtime
>    Affects Versions: Java-SCA-1.0
>         Environment: SVN Head revision #586349
> Linux
>            Reporter: Mark Combellack
>            Assignee: Simon Nash
>             Fix For: Java-SCA-Next
>
>         Attachments: CallbackInSeparateThreadITest.patch
>
>
> The current implementation of Tuscany does not allow a Component implementation to invoke the call back using a separate thread.
> Consider the scenario:
>     1) Client invokes a method on a Service.
>     2) The Service obtains the CallableReference of the client using @Callback
>     3) The Service spawns a new thread and passes the CallableReference to the thread
>     4) The original calling thread from the client returns
> Meanwhile - the newly spawned thread:
>     5) Does some stuff
>     6) Invokes the getService() on the CallableReference to get a proxy to the client
>     7) Invokes the callback method on the proxy to the client
>     8) The client will have it's  callback method invoked
>     9) The separate thread ends as it's job is done.
>  
> The problem is with the way that Tuscany uses ThreadLocal to store the callback location. The newly spawned thread will not have the callback location attached to it's ThreadLocal.
> The above scenario will fail at step 7 with the following exception:
> Exception in thread "Timer-0" org.osoa.sca.ServiceRuntimeException: No callback wire found for /
> 	at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:63)
> 	at $Proxy12.eventNotification(Unknown Source)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl.receiveEvent(EventProcessorServiceImpl.java:114)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl.access$0(EventProcessorServiceImpl.java:102)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl$EventGenerator$EventGeneratorTimerTask.run(EventProcessorServiceImpl.java:193)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


[jira] Resolved: (TUSCANY-1860) Tuscany does not support performing call backs using a separate thread to the original invoking thread

Posted by "Simon Nash (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Simon Nash resolved TUSCANY-1860.
---------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: Java-SCA-Next)
                   Java-SCA-1.2

The fix for TUSCANY-2035 has fixed this problem as well.  I have added itest/callback-separatethread to the build under r637160.

> Tuscany does not support performing call backs using a separate thread to the original invoking thread
> ------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-1860
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1860
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: Java SCA Core Runtime
>    Affects Versions: Java-SCA-1.0
>         Environment: SVN Head revision #586349
> Linux
>            Reporter: Mark Combellack
>            Assignee: Simon Nash
>             Fix For: Java-SCA-1.2
>
>         Attachments: CallbackInSeparateThreadITest.patch
>
>
> The current implementation of Tuscany does not allow a Component implementation to invoke the call back using a separate thread.
> Consider the scenario:
>     1) Client invokes a method on a Service.
>     2) The Service obtains the CallableReference of the client using @Callback
>     3) The Service spawns a new thread and passes the CallableReference to the thread
>     4) The original calling thread from the client returns
> Meanwhile - the newly spawned thread:
>     5) Does some stuff
>     6) Invokes the getService() on the CallableReference to get a proxy to the client
>     7) Invokes the callback method on the proxy to the client
>     8) The client will have it's  callback method invoked
>     9) The separate thread ends as it's job is done.
>  
> The problem is with the way that Tuscany uses ThreadLocal to store the callback location. The newly spawned thread will not have the callback location attached to it's ThreadLocal.
> The above scenario will fail at step 7 with the following exception:
> Exception in thread "Timer-0" org.osoa.sca.ServiceRuntimeException: No callback wire found for /
> 	at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:63)
> 	at $Proxy12.eventNotification(Unknown Source)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl.receiveEvent(EventProcessorServiceImpl.java:114)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl.access$0(EventProcessorServiceImpl.java:102)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl$EventGenerator$EventGeneratorTimerTask.run(EventProcessorServiceImpl.java:193)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


[jira] Commented: (TUSCANY-1860) Tuscany does not support performing call backs using a separate thread to the original invoking thread

Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536273 ] 

Raymond Feng commented on TUSCANY-1860:
---------------------------------------

Hi, I checked in the itest under r586542. Thank you, Mark.

> Tuscany does not support performing call backs using a separate thread to the original invoking thread
> ------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-1860
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1860
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: Java SCA Core Runtime
>    Affects Versions: Java-SCA-1.0
>         Environment: SVN Head revision #586349
> Linux
>            Reporter: Mark Combellack
>             Fix For: Java-SCA-Next
>
>         Attachments: CallbackInSeparateThreadITest.patch
>
>
> The current implementation of Tuscany does not allow a Component implementation to invoke the call back using a separate thread.
> Consider the scenario:
>     1) Client invokes a method on a Service.
>     2) The Service obtains the CallableReference of the client using @Callback
>     3) The Service spawns a new thread and passes the CallableReference to the thread
>     4) The original calling thread from the client returns
> Meanwhile - the newly spawned thread:
>     5) Does some stuff
>     6) Invokes the getService() on the CallableReference to get a proxy to the client
>     7) Invokes the callback method on the proxy to the client
>     8) The client will have it's  callback method invoked
>     9) The separate thread ends as it's job is done.
>  
> The problem is with the way that Tuscany uses ThreadLocal to store the callback location. The newly spawned thread will not have the callback location attached to it's ThreadLocal.
> The above scenario will fail at step 7 with the following exception:
> Exception in thread "Timer-0" org.osoa.sca.ServiceRuntimeException: No callback wire found for /
> 	at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:63)
> 	at $Proxy12.eventNotification(Unknown Source)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl.receiveEvent(EventProcessorServiceImpl.java:114)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl.access$0(EventProcessorServiceImpl.java:102)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl$EventGenerator$EventGeneratorTimerTask.run(EventProcessorServiceImpl.java:193)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


[jira] Commented: (TUSCANY-1860) Tuscany does not support performing call backs using a separate thread to the original invoking thread

Posted by "Mark Combellack (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536234 ] 

Mark Combellack commented on TUSCANY-1860:
------------------------------------------

I believe the ability to perform a callback in a separate thread is an essential feature for Tuscany to implement for it to be used in large business applications.

The SCA specification also suggests that a ServiceReference should be able to be used by different threads.

422    1.6.3. Passing Conversational Services as Parameters
423    The service reference which represents a single conversation can be passed as a parameter to another
424    service, even if that other service is remote. This may be used in order to allow one component to continue
425    a conversation that had been started by another.

>From the above, if the service is Remote then it must be in a separate thread.


480    Continuing conversations
481    The client can continue an existing conversation, by:
482    • Holding the service reference that was created when the conversation started
483    • Getting the service reference object passed as a parameter from another service, even remotely
484    • Loading a service reference that had been written to some form of persistent storage

>From the above, there is little point in persisting the ServiceReference and retrieving it in the same thread. The persist and retrieve are likely to be done in separate threads.


> Tuscany does not support performing call backs using a separate thread to the original invoking thread
> ------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-1860
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1860
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: Java SCA Core Runtime
>    Affects Versions: Java-SCA-1.0
>         Environment: SVN Head revision #586349
> Linux
>            Reporter: Mark Combellack
>             Fix For: Java-SCA-Next
>
>         Attachments: CallbackInSeparateThreadITest.patch
>
>
> The current implementation of Tuscany does not allow a Component implementation to invoke the call back using a separate thread.
> Consider the scenario:
>     1) Client invokes a method on a Service.
>     2) The Service obtains the CallableReference of the client using @Callback
>     3) The Service spawns a new thread and passes the CallableReference to the thread
>     4) The original calling thread from the client returns
> Meanwhile - the newly spawned thread:
>     5) Does some stuff
>     6) Invokes the getService() on the CallableReference to get a proxy to the client
>     7) Invokes the callback method on the proxy to the client
>     8) The client will have it's  callback method invoked
>     9) The separate thread ends as it's job is done.
>  
> The problem is with the way that Tuscany uses ThreadLocal to store the callback location. The newly spawned thread will not have the callback location attached to it's ThreadLocal.
> The above scenario will fail at step 7 with the following exception:
> Exception in thread "Timer-0" org.osoa.sca.ServiceRuntimeException: No callback wire found for /
> 	at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:63)
> 	at $Proxy12.eventNotification(Unknown Source)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl.receiveEvent(EventProcessorServiceImpl.java:114)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl.access$0(EventProcessorServiceImpl.java:102)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl$EventGenerator$EventGeneratorTimerTask.run(EventProcessorServiceImpl.java:193)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


[jira] Updated: (TUSCANY-1860) Tuscany does not support performing call backs using a separate thread to the original invoking thread

Posted by "Mark Combellack (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Combellack updated TUSCANY-1860:
-------------------------------------

    Attachment: CallbackInSeparateThreadITest.patch

The attached CallbackInSeparateThreadITest.patch file adds a simple iTest that demonstrates the problem of callbacks in a separate thread.

> Tuscany does not support performing call backs using a separate thread to the original invoking thread
> ------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-1860
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1860
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: Java SCA Core Runtime
>    Affects Versions: Java-SCA-1.0
>         Environment: SVN Head revision #586349
> Linux
>            Reporter: Mark Combellack
>             Fix For: Java-SCA-Next
>
>         Attachments: CallbackInSeparateThreadITest.patch
>
>
> The current implementation of Tuscany does not allow a Component implementation to invoke the call back using a separate thread.
> Consider the scenario:
>     1) Client invokes a method on a Service.
>     2) The Service obtains the CallableReference of the client using @Callback
>     3) The Service spawns a new thread and passes the CallableReference to the thread
>     4) The original calling thread from the client returns
> Meanwhile - the newly spawned thread:
>     5) Does some stuff
>     6) Invokes the getService() on the CallableReference to get a proxy to the client
>     7) Invokes the callback method on the proxy to the client
>     8) The client will have it's  callback method invoked
>     9) The separate thread ends as it's job is done.
>  
> The problem is with the way that Tuscany uses ThreadLocal to store the callback location. The newly spawned thread will not have the callback location attached to it's ThreadLocal.
> The above scenario will fail at step 7 with the following exception:
> Exception in thread "Timer-0" org.osoa.sca.ServiceRuntimeException: No callback wire found for /
> 	at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:63)
> 	at $Proxy12.eventNotification(Unknown Source)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl.receiveEvent(EventProcessorServiceImpl.java:114)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl.access$0(EventProcessorServiceImpl.java:102)
> 	at org.apache.tuscany.sca.itest.EventProcessorServiceImpl$EventGenerator$EventGeneratorTimerTask.run(EventProcessorServiceImpl.java:193)
> 	at java.util.TimerThread.mainLoop(Timer.java:512)
> 	at java.util.TimerThread.run(Timer.java:462)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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