Hi everybody.

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:

• FP_OPTION_OPENSTRATEGY = FP_LAZY_OPEN
• FP_OPTION_MULTICLUSTER_READ_STRATEGY = FP_REPLICATION_STRATEGY
• FP_OPTION_MULTICLUSTER_READ_CLUSTERS = FP_NO_REPLICA_CLUSTERS
• FP_OPTION_ENABLE_MULTICLUSTER_FAILOVER = true
• new FPClip(centeraPool,ca,FPLibraryConstants.FP_OPEN_ASTREE);  --> that's the long call !

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!

Filippo

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?