Raised and submitted fix under FELIX-363 for this [Re: Anyone had issues with subsequent Framework creation & start in single Applet VM lifecycle]

[Rob Walker <ro...@ascert.com>]

Seems my hunch was correct, and that an Applet VM can kill or cause 
death of global EventDispatcher thread preventing further Felix instance 
launches within the same browser session.

Have raised and committed a fix for this under FELIX-363

-- Rob

Rob Walker wrote:
>> Richard S. Hall wrote:
>>> On a older version of the trunk we had a bug where the global event 
>>> thread was being killed between successive instance of Felix...are 
>>> you on 1.0.0 or on trunk?
>>>
> I have a hunch this may be a subtle *nasty* variation on the scenario 
> FELIX-314 fixes.
>
> The following code is the actual dispatcher thread itself:
>
>            // Start event dispatching thread if necessary.
>            if (m_thread == null)
>            {
>                m_thread = new Thread(new Runnable() {
>                    public void run()
>                    {
>                        EventDispatcher.run();
>                    }
>                }, "FelixDispatchQueue");
>                m_thread.start();
>            }
>
> FELIX-341 has put safety code in to ensure that thread isn't killed if 
> there is still a +ve usage count.
>
> However - if the thread "dies" or is killed by some external cause 
> then I think we can get a scenario where m_thread != null , but the 
> thread has ended.
>
> I suspect - in my Applet based environment. The VM managed by the 
> browser is actually forcable killing any remaining threads - so 
> although the internal Felix state shows this thread as still running, 
> it has in fact been killed by the VM.
>
> I'll do some experimentation and see if I can prove if this is what is 
> causing the issue we're seeing here
>
> Regards
>
> -- Rob

Re: Raised and submitted fix under FELIX-363 for this [Re: Anyone had issues with subsequent Framework creation & start in single Applet VM lifecycle]

[Rob Walker <ro...@ascert.com>]

Yep - taxed my overworked brain a shade chasing this one down.

I'm stll having 1 or 2 Applet based instance issues - but I think 
they're now within our application code.

If I do find any other boundary cases along these lines I'll re-commit 
any extra mods needed

-- Rob

Richard S. Hall wrote:
> Interesting, thanks Rob!
>
> -> richard

Re: Raised and submitted fix under FELIX-363 for this [Re: Anyone had issues with subsequent Framework creation & start in single Applet VM lifecycle]

["Richard S. Hall" <he...@ungoverned.org>]

Interesting, thanks Rob!

-> richard

Rob Walker wrote:
> Seems my hunch was correct, and that an Applet VM can kill or cause 
> death of global EventDispatcher thread preventing further Felix 
> instance launches within the same browser session.
>
> Have raised and committed a fix for this under FELIX-363
>
> -- Rob
>
> Rob Walker wrote:
>>> Richard S. Hall wrote:
>>>> On a older version of the trunk we had a bug where the global event 
>>>> thread was being killed between successive instance of Felix...are 
>>>> you on 1.0.0 or on trunk?
>>>>
>> I have a hunch this may be a subtle *nasty* variation on the scenario 
>> FELIX-314 fixes.
>>
>> The following code is the actual dispatcher thread itself:
>>
>>            // Start event dispatching thread if necessary.
>>            if (m_thread == null)
>>            {
>>                m_thread = new Thread(new Runnable() {
>>                    public void run()
>>                    {
>>                        EventDispatcher.run();
>>                    }
>>                }, "FelixDispatchQueue");
>>                m_thread.start();
>>            }
>>
>> FELIX-341 has put safety code in to ensure that thread isn't killed 
>> if there is still a +ve usage count.
>>
>> However - if the thread "dies" or is killed by some external cause 
>> then I think we can get a scenario where m_thread != null , but the 
>> thread has ended.
>>
>> I suspect - in my Applet based environment. The VM managed by the 
>> browser is actually forcable killing any remaining threads - so 
>> although the internal Felix state shows this thread as still running, 
>> it has in fact been killed by the VM.
>>
>> I'll do some experimentation and see if I can prove if this is what 
>> is causing the issue we're seeing here
>>
>> Regards
>>
>> -- Rob
>