Highlighted
gopippo
1 Copper

Slowness retrieving clip from secondary with API java

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?

0 Kudos
2 Replies
mfh2
3 Argentium

Re: Slowness retrieving clip from secondary with API java

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.

Good Luck,

Mike Horgan

gopippo
1 Copper

Re: Slowness retrieving clip from secondary with API java

Thank you very much Mike!

I will try and let you know.

Filippo

0 Kudos