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.0.0.1 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 18.0.0.1, 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 WebSphere:feature=kernel,name=ServerEndpointControl.

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 ConcurBMTNonJMS and EndpointBMTJMS.

Controlling the state of endpoints at runtime

In part 1 of my blog, I discussed how to use the pause() and 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:

pause(“defaultHttpEndpoint,MsgEndpointApp#MsgEndpointEJB.jar#EndpointBMTJMS”)

Similarly, I can restart the flow of inbound traffic on those two endpoints using:

resume(“MsgEndpointApp#MsgEndpointEJB.jar#EndpointBMTJMS,defaultHttpEndpoint”)

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

and:

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 activationSpec and jmsActivationSpec server configuration elements. Because of Liberty’s zero-migration policy, the default value for autoStart is 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>

With 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.

Feedback

To recap, for the Liberty 18.0.0.1 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.

1 comment on"Control traffic on server endpoints with Liberty MBeans (Part 2)"

  1. This is the feature we are waiting for.
    Thank you for implementing this great feature.

Join The Discussion

Your email address will not be published. Required fields are marked *