Thanks Gregg,
It works well in testing and allows a maximum of 256 remote object
between two nodes over a JERI endpoint.
Is anyone approaching 128 remote object in deployment?
If no one objects in the next week, I'll assume lazy concensus.
Regards,
Peter.
On 3/09/2019 1:31 AM, Gregg Wonderly wrote:
I think considering an unsigned byte value should be a reasonable step.
Gregg
Sent from my iPhone
On Sep 1, 2019, at 9:41 PM, Peter Firmstone<peter.firmst...@zeus.net.au> wrote:
Hello,
The JERI multiplexing protocol allows 128 sessions between two nodes, when this
value is exceeded, an exception is thrown and a connection cannot be made.
I have run into some situations during stress testing where 128 sessions isn't
enough.
The JERI multiplexing protocol sends a signed byte, the allowable range is from
0 to 127 (inclusive) and consumes it at the remote end.
However I have noticed in the implementation, checks for maximum and minimum
sessions occurs while the number is a 32 bit integer, before being cast to
byte, so basically we can change this to an unsigned byte, without breaking
compatibility with existing implementations (until we exceed 128 sessions).
Using an unsigned byte would allow a maximum 255 Sessions.
As both endpoints have to consume a byte, increasing this value further would
break the protocol.
Existing connections break when the number of sessions exceeds 128, this will
not cause any unexpcected additional breakage.
I'm not aware of any additional third party implementations of the JERI
protocol.
It's also worth noting that the JERI implementation of today, is much faster
and more efficient than JERI released in Jini 2.1, 128 connections would have
suffereed from contention, today, this isn't an issue.
Regards,
Peter.
