Daniel, Looking at the invocation code for OSGi and Java which creates the instances for conversations, there shouldn't be any difference between the two (except that OSGi instance creation takes much longer).
One of the differences between implementation.java and implementation.osgi is that the default scope for OSGi is COMPOSITE, but the default for Java is STATELESS. In your code, do you set the scope for Alpha? If Alpha uses COMPOSITE scope, and you call Alpha.doSomething() with @OneWay twice, as far as I can tell you may end up with either one conversation or two (either one Gamma object or two), depending on timing. And this should be true even if you are using implementation.java with COMPOSITE scope (I dont know whether this is the expected behaviour for SCA, but from the code it looks that way). Is your initialize method called from Tuscany (is it annotated with @Init, and does it have a corresponding @Destroy)? In the failing case, do you see two Gamma objects being created and calls to 'initialize' for both? Is it possible that the same Gamma object is being used in both calls, and the first one calls 'stop' while the second call has not yet completed? Sorry I am asking more questions instead of providing answers. If your test case is small could you raise a JIRA and attach the testcase? On 4/8/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi Rajini, > > Yes, after adding classes to my .composite file the Scope is found. > Now, if Alpha.doSomething() is executed twice (one after the other > without using @OneWay) it works and each call uses different > ConversationIDs. > > However, if I annotate Alpha.doSomething() with @OneWay and call > Alpha.doSomething() twice (now executed in "parallel") it behaves > strangely. Some more details: > > This is the sequence in that Gamma is accessed: > 1x Gamma(), constructor does nothing but a println > 1x initialize(), initializes members > Nx doSomethingElse() , performs some actions on members > 1x stop(), closes the conversation > > When debugging the two calls to Alpha.doSomething() one after another, I > see that Gamma() is called twice and that in initialize() two different > ConversationIDs are created and reused in doSomethingElse() and it works > without any error > > If I only set a breakpoint in Gamma.initialize() my JVM crashes: > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d794743, pid=2708, > tid=3612 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_10-b03 mixed mode) > # Problematic frame: > # V [jvm.dll+0x64743] > # > # An error report file with more information is saved as > hs_err_pid2708.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > > If I simply execute the test, most of the time I get a NullPointer in > doSomethingElse(), because a member of Gamma is null. In some rare cases > the test runs correctly. > If I add "synchronize" to method initialze(), the test runs without any > errors, using the correct ConversationIDs. > > This seems to be some kind of threading problem, but as there are two > instances of Gamma I can't see any problem in my code. Besides, as I > said in a previous mail, without using implementation.osgi the test runs > well. > > > Bye, > Daniel > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thank you... Regards, Rajini
