Hi,

Please refer to the Primus solution ID "emc151665" which explains a similar scenario. Hope this helps.

Would keep you posted once I get more information on the issue.

Regards

Satish.N.Kutty

Hi

As JCenteraVerify is ok with the pea file so should be your application.

Are there different entries for the read and write storage provider? Maybe the IP Address or name not resolving correctly?

Are you reading from a different server than the write server? If so are the firewall settings inbetween both of them and the Centera allowing acces?

Holger

Hello,

Thanks so much for the response.

The solutionID emc151665 looks very similar, but we use SDK version 3.2.661.

@Holger: Yes its really strange that JCenteraVerify is ok and yet not able to retrieve the data! I am using the same pooladdress for write and read. Also, no firewall settings enabled.

Still debugging the issue, but since the error message clears shows FP_AUTHENTICATION_FAILED_ERR, we cant make sure if its Centera problem or configuration issue on the application side.

Will update if there is any progress.

Thanks again,

D.

To add:

The software version on Centera cluster is following: 4.2.0-3881-0-0. All nodes are exactly on the same version. And the sdk used is Centera_SDK-3.2.661.

Does this have to do anything with the issue?

Hi Guys -

DJT mentions that there is a replica in the environment.  Are you using a 'merged' PEA file?  It's possible that your retrieval program is doing full authentication (rather than 'lazy' auth) upon connect where your other programs' behavior is being modified by an environment variable like FP_OPTION_OPENSTRATEGY=1 which select the 'lazy pool open' strategy.  The FP_AUTH failure could actually be coming from the replica rather than the primary Centera.

Since it sounds like your retrieval program opens a new pool coinnection to Centera for every recall, setting this environment variable will significantly speed up the pool open time as the SDK will not probe the replica chain before returning the connection.

Good Luck,

Mike Horgan

CTO, Interlock Technology

Hi

Your SDK and C* versions are not the issue.

If your .pea works with JCenteraVerify then your .pea file is also not the problem.

Please compare the .pea File on the Application Server with the one that you are using with JCenteraVerify.

Are you sure your application correctly references the .pea file? Not that the path or filename is wrong.

You can also swith on debug logging (See Powerlink Support Section, search for enable Centera SDK Logging) and send the file to holger.jakob@informatio.ch. There we could see the connect string your application is using which may provide additional information.

an authentication failed also seems to indicate the .pea or the connect string are wrong (anonymous which is disabled or stuff like that). if a firewall would prevent connections we'd get a no pool error.

Holger

Hi Mike

The SDK log shows missing MD5 libraries. These are reported missing prior to the pool open command that is launched with a reasonable IP?pea combination. Looks like the decryption of the secret already fails due to missing libraries.

Holger

Hi again,

The issue I have posted here still exists.

Based on some internet research, I did some changes but unfortunately I still cant figure out the problem.

The Centera connection works "sometimes" and fails otherwise.

I updated the SDK version to 3.2.705 and also tried changing the env path:

CENTERA_LIB_PATH="/usr/local/test/Centera_SDK/lib/64"

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$CENTERA_LIB_PATH

--Well nothing seems to change the problem.

Another concern is regarding the centera log files.

I have enabled the log for Centera with the env variable:

FP_LOGLEVEL=4

export FP_LOGLEVEL

FP_LOGPATH="/usr/local/test/current/glassfish/logs/centera1.log"

export FP_LOGPATH

---Here the the centera.log is written only when the conncetion works "sometimes". When the connection failes, the file centera.log is created but empty. This makes the debugging even more difficult.

Could you please give some possible reasons on why the centera.log is empty?

Hope you can give me some helpful hints to try.

Regards,

Deepthi

Hello all,

We still could not find the reason for the problem with the Centera connection working "sometimes".

But now as a work around we are connecting to Centera with the credentials directly, instead of the pea file.

The connection works perfectly with this configuration.

Can anyone please tell me the possible reason for the connection failure using the pea file?

And please let me know if there is any risk in using the credentials directly on the configuration.

Waiting for some response here.

Thanks,

Deepthi