Ricky's Hodgepodge

In the previous entry an EJB clustered solution was setup that was called from a standalone java client. There it was commented that, when using another Wildfly as the client, the solution was a bit different. This entry is dedicated to this second use-case, the client will be another wildfly server placed in the same domain but in another server group and using another profile.

If you remember, the standalone java program used a properties file where the initial connections and the cluster configuration were defined. When using an application deployed in a Wildfly server the idea is exactly the same, but the connection information is defined inside the server configuration (in this case in the profile to which the server belongs to but, if using standalone mode, in the standalone.xml itself). You can find the documentation in the Wildfly project pages. Today's example will be deployed in a new server in the same domain (with a port offset of 20000), it will be a web socket that will create the EJB client. The backend will be the same application of the previous entry and deployed in the same two-instance cluster. Therefore the configuration shown today is a continuation to the one done in the previous post.

Configuring the Wildfly client

In order to configure the new client a new domain group will be used defined in the default profile (the client is going to be a web socket, this way we can do the some HA tests, so default profile is enough).

1. Create the new server group and the new server:

   
   /server-group=default-server-group:add(profile=default,socket-binding-group=standard-sockets)
   /host=master/server-config=default-server:add(group=default-server-group, socket-binding-port-offset=20000)
   /host=master/server-config=default-server:start(blocking=true)
   

   With the server up and running the EJB client configuration is needed. As you will see, the same configuration that was previously placed in the jboss-ejb-client.properties is now part of the profile.

2. Add the connection security realm which contains the user password to use with the EJB backend. The password is placed using BASE64 encoding (remember the user that was created was ejbuser with the same password). I used a simple perl command to generate the encoding of the password.

   
   perl -MMIME::Base64 -e 'print encode_base64("ejbuser")'
   ZWpidXNlcg==
   

   Now add the security realm with the encoded password:

   
   /host=master/core-service=management/security-realm=ejb-server-security-realm:add()
   /host=master/core-service=management/security-realm=ejb-server-security-realm/server-identity=secret:add(value="ZWpidXNlcg==")
   

3. Once the password is configured the binding sockets are added (here the two remote hosts are defined).

   
   /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=ejb-server-1-binding:add(host=localhost, port=8080)
   /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=ejb-server-2-binding:add(host=localhost, port=18080)
   

4. And finally the two connections are configured as outbound connections in the profile (they use the previous steps):

   
   /profile=default/subsystem=remoting/remote-outbound-connection=ejb-server-1-connection:add(outbound-socket-binding-ref=ejb-server-1-binding, protocol=http-remoting, security-realm=ejb-server-security-realm, username=ejbuser)
   /profile=default/subsystem=remoting/remote-outbound-connection=ejb-server-1-connection/property=SASL_POLICY_NOANONYMOUS:add(value=false)
   
   /profile=default/subsystem=remoting/remote-outbound-connection=ejb-server-2-connection:add(outbound-socket-binding-ref=ejb-server-2-binding, protocol=http-remoting, security-realm=ejb-server-security-realm, username=ejbuser)
   /profile=default/subsystem=remoting/remote-outbound-connection=ejb-server-2-connection/property=SASL_POLICY_NOANONYMOUS:add(value=false)
   

   Only one property is added to the connections just as an example, but you can add all the options you need to each connection.

It is important to understand that we are doing more or less the same steps that were done in the previous entry, but now in the profile instead of using the preoperties file. Until now the two connections have been defined as it was done previously with the remote.connections properties inside the file.

Configuring the client application

The WAR application will use a jboss-ejb-client.xml to configure the EJB connections and cluster (the file is placed in the WEB-INF directory of the WAR). But now the configuration just links to the outbound connections and security realm configured in the previous step. So now the file will be the following:

<jboss-ejb-client xmlns="urn:jboss:ejb-client:1.2">
    <client-context>
        <ejb-receivers>
            <remoting-ejb-receiver outbound-connection-ref="ejb-server-1-connection"/>
            <remoting-ejb-receiver outbound-connection-ref="ejb-server-2-connection"/>
        </ejb-receivers>
        <clusters>
            <cluster name="ejb" security-realm="ejb-server-security-realm" username="ejbuser">
                <connection-creation-options>
                    <property name="org.xnio.Options.SSL_ENABLED" value="false" />
                    <property name="org.xnio.Options.SASL_POLICY_NOANONYMOUS" value="false" />
                </connection-creation-options>
            </cluster>
       </clusters>
    </client-context>
</jboss-ejb-client>

Again, the idea under this configuration is exactly the same of the previous entry. The client will have two connections to try (ejb-server-1 in port 8080 and ejb-server-2 in 18080) and, once connected to one of them, the client will receive the cluster events and will maintain a pool of connections against the server members using the cluster configuration. The difference is that the main configuration is defined in the server profile instead of the file and now the client file is an XML instead of a common properties file.

Developing the client

As I said previously the client is going to be a web socket. This way the browser will connect to a web socket interface and, in turn, this endpoint will open a client against the counter EJB (this last part using the cluster). The idea of the web socket is quite simple: the ejb client will be created onOpen and destroyed onClose; the onMessage method just receives the operation (increment, decrement or current) and returns a string containing the backend server that processed the request and the current count value; the web socket has a map of the counter beans created keyed by the client web socket session id. Here it is the main class.

@ServerEndpoint("/counter")
public class CounterSocketServer {

    private static class ContextAndCounter {
        
        private final InitialContext context;
        private final RemoteCounter counter;
        
        public ContextAndCounter(InitialContext context, RemoteCounter counter) {
            this.context = context;
            this.counter = counter;
        }

        public InitialContext getContext() {
            return context;
        }

        public RemoteCounter getCounter() {
            return counter;
        }
    }
    
    private static final Map counters = new HashMap<>();
    
    @OnOpen
    public void openConnection(Session session) throws NamingException {
        InitialContext context = EjbUtils.createContext();
        RemoteCounter statefulRemoteCounter = (RemoteCounter) context.lookup(EjbUtils.getCounterBeanName());
        counters.put(session.getId(), new ContextAndCounter(context, statefulRemoteCounter));
    }
    
    @OnClose
    public void closeConnection(Session session) throws NamingException {
        ContextAndCounter pair = counters.remove(session.getId());
        pair.getContext().close();
    }
    
    @OnMessage
    public void handleMessage(String operation, Session session) {
        RemoteCounter statefulRemoteCounter = counters.get(session.getId()).getCounter();
        String result;
        if ("current".startsWith(operation)) {
            result = statefulRemoteCounter.getJbossNode() + ": " + statefulRemoteCounter.getCount();
        } else if ("increment".startsWith(operation)) {
            statefulRemoteCounter.increment();
            result = statefulRemoteCounter.getJbossNode() + ": " + statefulRemoteCounter.getCount();
        } else if ("decrement".startsWith(operation)) {
            statefulRemoteCounter.decrement();
            result = statefulRemoteCounter.getJbossNode() + ": " + statefulRemoteCounter.getCount();
        } else {
            result = "invalid operation";
        }
        session.getAsyncRemote().sendText(result);
    }
}

Demo

The three local servers are running in localhost (ejb-server-1 and 2 are the clustered backend, default-server is the client frontend). When the application page is requested the web socket and the ejb client are created. The page shows that the first backend server is processing the requests. Then some requests are executed to increment or decrement the counter, all of them in the first server. When that instance is stopped the counter is maintained and the new operations are processed by the remaining server two.

Your browser doesn't support the video tag. See this entry for more information about how to see the videos in this blog. You can download the file instead.

This entry is just a continuation of the previous post about stateful EJBs in Wildfly. When the client is used inside another Wildfly server this configuration is recommended. The underlying idea is the same (connections and cluster configuration) but now the most part of the configuration is defined inside the server profile. The application file (now an XML) just links to that information. As I said in the previous entry, there are several ways to connect a remote EJB client and server in Wildfly, but remember that those two (today's entry for Wildfly clients and the previous post for non-Wildfly ones) are the recommended and the options that take full advantage of the cluster features. The maven project for client web-socket app used in the demo can be download from here.

Clustered and remoted regards!

Long time ago I posted an article about configuring an EJB in a clustered glassfish. During this summer I had to deal with some issues about this subject but using Wildfly. I discovered that, in this container, there are several possibilities of doing a remote call to an EJB, but only one of them is the good one. So this entry is going to setup this good configuration step by step. This same option is a little different when the client is another Wildfly server (a wildfly frontend communicates with another Wildfly backend in which the EJBs are running) than when the client is a standalone java app or another container. Today's entry covers the last case, using a non-wildfly client.

Installing the Wildfly cluster

First a clustered wildfly backend needs to be installed. Both instances are going to be running in the same machine, using a port offset in the one of them. The steps are the following.

1. Install the software, create an admin user for the management console and start the domain.

   
   wget http://download.jboss.org/wildfly/10.1.0.Final/wildfly-10.1.0.Final.zip
   unzip wildfly-10.1.0.Final.zip
   cd wildfly-10.1.0.Final/bin
   ./add-user.sh -u admin -p adminadmin
   ./domain.sh
   

2. By default wildfly generates some configuration (groups and servers) that I usually remove. From now on the jboss-cli.sh command is used to configure the domain.

   
   ./jboss-cli.sh --connect
   /host=master/server-config=server-one:stop(blocking=true)
   /host=master/server-config=server-two:stop(blocking=true)
   /host=master/server-config=server-three:stop(blocking=true)
   
   /host=master/server-config=server-one:remove()
   /host=master/server-config=server-two:remove()
   /host=master/server-config=server-three:remove()
   
   /server-group=main-server-group:remove()
   /server-group=other-server-group:remove()
   

3. With an empty domain two servers are created in the ha profile. In order to have a cluster you have to use at least this profile (full-ha profile would be also ok). Please take into account that the second server will use an offset of 10000. Besides a property jboss.node.name is set to each instance with the name (this property will be used later in the EJB to know which instance is executing it).

   
   /server-group=ha-server-group:add(profile=ha,socket-binding-group=ha-sockets)
   /host=master/server-config=ejb-server-1:add(group=ha-server-group)
   /host=master/server-config=ejb-server-2:add(group=ha-server-group,socket-binding-port-offset=10000)
   
   /host=master/server-config=ejb-server-1/system-property=jboss.node.name:add(value=ejb-server-1,boot-time=true)
   /host=master/server-config=ejb-server-2/system-property=jboss.node.name:add(value=ejb-server-2,boot-time=true)
   
   /host=master/server-config=ejb-server-1:start(blocking=true)
   /host=master/server-config=ejb-server-2:start(blocking=true)
   

   The cluster will use default configuration. Wildfly use jgroups for cluster communication and this library can be configured in different ways, by default it uses udp and multicast for cluster communication and discovery. If you prefer tcp and unicast further configuration is needed.

4. Finally in order to use the EJB remotely an application user is created (this username and password will be configured in the application).

   
   ./add-user.sh -a -u ejbuser -p ejbuser
   

At this point we have two wildfly instances in cluster (ha profile) running in the same machine.

Developing the EJB server

So now is the time to implement our little stateful EJB. The interface is very simple.

public interface RemoteCounter {
 
    void increment();
 
    void decrement();
 
    int getCount();
    
    String getJbossNode();
}

The maintained state is just a counter and the last method will be used to return the jboss.node.name property (which server is attending the call). The implementation is straight forward.

@Stateful
@Remote(RemoteCounter.class)
public class CounterBean implements RemoteCounter {

    private int count = 0;

    @Override
    public void increment() {
        this.count++;
    }

    @Override
    public void decrement() {
        this.count--;
    }

    @Override
    public int getCount() {
        return this.count;
    }

    @Override
    public String getJbossNode() {
        return System.getProperty("jboss.node.name");
    }
}

Developing the client

This part is the interesting one, in a standalone java application (or using a non-wildfly app container) the configuration for the EJB is done using a jboss-ejb-client.properties which should be available in the classpath. This file defines the remote connections where the EJBs are going to be located. You can define more than one endpoint and the implementation will try to connect to them one by one. But, for a cluster setup, there is another vital part: the cluster configuration. When an EJB client connects to a server that is configured in cluster, it receives the cluster formation data (when a member in the cluster shuts down or when a member joins to the cluster). This way the client can provide clustering features (high availability, load balancing,...). The configuration that the client uses to connect to the cluster instances is the one that is defined in the cluster part of this file (I know the configuration is repeated multiple times but it was thought like this).

In summary, for my little setup the following jboss-ejb-client.properties is used:

remote.connections=ejbserver1,ejbserver2

remote.connection.ejbserver1.host=localhost
remote.connection.ejbserver1.port=8080
remote.connection.ejbserver1.protocol=http-remoting
remote.connection.ejbserver1.username=ejbuser
remote.connection.ejbserver1.password=ejbuser

remote.connection.ejbserver2.host=localhost
remote.connection.ejbserver2.port=18080
remote.connection.ejbserver2.protocol=http-remoting
remote.connection.ejbserver2.username=ejbuser
remote.connection.ejbserver2.password=ejbuser

remote.clusters=ejb
remote.cluster.ejb.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=true
remote.cluster.ejb.protocol=http-remoting
remote.cluster.ejb.username=ejbuser
remote.cluster.ejb.password=ejbuser

There are defined two connections (for each member of the cluster) and the configuration for the cluster (the connection data for each member of the cluster when members are received by the client). Think that you can omit one connection but then, if the only defined server is down when connecting, the client will fail although the second server is up and running (the cluster information is only used when the connection starts and the cluster formation information is received). Then the client is developed as shown in the jboss documentation.

InitialContext context = null;
try {
    Properties jndiProperties = new Properties();
    jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
    context = new InitialContext(jndiProperties);
    // lookup name is a bit tricky, check documentation
    String lookupName = "ejb:/stateful-ejb-wildfly/CounterBean!es.rickyepoderi.samples.ejb.RemoteCounter?stateful";
    RemoteCounter statefulRemoteCounter = (RemoteCounter) context.lookup(lookupName);
    statefulRemoteCounter.increment();
    // Use the stateful EJB
    // ...
} finally {
    if (context != null) {
        try {
            context.close();
        } catch (Exception e) {
        }
    }
}

Demo

Here you have a simple video that shows the demo EJB application in action. The server ejb-server-1 is down at the beginning so, when the client is started, it fails to connect to the first connection but establishes it with the second server. After some increments in the second server the first one is started again. The client (as the server backend is clustered) receives that a new member is active. This way when the second server is shut down the stateful EJB can continue using the new discovered first server.

Your browser doesn't support the video tag. See this entry for more information about how to see the videos in this blog. You can download the file instead.

And that is all. Remember that there are more options to configure a remote EJB client but this is the good one. If, for whatever reason, you cannot use a fixed properties file there is a programmatic way of specifying the same configuration, although I have never used it. You can download the sample application I used for this entry from here.

Best regards!

Another simple post this time. I updated my phone again with LineageOS (I was waiting if any release other than nightly was to be available, but the blueborne exploit convinced me to move now) and, again, I spent some time trying to install a custom certificate in the phone. The procedure is explained in this article in detail and it works like a charm for me.

1. To install your CA certificate you need to obtain a hash of the certificate because android expects the file to be called using this hash (this point was crucial and I had no idea about it before). So first you obtain your PEM and get the hash with the following command:

   openssl x509 -inform PEM -subject_hash_old -in calocal.crt | head -1
   xxxxxxxx
   

2. Once you have the certificate and the hash you just need to install it with the following name /system/etc/security/cacerts/xxxxxxxx.0 and the same permissions than the other CAs. Remember that the /system file system is read-only by default and you need su to do the complete process. So you have to go to Settings → Developer Options → Root Access and include ADB to it.

   $ adb shell
    daemon not running. starting it now on port 5037 
    daemon started successfully 
   $ su
   # mount -o remount,rw /system
   # cp /sdcard/Downloads/calocal.crt /system/etc/security/cacerts/xxxxxxxx.0
   # chmod 644 /system/etc/security/cacerts/xxxxxxxx.0
   # mount -o remount,ro /system
   

3. And reboot your phone. You can check that your local CA now should be listed in Settings → Security → Trusted Credentials in the System tab.

Following the procedure all my synchronizations started to work again against my personal nextcloud and runalyze servers. It's incredible that such an old phone is still maintained by lineage and now running android 7.1.2 with the September security patches from google. I have to say that my requirements for the phone are very slight.

Good job lineage team!