Programmatically Purging EHCache in WLST

5 03 2010

In my previous blog, we discussed how to locate MBeans within the custom tree. We’re going to piggy back that discussion and show how to purge an EHCache MBean by executing the removeAll() operation.

For reference, let’s see the findMBean() helper method we defined previously:

# function to help locate a mbean(s) in the provided list
# that match a specific name
def findMBean(prefix, name):
        # get a listing of everything in the current directory
        mydirs = ls(returnMap='true');

        found = [];
                
        # we're going to use a regular expression for our test
        pattern = java.util.regex.Pattern.compile(str(escape(prefix)) + str('.*name=') + str(escape(name)) + str('.*$'));
                
        # loop through the listing
        for mydir in mydirs:
                x = java.lang.String(mydir);
                matcher = pattern.matcher(x);
                # if we find a match, add it to the found list
                while matcher.find():
                        found.append(x);
                
        return found;

In review, this method returns a list of MBean names that meet the regular expression in the current custom tree node (non-recursively). Once we have this list of names, we can then act on them. Here is our method:

def purgeCache(cacheDirNames):
        if len(cacheDirNames) > 0:
                # for each match, let's purge it
                for cacheDirName in cacheDirNames:
                        print 'Purging cache ' + str(cacheDirName);
                        cd(cacheDirName);
                        params = jarray.array([], java.lang.Object);
                        sig = jarray.array([],java.lang.String);
                        invoke('removeAll', params, sig);
                        #important, must do before we move on to the next cache
                        cd('..');
        else:
                print 'No cache found for ' + str(cache);

Let’s decompose this method. The parameter cacheDirNames is the list of MBean names return from the previous findMBean() call. We’re going to loop through each one of these names and execute the appropriate removal method. The meat of the purging process happens in lines 6 through 11.

On line 6, we perform the cd() API call on the MBean name. Within WLST, WebLogic treats MBean as a node of the tree. By “changing directory” into this node, we’ll have access to all of the attributes and operations on this MBean.

On lines 7 through 9, we are preparing to and invoking the operation on the MBean. The invoke() API requires that we provide the method name to be called, removeAll, the signature of the parameter list for the operation (in our case nothing, thus a blank list), and the actual parameters passed to the operation (in our case a blank list of java.lang.Objects). Finally we call the invoke API with the appropriate parameters, invoke(‘removeAll’, params, sig).

On line 11, we call cd(‘..’) to change to the parent of the currently operated on MBean node. This is important if the next loop in the cycle is to work appropriately. Remember on line 6, we entered the custom MBean node, so we need to exit to the parent before beginning work on the next MBean in the list.

Putting this all together, finding the custom EHCache MBean and purging it of it’s contents can be performed as such:

# connect to our server
connect('weblogic', 'welcome1', 't3://localhost:7001');
        
# change to our custom tree
custom();
        
# navigate to the appropriate location in our custom tree
cd('net.sf.ehcache');
        
# find our mbean(s)
mybean = findMBean('net.sf.ehcache:type=Cache,CacheManager', 'com.ericmiles.fishing.Angler');
        
# purge our mbean
purgeCache(mybean);
        
# be nice and tidy up
disconnect();

Reference
Purge WLST Script

Advertisements




Finding Custom MBeans in WLST

4 03 2010

My collegue Ron DiFrango recently wrote a blog about exposing custom MBeans within the WebLogic container. Both Ron and myself experienced similar frustrations when trying to work with custom MBeans and his blog is a must read if you’re having difficulty finding yours.

Once the container is setup as directed in Ron’s blog, you’ll quickly notice that several of WLST’s APIs for navigating do not work in the custom tree; most notably is the find API. The lack of a find API is especially troubling when you have MBeans such as ones for EHCache that use the memory location as part of the unique identifier, for example:

net.sf.ehcache:type=CacheStatistics,CacheManager=net.sf.ehcache.CacheManager@6c20c8,name=com.ericmiles.fishing.Angler

This value will change from server start to server start making programmatic navigation to this bean an issue. We’ll need to create our own finder method that we can reuse when we need to find custom MBeans such as these.

We’re in a Jython environment so Python and Java functionality are both available to leverage. I don’t have much experience with python, so most of my scripting in WLST has Java leanings. Here is a simple custom finder method I have written:

# function to help locate a mbean(s)
# that match a specific name
def findMBean(prefix, name):
        # get a listing of everything in the current directory
        mydirs = ls(returnMap='true');

        found = [];
                
        # we're going to use a regular expression for our test
        pattern = java.util.regex.Pattern.compile(str(escape(prefix)) + str('.*name=') + str(escape(name)) + str('.*$'));
                
        # loop through the listing
        for mydir in mydirs:
                x = java.lang.String(mydir);
                matcher = pattern.matcher(x);
                # if we find a match, add it to the found list
                while matcher.find():
                        found.append(x);
                
        return found;

At a high level, this method searches a specific directory tree (non-recursively) for a bean that matches a specific prefix and naming pattern and returns these references in a list. Let’s decompose the contents of the method.

On line 5 of the listing, we are calling the WLST API ls(returnMap=true) to perform a directory listing on the current tree which will return a reference to an object we can work with, rather than merely directing output to the console.

On line 10 of the listing, we are compiling our regular expression for pattern matching use. The prefix parameter is usually a domain specific naming convention, that helps uniquely identify the MBean. The name is the name of the object. Using the sample EHCache MBean name previously identified, in this example the prefix would be net.sf.ehcache:type=CacheStatistics,CacheManager and the name would be com.ericmiles.fishing.Angler. By using this prefix variable, we should be able to find any MBean we need to within the custom tree. The call to escape() is merely performing some escaping of the string to prepare it for regex use.

On lines 13 through 18, we’re looping through all the found objects in the current tree and checking for matches against our regular expression. If a match is found, we add it to our return list. Here is a sample listing of how we could use this method to locate an MBean in a known location within our tree.

#change to the custom tree
custom();
cd('net.sf.ehcache');
mybean = findMBean('net.sf.ehcache:type=Cache,CacheManager', 'net.sf.ehcache:type=Cache,CacheManager');

#do something with your bean

The call to escape prepares the string for regex creation.That’s all there is to it. Notice how we changed into the appropriate tree with the cd() call. This method could have been written to recursively look through all trees in the custom tree, however I didn’t want the overhead associated with that. With this limitation known, you must navigate to the appropriate location within the custom tree to find your bean.