Forum Discussion
lucadentella_55
Nimbostratus
NimbostratusGet persistence records
Good afternoon,
I'm working on a management app for our Big-IP (BIG-IP 10.0.1 Build 378.0 Hotfix HF3) and I've some problems with a method that should get the number of persistence records for a given VirtualServer.
Here's the code I'm using:
string[] vservers = new string[1];
vservers[0] = "VS_Test";
LocalLBPersistenceMode[] modes = new LocalLBPersistenceMode[1];
modes[0] = LocalLBPersistenceMode.PERSISTENCE_MODE_NONE;
LocalLBPersistenceRecord[][] records = interfaces.LocalLBVirtualServer.get_persistence_record(vservers, modes);
The code compiles, but when I run my app I get the following exception:
Unhandled Exception: System.InvalidOperationException: There is an error in XML document (39, 51). ---> System.InvalidOperationException: Instance validation er ror: '' is not a valid value for CommonProtocolType.
If I run a similar command (bigip persist virtual VS_Test show) from a command line, it works fine.
I found an old post about a similar problem:
http://devcentral.f5.com/Forums/tabid/1082223/asg/51/showtab/groupforums/afv/topic/aff/1/aft/56693/Default.aspx
but the hotfix should be already present in newer versions...
Can you help me?
Thanks!
- This error most often indicates you aren't using the most recent version of the iControl libraries. Hopefully you are using the iControl Assembly for .Net (or library for Java). I can't tell from your code whether it's .Net or Java...
What happens is that for enumarations, the client proxy code that's generated builds a lookup for the values of the enumeration. It could be that an enumeration has been updated on 10.0.1 that that method is returning but you have an older version of the client generated code that doesn't contain the new enum value. This can be corrected by re-compiling the WSDL or updating to our latest iControl library.
Hope this helps...
-Joe 
lucadentella_55Hi Joe,
thanks for your reply... I'm using the latest version of iControl.dll for .Net (File version: 10.2.0.0) but the problem is still here.
I was able, using Fiddler, to "sniff" soap request and response:
REQUEST: http://pastebin.com/RVq3LEx3
RESPONSE: http://pastebin.com/HyttLQBg
Response is about 293Kb, could it be a problem?
Thanks!- The size isn't likely the problem. When looking through your trace, I see that the "protocol" field in the "virtual_server" structure being returned in the result array is empty. In a response from my system I get the value of "PROTOCOL_ANY" returned.
I looked trough the sources and in 10.0 this value was omitted in the response generation but it was fixed in 10.1 and above. This very likely could be your problem. I don't have a way to test this as I don't have access to a 10.0 build, but I'm fairly confident that upgrading to 10.1 or above will fix your issue with this method.xmlns:E="http://schemas.xmlsoap.org/soap/envelope/" xmlns:A="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://www.w3.org/2001/XMLSchema-instance" xmlns:y="http://www.w3.org/2001/XMLSchema" xmlns:iControl="urn:iControl" E:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> xmlns:m="urn:iControl:LocalLB/VirtualServer"> s:type="A:Array" A:arrayType="iControl:LocalLB.PersistenceRecord[][1]"> A:arrayType="iControl:LocalLB.PersistenceRecord[1]"> s:type="y:string">DC5 s:type="iControl:Common.IPPortDefinition"> s:type="y:string">10.10.10.221 s:type="y:long">80 s:type="iControl:LocalLB.PersistenceMode">PERSISTENCE_MODE_SOURCE_ADDRESS_AFFINITY s:type="y:string">192.168.44.149 s:type="iControl:Common.VirtualServerDefinition"> s:type="y:string">DC5 s:type="y:string">172.27.11.117 s:type="y:long">0 s:type="iControl:Common.ProtocolType">PROTOCOL_ANY s:type="y:long">1295440156 s:type="y:long">11
-Joe - The iControl libraries should be forward and backward compatible with the following exceptions
1. When using a newer library, you might get "method not found" exceptions at runtime if you are trying to call a method that wasn't present on a previous version of BIG-IP.
2. When using a older library, you may get the error you are seeing if you are accessing a method where an enumeration has been appended to in the newer version of the product.
Both of these situations occur very rarely but are good to know about. The best bet is to update to the latest version of the library each time a new SDK is released.
Let me know if it works in your test lab so I'll know to post something about this in the documentation.
-Joe - lucadentella_55Joe,
I can confirm you that - with my test unit (BIG-IP 10.2.0 Build 1789.0 Hotfix HF2) - my code works fine... so I asked our network team to upgrade ASAP the production units.
Thanks for your support, do you see any workaround I can use in the mean time? - No problem, always glad to help out. Looks like this is one that slipped through the cracks in our testing with 10.0.
The issue is the fact that the value is empty and the .Net bindings don't like it when that happens. The only workaround I can think of is to use a different language binding but that most likely won't be a possibility for you.
Please don't hesitate to post any future issues you have with the interfaces not behaving as expected and I'll do my best to get to the bottom of it.
-Joe
