Forum Discussion
Jim_Morgan_4481
Nimbostratus
NimbostratusWeb Accelerator not responding to iControl invalidation commands
We have an eCommerce site and need to be able to invalidate the cache programatically under certain conditions (e.g. a product goes out of stock and we don't want the product page to show a Buy Now button). We also invalidate the entire cache on a daily basis after our stock and price updates. We currently do this now with our old Piva v4 servers. We have been told that we could do this with v10 using iControl. We have tried several methods to do this, but the cache is not being invalidated.
Things we have tried:
1. Using the provided Perl script
2. Using soapUI to send the message and look at the results. We get the response but the cache is not invalidated.
3. Using a Java class along with the iControl assembly iControl.jar (recompiled under JDK 1.4.2)
In all cases, we are not seeing the cache invalidated. We have tried both the invalidate_content as well as the esi_invalidate_content methods.
We've tried with putting START_INVALIDATION_MESSAGE:b2c in front of the xml as well as without it. I can send the exact same message to our v4 server (without the START_INVALIDATION_MESSAGE) and the cache invalidates. In all cases, we are Base64 encoding it as it shows in the Perl script:
Message must be Base64 encoded inorder to send in SOAP message
my $encoded_message = encodeBase64($message);
We can get SystemInfo just fine using soapUI and Java (haven't tried it with Perl) so we know we are able to connect and get good responses back
If I login to the admin console and invalidate the entire cache there, it works just fine as well.
We need to get iControl working so we can put these servers into our production environment and retire our v4 servers.
- Are you manually base64 encoding the information or are you letting the script do it?
It's difficult to diagnose without the actual script. Would you be able to paste the script - you can remove the sensitive information.
The cache invalidated message will appear even if an error occurs such as not matching an application or any content in the cache. The applicatin name being passed into the command needs to be identical to what is defined in the application maping section of WebAccelerator. 
Jim_Morgan_4481Dawn,
I've attached the test_f5.inv file and a file with the SOAP message and response we get when using soapUI to send the message to iControl.
It looks like this content isn't displaying in my earlier post.
The invalidation message in the soap file is base 64 encoded. If you decode it, it is the same as the test message in the test_f5.txt file.
Thanks,
Jim- Jim_Morgan_4481Hi Dawn,
One more thing. The 10.2.0 version of iControl Assembly is missing web proxy in the Interfaces class. We added this and I've uploaded Interfaces.java (renamed with .txt so it would upload) with the m_WebAcceleratorProxyMessage interface in it.
Regards,
Jim - Thanks for the files. Maybe I'm missing it but I'm not seeing where you are passing in the name of the application?
- Jim_Morgan_4481Hi Dawn,
It is the first line of the invalidation message:START_INVALIDATION_MESSAGE:b2c Our applications are b2c and c2c (see .jpg). Regards, Jim Greetings. Your actual XML message in test_f5.txt is valid; it works for me with the appropriate change to the app name and the URI.
I have not looked at your Java program. But here is a pearl of wisdom followed by a very simple example which you might use as a better starting example than the rather sordid Perl script to which I think you're referring.
Search your log /var/log/tomcat/catalina.out for an error similar to this:
Exception in thread "Thread-5" java.lang.NullPointerException at com.f5.wa.esi.server.InvalidationSocketServer.processInvalidation(InvalidationSocketServer.java:157) at com.f5.wa.esi.server.InvalidationSocketServer.run(InvalidationSocketServer.java:103) at java.lang.Thread.run(Unknown Source)If this error occurred since last time you restarted tomcat, then you will find yourself in an unfortunate predicament, a predicament subversive to developing your working invalidation script. Because subsequent iControl calls to the method will silently fail in the meantime even with a properly base64 encoded XML message. Restart the tomcat service for to recover.
tmsh restart sys service tomcatThe condition occurs after certain invalid / corrupt messages to esi_invalidate_content, which makes it easily stumbled upon trying to develop a new script.
That Python example is attached. It seems to require more effort than it's worth to render it correctly within the posting.- Jim_Morgan_4481Well, I found out I was indeed crashing the Invalidation Server process. After restarting Tomcat, I'm able to invalidate the cache using both soapUI and Perl, but not with the iControl assembly java library.
I'm using the org.apache.commons.codec.binary.Base64 library to do the encoding. I'm reading the invalidation message into a StringBuffer from a file. Here are the pertinent lines of code:
m_interfaces.initialize(F5address, 443, UserName, Password);
m_interfaces.getWebAcceleratorProxy().esi_invalidate_content(Base64.encodeBase64(sb.toString().trim().getBytes()));
The compiles just fine and as far as I can tell, should work fine. However, everytime I run this I get the Null Pointer exception and need to restart Tomcat.
I'm also outputting the encoded message as a string. If I take this and paste it into soapUI, it works fine. The content gets invalidated and there are no exceptions.
At this point, I'm wondering if anybody is doing this using Java and the iControl assembly code?
Thanks in advance - Jim_Morgan_4481Hi,
I just wanted to post an update to anybody following this. In the end, all we doing thru iControl is sending the invalidation messages. After struggling to get the iControl assembly to work with this, we just went back to plain old Java objects without any specialized SOAP libraries.
I'm just manually creating the entire message including the envelope. I'm using a plain old URL HttpURLConnection (and overriding the TrustManager so we don't care about getting a valid cert back). I add the required headers, send the message over to the iControl.cgi and then get the entire SOAP response back.
This returns a void in any case, so we don't need to parse it. We'll just log the return result so if there are any issues (say password changed, no connection, etc) we'll see them.
So, that is the work around we are going to use to send these messages using Java.
One thing that would be nice for a future release is to fix the NullPointerException in the server code.Exception in thread "Thread-5" java.lang.NullPointerException at com.f5.wa.esi.server.InvalidationSocketServer.processInvalidation(InvalidationSocketServer.java:157) at com.f5.wa.esi.server.InvalidationSocketServer.run(InvalidationSocketServer.java:103) at java.lang.Thread.run(Unknown Source) At times we need to do on the fly page invalidation where we'll be hand crafting the xml message. Regards, Jim Morgan - > fix the NullPointerException in the server code.
That's bug number 226509 and your support case has been linked to it. Thank you Jim.
Dale
