Just got used to JBoss EAP 6 administration? Welcome to EAP 7! Don’t panic, it’s not a total re-write in the way that EAP 6 was. And all the basic operations of the server, the profiles, the directory structures and files, standalone and domain mode, the management console and CLI are all still there.
Having said that, EAP 7 is based on the upstream community project Wildfly version 10, which means that:
- it now exclusively supports Java 8 and JEE 7
- some of the underlying technologies have changed (e.g. messaging provider and web server)
- some new subsystems have been added (e.g. batch processing)
- sadly, one or two beloved features have disappeared
The idea of this post is to highlight the major changes from an administration perspective, rather than a development one. If you are interested in the new specifications of JEE 7 and what EAP 7 means for your existing applications, check out Red Hat’s migration guide:
Additionally, this is not an exhaustive list, more a personal selection of the changes I believe are most significant: a full list of changes is available in the official EAP 7.0 release notes:
The number of external ports needing to be exposed has been reduced right down so that you can now effectively do everything over 8080 for application access, and 9990 for management (and yes, CLI is now also accessed over 9990!). However, bear in mind that domain mode still requires your hosts to talk over the native management interface (i.e. port 9999).
On the subject of network interfaces, you now have a fourth interface, called ‘private’. This is used exclusively to keep all JGroups comms on the internal network, as opposed to exposing them publicly. You’ll notice that in the socket binding groups, this interface is used in the JGroups socket binding definitions by default:
Red Wine Jus
You can now start either a standalone server, or domain host controllers, in admin-only mode. This means that no servers are actually started (they remain in a ‘disabled’ state), but you can still perform CLI operations on them. It does also mean that the management console is unavailable. Just start the server or host with the – – admin-only switch.
You also have a new ‘suspend’ operation that allows you to effectively stop a server for all new incoming connections, but to allow existing connections to continue processing. It provides a way to do much more graceful shutdown and quiescence of servers, for example when performing rolling upgrades. On a standalone server, issue the CLI operation :suspend, and issue the :suspend-servers operation on either a server-group or the entire domain.
A really interesting new feature, which hasn’t been shouted from the rooftops of Red Hat towers, is the ability to choose how you organise your directory structure in domain mode: each host has a new attribute called ‘directory-grouping’, with the possible value options of ‘by-server’ (default) or ‘by-type’.
This means you can either keep the traditional structure:
Or re-organise as follows:
This may seem a bit esoteric, but if you think about the way you take backups or archive logs, this option could be quite appealing. What’s even more impressive is that you can change the option on-the-fly: once you’ve set the attribute, just reload the host and voila! The only gotcha is the fact that, as with previous versions, it won’t clean up after itself, so if you do decide to change, I’d advise you to delete the old, unused structures or it could get messy.
In domain mode, you can now nominate multiple domain controllers. This allows your hosts the option to discover a backup domain controller, in the event that the primary dies. By default, in host-slave.xml you have a ‘primary’ domain controller defined, and you can use the same XML format to define a backup domain controller to fail over to:
Once your hosts have the above configuration, they will initially connect to the primary domain controller, but automatically fail over to the backup as soon as the primary fails – pretty impressive stuff!
It’s now possible to do a lot more with profiles than before. New CLI operations are available to create a new profile by cloning an existing one, and also create hierarchical profiles which inherit their details from other profiles.
For example, to clone the ‘ha’ profile to a new profile called ‘new’, use the following CLI operation:
By the way, try this while domain.xml is open and it’s particularly impressive!
Now let’s say you wanted to create a new, hierarchical profile, which inherits all the settings from the ‘ha’ profile. You first need to create the new profile:
Then you can add the ‘includes’ attribute, with the name of the profile containing all the settings you want to inherit:
The resulting XML looks like this:
A few things have happened to JGroups. Firstly, you no longer define a default stack for JGroups as you used to in EAP 6. Now JGroups stacks are assigned to “channels” (to match the new ForkChannel implementation of ChannelFactory). By default, you have an “ee” channel, which is used by ejb and web applications in a cluster, and you can assign a JGroups stack (UDP, TCP, or your own) to this channel:
The other change to JGroups is the ability to configure the individual thread pools associated with the transport of each JGroups channel, as illustrated here:
Sadly, the requirement to replace the MPING directive in the default TCP stack configuration is still there!
A completely new subsystem to support batch processing has been introduced in EAP 7. I must admit to not knowing a great deal about this, mainly because it’s there to support batch applications conforming to JSR-352 (and I don’t have any!). However, what I can tell you is that you can configure settings for batch jobs, such as repositories and thread pools, you can stop, start and resume batch jobs, monitor active jobs and re-launch previously-failed jobs. This is all done courtesy of the new “batch-jberet” subsystem.
The Infinispan subsystem has undergone a few changes, but unfortunately not necessarily for the better.
The first example I’ve discovered is the disappearance of the default replicated cache in the web cache container. It’s not just the fact that ‘dist’ is now the default cache of the container: it’s the fact that ‘repl’ has actually gone completely! So, if you want your session replication to occur via a replicated rather than a distributed cache, you’re going to have to create that cache yourself, then make it the default for the web cache container.
Secondly, the way you view/change the default cache of a container in the web management console has changed. You now have to select the container, drop down the View menu and choose Container Settings. If you just click on the container (which would be the intuitive thing to do), you drill straight down to the settings for each individual cache, and by-pass the container settings:
I know the Infinispan section of the web console needed a revamp, but I’m not sure this is the answer!
As mentioned in the previous section, I’m not a huge fan of the new-look web management console. I understand it’s reflective of Wildfly 10, but in my opinion it’s a step backwards. The way you navigate through the subsystems feels clunky, there are far too many long lists that require you to scroll, there are large portions of screen real-estate unused, and it generally feels like a community offering, as opposed to the slick and professional look of its predecessor. But for me, the real nail in the coffin is the removal of the domain overview screen, which gave you a cross-section of hosts, server groups and managed servers within your domain. There is no replacement for this in EAP 7: all you get is a list of servers either by pre-selecting a host or server group. Shocking!
Buttery Biscuit Base
The final, and possible most dramatic, change in EAP 7 is the complete removal of JBoss Web (aka Tomcat). In its place comes Undertow, which is a modern NIO web server designed for much higher throughput and scalability than Tomcat. Undertow supports non-blocking and blocking handlers, traditional and asynchronous servlets, and JSR-356 WebSocket. In addition, it can act as a web-tier load balancer for EAP clusters, which was the component that was always missing in previous EAP cluster setups. But don’t worry, Undertow still supports mod_cluster (both natively and with an external Apache server if required).
There are so many changes and new features in Undertow that it really deserves it’s own blog post, so that’s what it’s going to get. In the meantime, I hope you’ve enjoyed this quick tour of EAP 7. Bye for now!
PS: If you’d like assistance with Red Hat JBoss EAP (migration, subscriptions etc) just drop us a line via the contact page https://www.tier2consulting.com/contact/