Using Centera (with primary and secondary configuration) we are experimenting an issue of slowness trying to retrieve files from a clip (default pool) stored in the secondary but not in primary.
We are using java API.
The string connection to the pool is like this: primary=...,secondary=...
The SDK Version is 3.0.414
The option are:
You can find in attachment the SDK log.
The weird thing is that using "C" API (with apparently same options) there are no problems, that is all run fast.
Any idea? suggestion?
Thanks in advance!
As suggested by Mike we moved to SDK Version 3.2.705. There was actually an improvement: we passed from 50 sec. to 14 sec. (that's still a lot of time confornting with "C" api, same SDK). However the thing we don't understand is that application still tries to talk to node 192.168.242.154 (see "CenteraSDK_3.2.705.log")...and that shouldn't be! We are using this connection string: primary=192.168.242.18,primary=192.168.242.19,primary=192.168.242.20,primary=192.168.242.21,secondary=192.168.242.41,secondary=192.168.242.42,secondary=192.168.242.43,secondary=192.168.242.44 Our goal is indeed to look first into primary (192.168.242.18,...) and then, if the clip is not there, into secondary (192.168.242.41,...). But it seems that Centera searches also into 192.168.242.154 (which is our "mirroring" node). Any idea about that?
Hello Filippo -
I took a quick look at this log and you can see the SDK hitting a bunch of socket errrors when trying to talk to a couple of access nodes (192.168.242.154 & 155, search for 'error=-10101' in the log). The retries on probes and connection attempts for those nodes are taking up a lot of elapsed time.
You really shouldn't be using this very old version of the SDK; I believe if you upgrade to 3.2.P5 (or 3.3 depending on your platform) you will see most of this problem go away as the retry timing logic was updated to avoid these long delays.