Re: Seasonal djinn blues...

[Peter]

Thanks Bill,

Sounds interesting, let us know how you get on, maybe you could send us 
some screen shots and we could feature it on our website?


There's an updated version of Browser available at the following link, 
it uses the River 3.0 Startable interface, which was introduced to 
support safe publication of services after construction, so it might 
make a better starting point, don't mind the pun :).


https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/browser

Regards,

Peter.


On 11/12/2017 8:03 PM, bill pickup wrote:

  Dear Peter,
Thanks for offering a patch, but that won't be necessary, as I can work around 
the shutdown problem by just dumping the JVM through System#exit(..), and the 
sluggishness problem by just being patient.
 I checked the shutdown bug on 3.0.1 and it still persists in a modified 
form, in that the enigmatic thread, 'Thread-1', is left in 
LockSupport#parkNanos(..), so in locking. I ran the Mickey Mouse shutdown test 
a few times to make sure it wasn't a racy problem.
 To give some context to the source of these slight concerns, I'm trying to 
build a replacement for the now tired 'browser' that comes with the 
distribution. The new stuff uses JavaFX, so will run on Java 7 and 8, 
hopefully. I've got as far as event-driven controls for registrars and group 
membership, and will look to other functionality of the 'browser' in fleshing 
out the candidate. It looks like it's going to be quite a simple application, 
so easily modifiable, which can't be said for the 'browser' any more, 
unfortunately.
Kind regards,
Bill
 On Sunday, December 10, 2017, 10:35:21 PM GMT, Peter  
wrote:

  Thanks Bill,

I suspect the thread bug was fixed in 3.0.1, are you able to confirm?

I think I can provide a fix for sluggish discovery.

One of the changes with River 3.0 was to remove instances of unsafe
publication, that is allowing a reference to "this" to escape during
object construction.

LookupDiscovery was changed to implement Startable (which allows threads
to start and safe publication to occur after construction), and
LookupDiscoveryManager was also changed, to ensure safe publication.

LookupDiscoveryManager utilises LookupDiscovery to perform discovery.

I suspect the problem is LookupDiscovery starts before the safe
publication of LookupDiscoveryManager, so that LDM is not notified
immediately, becuase LookupDiscovery doesn't have a reference to it yet.

It will be a simple fix to delay starting of LookupDiscovery until after
LookupDiscoveryManager publication is complete.

Would you like me to provide a patch?

Regards,

Peter.

On 11/12/2017 12:53 AM, bill pickup wrote:

   Hi Peter,
More from theseasonal djinn…
So, I had a littlemore patience with River 3.0’s unadorned 
LookupDiscoveryManager,and it did indeed recognised the existence of an already 
running 3.0djinn, but only after a fashion. River 2.3.3’sLookupDiscoveryManager 
recognises the same djinn immediately.
Also noted was atermination concern with 3.0’s LookupDiscoveryManager, which 
keepthreads
   sun.misc.Launcher$AppClassLoader@blah_thread-0,andThread-1 (?)
running permanently.
The former is a bitof a bind, but the latter can be worked around with a system 
exit of0, much as must be done in QA.
Kind regards,



Bill


   On Sunday, December 10, 2017, 7:01:49 AM GMT, Peter   
wrote:

   Hi Bill,

Are you trying to discover a lookup service provided by River 2.2.X?

Which version of discovery are you using?  V2 is now enabled by default
in 3.0.X, you won't discover any V1 lookup services unless you enable it
by passing in a ConstrainableLookupLocator using InvocationConstraint
with DiscoveryProtocolVersion.ONE to LookupDiscoveryManager's constructor.

If you're still using V1, I'd suggest using LookupLocators to support
both discovery versions 1 and 2, which should allow you to migrate off
version 1.

Version 1 discovery has been deprecated and will likely be removed in a
future version of River, for now at least, it can still be re-enabled.

If this isn't the cause, can you enable the loggers for LookupDiscover
and LookupDiscoveryManager and send us the output?

Regards,

Peter.





On 9/12/2017 11:42 PM, bill pickup wrote:

Hi all. Season’s greetings… well, almost.
Apologies for coming over the dev@ wire, but the user@ wire seems to be 
defunct. Anyway, I’m designing something for River, so I don’t feel too bad.
I’m having problems with LookupDiscoveryManager in 3.0.0 and 3.0.1. My call is 
simple,
 new LookupDiscoveryManager(LookupDiscovery.ALL_GROUPS, null, 
(DiscoveryListener) this);
but this refuses to discover anything. However, it works in 2.2.3, for the same 
djinn.
Is something broken?

Kind regards,
Bill

Re: Seasonal djinn blues...

[bill pickup]

 Dear Peter,
Thanks for offering a patch, but that won't be necessary, as I can work around 
the shutdown problem by just dumping the JVM through System#exit(..), and the 
sluggishness problem by just being patient.
I checked the shutdown bug on 3.0.1 and it still persists in a modified 
form, in that the enigmatic thread, 'Thread-1', is left in 
LockSupport#parkNanos(..), so in locking. I ran the Mickey Mouse shutdown test 
a few times to make sure it wasn't a racy problem.
To give some context to the source of these slight concerns, I'm trying to 
build a replacement for the now tired 'browser' that comes with the 
distribution. The new stuff uses JavaFX, so will run on Java 7 and 8, 
hopefully. I've got as far as event-driven controls for registrars and group 
membership, and will look to other functionality of the 'browser' in fleshing 
out the candidate. It looks like it's going to be quite a simple application, 
so easily modifiable, which can't be said for the 'browser' any more, 
unfortunately.
Kind regards,
Bill
On Sunday, December 10, 2017, 10:35:21 PM GMT, Peter  
wrote:  
 
 Thanks Bill,

I suspect the thread bug was fixed in 3.0.1, are you able to confirm?

I think I can provide a fix for sluggish discovery.

One of the changes with River 3.0 was to remove instances of unsafe 
publication, that is allowing a reference to "this" to escape during 
object construction.

LookupDiscovery was changed to implement Startable (which allows threads 
to start and safe publication to occur after construction), and 
LookupDiscoveryManager was also changed, to ensure safe publication.

LookupDiscoveryManager utilises LookupDiscovery to perform discovery.

I suspect the problem is LookupDiscovery starts before the safe 
publication of LookupDiscoveryManager, so that LDM is not notified 
immediately, becuase LookupDiscovery doesn't have a reference to it yet.

It will be a simple fix to delay starting of LookupDiscovery until after 
LookupDiscoveryManager publication is complete.

Would you like me to provide a patch?

Regards,

Peter.

On 11/12/2017 12:53 AM, bill pickup wrote:
>  Hi Peter,
> More from theseasonal djinn…
> So, I had a littlemore patience with River 3.0’s unadorned 
> LookupDiscoveryManager,and it did indeed recognised the existence of an 
> already running 3.0djinn, but only after a fashion. River 
> 2.3.3’sLookupDiscoveryManager recognises the same djinn immediately.
> Also noted was atermination concern with 3.0’s LookupDiscoveryManager, which 
> keepthreads
>      sun.misc.Launcher$AppClassLoader@blah_thread-0,and    Thread-1 (?)
> running permanently.
> The former is a bitof a bind, but the latter can be worked around with a 
> system exit of0, much as must be done in QA.
> Kind regards,
>
>
>
> Bill
>
>
>      On Sunday, December 10, 2017, 7:01:49 AM GMT, Peter  
>wrote:
>
>  Hi Bill,
>
> Are you trying to discover a lookup service provided by River 2.2.X?
>
> Which version of discovery are you using?  V2 is now enabled by default
> in 3.0.X, you won't discover any V1 lookup services unless you enable it
> by passing in a ConstrainableLookupLocator using InvocationConstraint
> with DiscoveryProtocolVersion.ONE to LookupDiscoveryManager's constructor.
>
> If you're still using V1, I'd suggest using LookupLocators to support
> both discovery versions 1 and 2, which should allow you to migrate off
> version 1.
>
> Version 1 discovery has been deprecated and will likely be removed in a
> future version of River, for now at least, it can still be re-enabled.
>
> If this isn't the cause, can you enable the loggers for LookupDiscover
> and LookupDiscoveryManager and send us the output?
>
> Regards,
>
> Peter.
>
>
>
>
>
> On 9/12/2017 11:42 PM, bill pickup wrote:
>> Hi all. Season’s greetings… well, almost.
>> Apologies for coming over the dev@ wire, but the user@ wire seems to be 
>> defunct. Anyway, I’m designing something for River, so I don’t feel too bad.
>> I’m having problems with LookupDiscoveryManager in 3.0.0 and 3.0.1. My call 
>> is simple,
>>        new LookupDiscoveryManager(LookupDiscovery.ALL_GROUPS, null, 
>>(DiscoveryListener) this);
>> but this refuses to discover anything. However, it works in 2.2.3, for the 
>> same djinn.
>> Is something broken?
>>
>> Kind regards,
>> Bill
>>
>

  

Re: Seasonal djinn blues...

[Peter]

Thanks Bill,

I suspect the thread bug was fixed in 3.0.1, are you able to confirm?

I think I can provide a fix for sluggish discovery.

One of the changes with River 3.0 was to remove instances of unsafe 
publication, that is allowing a reference to "this" to escape during 
object construction.


LookupDiscovery was changed to implement Startable (which allows threads 
to start and safe publication to occur after construction), and 
LookupDiscoveryManager was also changed, to ensure safe publication.


LookupDiscoveryManager utilises LookupDiscovery to perform discovery.

I suspect the problem is LookupDiscovery starts before the safe 
publication of LookupDiscoveryManager, so that LDM is not notified 
immediately, becuase LookupDiscovery doesn't have a reference to it yet.


It will be a simple fix to delay starting of LookupDiscovery until after 
LookupDiscoveryManager publication is complete.


Would you like me to provide a patch?

Regards,

Peter.

On 11/12/2017 12:53 AM, bill pickup wrote:

  Hi Peter,
More from theseasonal djinn…
So, I had a littlemore patience with River 3.0’s unadorned 
LookupDiscoveryManager,and it did indeed recognised the existence of an already 
running 3.0djinn, but only after a fashion. River 2.3.3’sLookupDiscoveryManager 
recognises the same djinn immediately.
Also noted was atermination concern with 3.0’s LookupDiscoveryManager, which 
keepthreads
 sun.misc.Launcher$AppClassLoader@blah_thread-0,andThread-1 (?)
running permanently.
The former is a bitof a bind, but the latter can be worked around with a system 
exit of0, much as must be done in QA.
Kind regards,



Bill


 On Sunday, December 10, 2017, 7:01:49 AM GMT, Peter  
wrote:

  Hi Bill,

Are you trying to discover a lookup service provided by River 2.2.X?

Which version of discovery are you using?  V2 is now enabled by default
in 3.0.X, you won't discover any V1 lookup services unless you enable it
by passing in a ConstrainableLookupLocator using InvocationConstraint
with DiscoveryProtocolVersion.ONE to LookupDiscoveryManager's constructor.

If you're still using V1, I'd suggest using LookupLocators to support
both discovery versions 1 and 2, which should allow you to migrate off
version 1.

Version 1 discovery has been deprecated and will likely be removed in a
future version of River, for now at least, it can still be re-enabled.

If this isn't the cause, can you enable the loggers for LookupDiscover
and LookupDiscoveryManager and send us the output?

Regards,

Peter.





On 9/12/2017 11:42 PM, bill pickup wrote:

Hi all. Season’s greetings… well, almost.
Apologies for coming over the dev@ wire, but the user@ wire seems to be 
defunct. Anyway, I’m designing something for River, so I don’t feel too bad.
I’m having problems with LookupDiscoveryManager in 3.0.0 and 3.0.1. My call is 
simple,
   new LookupDiscoveryManager(LookupDiscovery.ALL_GROUPS, null, 
(DiscoveryListener) this);
but this refuses to discover anything. However, it works in 2.2.3, for the same 
djinn.
Is something broken?

Kind regards,
Bill

Re: Seasonal djinn blues...

[bill pickup]

 Hi Peter,
More from theseasonal djinn…
So, I had a littlemore patience with River 3.0’s unadorned 
LookupDiscoveryManager,and it did indeed recognised the existence of an already 
running 3.0djinn, but only after a fashion. River 2.3.3’sLookupDiscoveryManager 
recognises the same djinn immediately.
Also noted was atermination concern with 3.0’s LookupDiscoveryManager, which 
keepthreads
sun.misc.Launcher$AppClassLoader@blah_thread-0,andThread-1 (?)
running permanently.
The former is a bitof a bind, but the latter can be worked around with a system 
exit of0, much as must be done in QA.
Kind regards,



Bill


On Sunday, December 10, 2017, 7:01:49 AM GMT, Peter  
wrote:  
 
 Hi Bill,

Are you trying to discover a lookup service provided by River 2.2.X?

Which version of discovery are you using?  V2 is now enabled by default 
in 3.0.X, you won't discover any V1 lookup services unless you enable it 
by passing in a ConstrainableLookupLocator using InvocationConstraint 
with DiscoveryProtocolVersion.ONE to LookupDiscoveryManager's constructor.

If you're still using V1, I'd suggest using LookupLocators to support 
both discovery versions 1 and 2, which should allow you to migrate off 
version 1.

Version 1 discovery has been deprecated and will likely be removed in a 
future version of River, for now at least, it can still be re-enabled.

If this isn't the cause, can you enable the loggers for LookupDiscover 
and LookupDiscoveryManager and send us the output?

Regards,

Peter.





On 9/12/2017 11:42 PM, bill pickup wrote:
> Hi all. Season’s greetings… well, almost.
> Apologies for coming over the dev@ wire, but the user@ wire seems to be 
> defunct. Anyway, I’m designing something for River, so I don’t feel too bad.
> I’m having problems with LookupDiscoveryManager in 3.0.0 and 3.0.1. My call 
> is simple,
>      new LookupDiscoveryManager(LookupDiscovery.ALL_GROUPS, null, 
>(DiscoveryListener) this);
> but this refuses to discover anything. However, it works in 2.2.3, for the 
> same djinn.
> Is something broken?
>
> Kind regards,
> Bill
>

  

Re: Seasonal djinn blues...

[Peter]

Hi Bill,

Are you trying to discover a lookup service provided by River 2.2.X?

Which version of discovery are you using?  V2 is now enabled by default 
in 3.0.X, you won't discover any V1 lookup services unless you enable it 
by passing in a ConstrainableLookupLocator using InvocationConstraint 
with DiscoveryProtocolVersion.ONE to LookupDiscoveryManager's constructor.


If you're still using V1, I'd suggest using LookupLocators to support 
both discovery versions 1 and 2, which should allow you to migrate off 
version 1.


Version 1 discovery has been deprecated and will likely be removed in a 
future version of River, for now at least, it can still be re-enabled.


If this isn't the cause, can you enable the loggers for LookupDiscover 
and LookupDiscoveryManager and send us the output?


Regards,

Peter.





On 9/12/2017 11:42 PM, bill pickup wrote:

Hi all. Season’s greetings… well, almost.
Apologies for coming over the dev@ wire, but the user@ wire seems to be 
defunct. Anyway, I’m designing something for River, so I don’t feel too bad.
I’m having problems with LookupDiscoveryManager in 3.0.0 and 3.0.1. My call is 
simple,
 new LookupDiscoveryManager(LookupDiscovery.ALL_GROUPS, null, 
(DiscoveryListener) this);
but this refuses to discover anything. However, it works in 2.2.3, for the same 
djinn.
Is something broken?

Kind regards,
Bill