With the Liberty December beta, we introduced the first look at functionality that provided a new Java Management Extension (JMX) Mbean to control server endpoints, which I described in my 12/2017 blog post. In that post, I promised that we’d add control of additional endpoint types in a future release and we did so with the first quarter 2018 WebSphere Liberty 18.104.22.168 release, plus some more!
As part of our commitment to actively listen and respond to your requests for new functionality, this release delivers everything requested by Request For Enhancement (RFE) 95794 Status management function for ActivationSpec, namely starting and stopping messaging endpoints using an MBean, and the ability to control whether they automatically start when the associated application starts. Because we delivered this new function to the open source Open Liberty project, it is now available in our fully supported WebSphere Liberty 22.214.171.124, which is built on Open Liberty. Let’s look at what’s changed since the beta.
Enabling the ServerEndpointControl MBean
As discussed in my December blog post, we have created a new JMX MBean, ServerEndpointControl. In my blog post, I noted that you needed to add the
endpointControl-1.0 feature to the
featureManager of your
server.xml to enable this MBean. Now that this new function has moved from beta to released, the MBean is available without specifying any features and if you added
endpointControl-1.0 to your
server.xml, you’ll need to remove it or you’ll get a warning about an unrecognized feature. Once your server is started, you can connect using any JMX tool like JConsole (for more details, see the Knowledge Center docs). Once connected, navigate to the MBean with the ObjectName
Listing available endpoints
As discussed in my previous blog post, you can list the available endpoints of a server using the MBean operation
listEndpoints(). The results of the operation can be used to determine the ’target’ name of an endpoint, which is needed to pause or resume it. In my blog post, I noted this operation would only return
httpEndpoints but it will now also return any messaging endpoints. Here’s an example of the output from a server in which I have a default
httpEndpoint and several MDBs:
In this example, I have an installed application,
MsgEndpointApp, which has an EJB module,
MsgEndpointEJB.jar with several MDBs, including
Controlling the state of endpoints at runtime
In part 1 of my blog, I discussed how to use the
resume() operations of the MBean to control the state of endpoints. Those operations remain unchanged but I want to give you an example of pausing and resuming several endpoints at once. If I want to stop inbound traffic to both the
defaultHttpEndpoint and the
EndpointBMTJMS endpoints, I invoke the operation with a comma-separated list of targets (where a target is the endpoint name returned by the
listEndpoints() operation) like this:
Similarly, I can restart the flow of inbound traffic on those two endpoints using:
The order of the targets is not important. In part one, I didn’t discuss using the
server command to control endpoints, so I’ll take the opportunity to do so now. In that post I noted that, depending on your operational needs, you could choose to use the
EndpointControl MBean (new) or the
server command (existing). See that post for more details on why you might choose one over the other. One advantage of the
server command approach is that you don’t need any additional tools like JConsole. The
server command is the same command as used to start the server but with different parameters.
To issue the same pause/resume operations as above, you would type:
Server pause <server_name> --target=defaultHttpEndpoint,MsgEndpointApp#MsgEndpointEJB.jar#EndpointBMTJMS
server resume server_name> — target=defaultHttpEndpoint,MsgEndpointApp#MsgEndpointEJB.jar#EndpointBMTJMS
Controlling the initial state of endpoints
I mentioned earlier that we were delivering all the functionality requested by an RFE. In addition to requesting the ability to control the state of messaging endpoints using an MBean, the RFE also requested functionality that we have in WebSphere Application Server traditional: The ability to control whether a messaging endpoint is started automatically when the associated application starts.
Until now, in Liberty, if the application associated with a messaging endpoint was started, the endpoint was started. This could result in messages beginning to flow into the MDB before the application was ready. You can now control this using the new
autoStart attribute of the
jmsActivationSpec server configuration elements. Because of Liberty’s zero-migration policy, the default value for
true; if you want to change it, you’ll need to explicitly state a value of
false for the attribute like this:
<activationSpec autoStart="false" id="myActSpec"></activationSpec> <jmsActivationSpec autoStart="false" id="myJMSActSpec"></jmsActivationSpec>
autoStart set to
false, you’ll need to use either the
EndpointControl MBean or the
server command to start the messaging endpoint when you’re ready for messages to start flowing into the endpoint.
To recap, for the Liberty 126.96.36.199 release, we have added a new endpoint control MBean that allows you to query and control the state of both HTTP and messaging endpoints. You can also now control the state of message endpoints using the existing
server command. And, finally, you can now configure whether the messaging endpoint starts automatically with the associated application.
Thanks for your feedback, particularly via the RFE process, which is one of the ways you can help us prioritize our Liberty development efforts.