Connection Delay to Centera

Hi there

Do you have a replica centera in your network?  The connection should take around 2 seconds so I suspect that you may have a replica which the SDK will attempt to connect to and if its remote on the network then thats what might give you the 28secs connection.

Having said that 28 secs is not too bad as you should only do the connection once for the lifetime of the service.  Another thing you may want to look at is the lazy open option but let me know if I'm correct about the replica centera

We do have a replica Centera and it is offsite.  I never would have suspected that as the issue.  Is there a way to make the SDK not try to make that connection?

We are preparing the Centera to store 2 TB worth of images.  These images are called up thousands of times throughout the day by several applications.  We are utilizing a image web service as the central hub for these applications and I have placed the XAM code in the web service.  In testing I have seen the Centera connection object go out of scope and need to be recreated but that is after a lengthy time of inactivity.

By default the underlying centera sdk will probe the primary access nodes on connecting and discover the IP addresses of all AN on the primary and replica.  The default behaviour is then for the SDk to open sockets to both the primary ANs and the replica ANs in case it needs to failover reads from the primary to the replica.

You can change this by setting the Centera option FP_LAZY_OPEN on the XAMLibrary before you connect to the centera, which stops the SDK opening the connections to the replica.   Obviously now if the SDK needs to access the replica in the cases of content missing on the primary or the primary being unavailable, it will then open the connections.

You can set this by setting tyhe XAMLibrary field .vnd.com.emc.centera.open.strategy  see table 5 in the Centera_SDK_XAM_VIM_ReferenceGuide.pdf on page 29 or you can set the environment variable

FP_LAZY_OPEN=1

before you start your service.

I think the .NET wrapper  has a field LAZY_OPEN in the pool object try looking for that in the XAMLIbrary wrapped object.

I'll have a look further tomorrow, I'm not sure there is some sample code around.

I apologize but I do not know where to make this change.  Is this something I can change in code at application startup or is it something that needs to be set on the Centera by my network folks?

I have a little test application written that I use.  In it I have a method that displays the fields on a XAMObject.  When I pass in the XAMLibrary object and iterate over it's fields, I do not see the .vnd.com.emc.centera.open.strategy field.  However, when I pass in the XSystem object and iterate over it's fields, I see the field and it currently has a value of 0.  It appears that I can't create an XSystem without making a connection through the XAMLibrary so I'm not sure how I would change the value to 1 prior to making the initial connection.

If it can be done through code at application startup, could you post some sample code for me to look at?  It doesn't need to be .Net.

From the documentation:

In the legacy EMC Centera API, global and int options establish

initial settings for all pools and specific pools, respectively. Similarly,

in the EMC Centera SDK for XAM, you can set global options as

global fields on the XAM Library object. Setting options on the XAM

Library object ensures that all created XSystem instances have the

expected set of configurations. This practice is especially important

and relevant if a global option is used to effect connection behavior.

For example, if you preset the XAM Library object with the

FP_NORMAL_OPEN connection strategy, the object uses that

method to open IP connections to the XSystem after it creates the

XSystem.

In order to access symbolic names for SDK option values, it is

necessary for a XAM application to include the

FPAPI.h header file.

Including this header file allows you to use FP_NORMAL_OPEN as

an option value, instead of inserting an integer value directly. It is not

necessary to link against the FPLibrary shared library when including

I havent had a chance to look at this today but the environment variable method should work

The env variable to set is

FP_OPEN_STRATEGY=1

I tried this using shXAM.jar and the sdk log showed

1309882802895 2011-07-05 16:20:02.895  [log]  8408.7176 [API] [FPAPI_Access] Start FPPool_Open("emea2?c:\peafiles\emea2armtesting.pea")
1309882802895 2011-07-05 16:20:02.895  [debug]  8408.7176 [API] Discovered global env var 'FP_OPTION_OPENSTRATEGY' = '1'
1309882802895 2011-07-05 16:20:02.895  [debug]  8408.7176 [API] Initialize global env var 'openstrategy' = '1'
13098

I'll try and figure out how this is done in code, i have a feeling there is a documentation error and the .vnd. might need to be vnd.  (no dot at the beginning)

set

If you want to switch on the sdk logging set these two env vars as well

FP_LOGLEVEL=4
FP_LOGPATH=sdk.log

that will create a file sdk.log with detailed info.  A bit offputting to look at at first but you'll get the hang of it and this part is near the front

can you email me the sdk.log

paul.mckeown@emc.com

Ta

It seems we are on the right track.  I set the two environment variables as you suggested :

FP_LOGLEVEL=4
FP_LOGPATH=sdk.log

I then fired up shXAM and connected with this string: snia-xam://centera_vim!10.155.200.105?c:\\xam\\xamtest.pea

The connection took 28 seconds and the sdk.log file confirmed those findings with it's time stamps.  I then tried to set the environment variable

FP_OPEN_STRATEGY=1 but was having no improvement in performance.  After looking more closely at your log entries above I saw the log show the option as 'FP_OPTION_OPENSTRATEGY' = '1'.  So I gave that a try and the connection was nearly instantaneous!  I set the entry back to 0 and the connection time went back to 28 seconds.

I then fired up my test windows application that utilizes the XAMSDK and it appears to completely ignore the environment variable.  No matter what I try it continues to take 28 seconds.

I'll keep looking.  We're getting closer to solving the problem.

Use a local xam.properties file in the application directory. This is the  preferred method for XAM systems.

Do you happen to have an example of this file or can point me to some documentation that would show me how to do this?  I'm still having the issue.

Having nothing but create a xam.properties file to go by, I tried the following:

1. I created a file called xam.properties and placed it in the application directory.

2. I placed this entry in the file: com.emc.centera.open.strategy=1

3. The program reacts to the file but fails with this message: XAM Error <1014>: "xam/field is read only" [XAMLibrary_Connect]

Any ideas on how to fix this or make it do what I want?