JBossDeveloper

"ovidiu.feodorov@jboss.com" wrote:
ummmmm, Clebert .... this is a public forum, everybody can read it :)

Never mind, you go ahead, I am sure you'll figure out a way to overcome those invading Bindings, nodeIDs and routers :)

I just changed DefaultRouter on HA Branch.

I'm round robbin between local Queues and FailedQueues now.

One thing we need to identify is... when to delete a failedOver queue. Say... a queue that failed 1 week ago.. won't be accessed any more, as when the client bounces there is no way to access a failed queue any more.

I have made a couple of changes to get the actual RemotingLocator into NodeAddressInfo.

- I have made explicity the dependency between ServerPeer and Remoting JMX.

- ServerPeer now looks up for the Remoting Locator

Tomorrow I will make this to go into ConnectionFactories and start doing some load balancing and detection failure on the client side.

Anyway... I had a talk with Tim today, and we are missing:

- failure detection (server
- client side load balancing
- client side failure detectionm
- reconnection protocol

For most of this I needed the actual Remoting Locator, so I had started today doing these changes.

So... so far... so good towards the HA release what is great.


_____________
Clebert Suconic

I changed NodeAddressInfo a little bit. It now has ConnectionFactories for all the nodes on NodeAddressInfo. (Even I had to convert the factories to bytes before sending it to the cluster).

I had to do that because just the Locator is not enough to perform a connection creation.

I have also started creating a ClusteredConnectionFactory. So far I'm requiring a cluster to also have a regular connection Factory. ClusteredConnectionFactory will get already registered ConnectionFactories on ServerPeer and encapsulate them on a list that will work both as RoundRobbin Connectors and Failover in case of connection failure.

There are some issues I don't know how to solve yet... like what to do when a Server has multiple connectors. We will probably need two ClusteredConnectionFactory (one for each type of connector, for example HTTP/Socket). (I will get the basic working first and worry about multiple datasources right after this).


Also.. We have at this point two PostOffices (queue/topic). To manage the Datasource we need only one. So, I will configure ClusteredDataSource to use Queue ClusteredPostOffice as we don't need to deal with both postOffices. (Let me know if there is any objection)

Tim wrote:
...why you think you need a ClusteredConnectionFactory...

Tim wrote:
...and why you need to replicate more than the locatorURI?

 //... from superClass DelegateSupport:
 protected int id;

 //... from the class itself

 protected String serverLocatorURI;
 protected Version serverVersion;
 protected int serverID;
 protected boolean clientPing;

Tim wrote:
Replicate the whole connection factory is not a good solution IMHO

Tim wrote:
What do you mean by HAConnection, I am not aware of this term in JBoss Messaging

Tim wrote:
All you need to replicate is locator uri and server id, the rest stays the same as you mention

All you need to replicate is locator uri and server id, the rest stays the same as you mention

Tim wrote:
Have you considered just downloading the new connection factory from JNDI from the new server?

I was talking to Tom Elrod about ConnectionListeners and stuff..

I wanted to know when aConnectionListener would be called. In specifically I wanted to know if the event is called during an invocation.

Tom gave me some light that I want to keep it registered on this thread:

"Tom Elrod over IM" wrote:
The ConnectionListener can be registered on the client and server side. The server side uses leasing to tell if a client has not contacted the server within a certain amount of time and thus considers it dead and notifies the ConnectionListener. On the client side, the ConnectionListener is only there to tell the client that server has died when the client is idle (meaning not making invocations). If an invocation is made and the server is dead, there will be a CannotConnectException thrown from the invoke() method.

"Tom Elrod over IM" wrote:
on the client side, the ConnectionListener is independent of invocation calls. is just a pinger that runs concurrently with any client invocations that might be made.

I've created a new class called LeaveClusterRequest.
This request is sent over the cluster when PostOffice.stop is called.

I have added a parameter boolean to stop, when if you set it to false it will emulate a crash.

Now... viewAccept will perform a failOver if a view is changed. I still need to add some logic to have only one server accepting the failOver but that is pretty easy. I will do it probably over the holidays.


Cheers,