Hi Rajini,
> 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?
Yes, I use scope COMPOSITE in Alpha. I just tried STATELESS with the
same result (same problem).
> 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).
This is not what I expected. I don't understand why it is not
deterministic how many instances of Gamma are created. To handle 2
different "sessions" one needs 2 instances of Gamma, or you have to do
the work in Gamma itself (using static members and selfmade session
ids). But this is exactly what I expected from @Conversational resp.
Scope CONVERSATION.
I also testet it with two instances of Alpha -> same result.
So this behavior looks like a bug to me.
> Is your initialize method called from Tuscany (is it
> annotated with @Init, and does it have a corresponding
> @Destroy)?
No, I did not use @Init. My initialize() method has a parameter (to
configure Gamma) which is not allowed by @Init.
I also did not use @Destroy.
I only annotated stop() with @EndConversation.
When exactly would methdos anotated with @Init and @Destroy be executed
? The documentation says "... is called when the scope defined for the
local servic implemented by this class starts/ends." Does that mean
- Constructor
- @Init
- some methods (e.g. in my initialize(), doSomethingElse())
- @EndConversation
- @Destroy
Would usage of either @Init or @Destroy be of any help with my problem?
>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?
Well, the Constructor is called two times creating two different
objects. Initialize() then creates 2 different ConversationIDs.
Is there anything special to take care about when getting the
ServiceReference to Gamm in Beta ?
Here is a code snippet of Beta:
public CallableReference<Gamma> getRef(Config config)
{
ServiceReference<Gamma> gammaRef =
componentContext.getServiceReference(Gamma.class, "gamma");
Gamma dynamicGamma = gammaRef.getService();
dynamicGamma.initialize(config);
return gammaRef;
}
So Alpha should not able to call any methods on Gamma before
initialize() was executed in Beta and the ServiceRefference returned to
Alpha.
Of course because of multithreading if there is some internal bug, a
call stop() on the first refference to gamma could affect the 2nd
refference to Gamma, causing the problems. However, the errors happen
both before and after stop() was called, so I think this is not the
case.
I just noticed, that if an error occurs, the Constructor of Gamma is
called three times, not just two times !?
This is getting really strange ...
> 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?
No need to apologize, I'm glad for every kind of feedback. And your
answers/questions were all very helpful.
I'll check if I can provide a testcase.
Bye,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
