new HA questions

[ataylor]

Started this post really so i can post questions about the new HA functionality in Tims branch in one place.

first off.

1. should the Resource Adapater use HA by default, currently its not set and throws an NPE, i think yes.

2. I see DiscoveryGroupControl has been removed even tho discovergroup is still there, Is this functionality still covered somewhere or do I need to add it or are you hiding this from the end user.

[ataylor]

1. should the Resource Adapater use HA by default, currently its not set and throws an NPE, i think yes.

Actually this throws up another question, should we allow HA clients to connect to non HA servers (a server with no cluster connections configured). Currently if this happens the create session call timeout waiting for the cluster topology to be sent to the client, this never happens as there is no cluster topology. I'm going to try and handle this a bit better by sending a message notifying the client that the server is non ha, the client can the either:

1. throw an exception

2. falback to non ha mode and log a warning.

Can you see any issues wiith 2.

[timfox]

Andy Taylor wrote:

Started this post really so i can post questions about the new HA functionality in Tims branch in one place.

first off.

1. should the Resource Adapater use HA by default, currently its not set and throws an NPE, i think yes.

Yes. Also it should be possible to configure the RA with a list of initial servers, right now it can only be configured with one.

2. I see DiscoveryGroupControl has been removed even tho discovergroup is still there, Is this functionality still covered somewhere or do I need to add it or are you hiding this from the end user.

Each client session factory has it's own discovery group now, so it doesn't make sense to expose it as a single control.

[timfox]

Andy Taylor wrote:

1. should the Resource Adapater use HA by default, currently its not set and throws an NPE, i think yes.

Actually this throws up another question, should we allow HA clients to connect to non HA servers (a server with no cluster connections configured). Currently if this happens the create session call timeout waiting for the cluster topology to be sent to the client, this never happens as there is no cluster topology. I'm going to try and handle this a bit better by sending a message notifying the client that the server is non ha, the client can the either:

1. throw an exception

2. falback to non ha mode and log a warning.

+1

[ataylor]

a question on the core API.

when u create a ClientSessionfactory an initial connection is made to the server. subsequent create session methods use this. Once the last session is closed the factory closes the connection and sets it to null. After this any create session methods would fail. I think we should move the initialisation of the factory to its own method, initialise it on the the creation of any first session ? wdyt?

[timfox]

Once the last session is closed it shouldn't close the underlying remoting connection, this should stay open from when the ClientSessionFactory is created until the close() method on the ClientSessionFactory is called.

In JMS terms, think of the ServerLocator as the JMS connection factory and the ClientSessionFactory as the JMS connection.

[ataylor]

Tim Fox wrote:

Once the last session is closed it shouldn't close the underlying remoting connection, this should stay open from when the ClientSessionFactory is created until the close() method on the ClientSessionFactory is called.

In JMS terms, think of the ServerLocator as the JMS connection factory and the ClientSessionFactory as the JMS connection.

ok, that makes sense

[ataylor]

Question on live/backup with shared journal.

When a backup node starts up when using shared store it will negotiate via the live server using locks etc and then lock the backup lock and await failover. Theres a comment in this code that says "TODO at this point the clustermanager needs to announce it's presence so the cluster can know about the backup" implying that there needs to be a cluster connection for this to work, is this the way this should work? I think a better way would be for the backup node to write its transport connector params to a file, say 'connetor.backup' and the live server checks this file for changes, once this file has been updated by the backup server the live server updates its topology. wdyt?