Put node down programmatically

[pedrokowalski]

Hi Guys,

I'm rather new in clustering business. Assume I have an application that is clustered on three nodes - A, B, C and that I have a standalone remote EJB client.

During network partition I understand that the client will automatically jump to another working server. Now that's fine but assume I have my application dependent on some other third-party system; I have a kind of heartbeat from the third-party system and as soon as the heartbeat stops, my application should be taken out of order.

Is there a way to programmatically "inform the JBoss" that this particular node should not be accessed by the client? Just when the heartbeat from third-party system will be back, I would also like to enlist this node to the cluster back so it's available to clients.

TL;DR: My node is working fine and is accessible for the clients, but because of some reasons I want to prevent clients from accessing it and choose another node. Is it possible?

Thanks in advance.

[rhusar]

Cześć Piotr,

I understand the problem -- if an undelying 3rd party appliance is down, you want that JBoss node to stop operating.

The question is however, what do you mean by client? HTTP? EJB? JMS?

Either way, how about having a deamon outside of JBoss that checks whether the appliciance is available / not, and in that case shutdown / boot up the server?

Rado

[pedrokowalski]

Hello Radoslav,

Thanks for your answer.

Exactly - I want to JBoss node to stop operating. I can imagine I can do this somehow on the client side, e.g. some heartbeat method called by the client which tells if the node can be connected or not. There is, however, another quesiton - can the client specifically choose which node it will connect to? Does it see the clsuter as a bunch of nodes and is aware of their number and addresses or is it just a one big box called 'cluster'?

By the client I mean a standalone remote EJB client, so the RMI/IIOP in the case of protocol names.

The deamon could do the work and I will surely use it as a workaround if none higher-level solutions exist (e.g. something like 'availability policy' defined directly in JBoss).

Thanks once again Radoslav!

[rhusar]

Exactly - I want to JBoss node to stop operating. I can imagine I can do this somehow on the client side, e.g. some heartbeat method called by the client which tells if the node can be connected or not.

For this type of sulution you could levelrage Java EE's EJB3 Interceptors, and before invoking, check the server status and throw an exception or so.

There is, however, another quesiton - can the client specifically choose which node it will connect to? Does it see the clsuter as a bunch of nodes and is aware of their number and addresses or is it just a one big box called 'cluster'?

Yes there is. The client is using a 'selector' which specifies which node to connect to. You need to implement this class: org.jboss.ejb.client.ClusterNodeSelector and this method is the one that does the work:

@Override

    public String selectNode(String clusterName, String[] connectedNodes, String[] availableNodes) {

So you will know which cluster, what are the other nodes.

This doesn't solve the problem 100% right, because of a race condition such as: while the client selected the correct node to connect to -- which was OK and online at that time -- it could have gone to the undesirable state when you dont want the clients to connect. So there absolutely must be some handling logic on the server side -- this is unavoidable.

Rado

[pedrokowalski]

Děkuji Radoslav!

The ClusterNodeSelector sounds interesting, but as you said - I think I'll just stay on the server-side.

So, being in the server-side only is there some JBoss way of putting the node down? E.g. something like:

JBossMagicAPI.putDownNode(myNode);

which wouldn't actually shutdown the node - just make it unavailable for the user.

The node is still running so I can have some background process (e.g. @Schedule) that periodically checks if the node should be operational or not.

Is it possible or do I have to fallback to some system-level daemon?

[rhusar]

Ah, sorry, I forgot to reply.

Here is a quick and ugly solution:

From CLI (or management client or whatever you prefer), remove the remoting subsystem:

/subsystem=remoting:remove

That should disable all remoting-based communication. So yes, this is the JBossMagicAPI ;-)