Unsolved
This post is more than 5 years old
1 Rookie
•
90 Posts
0
5234
September 1st, 2010 00:00
SDK not probing all IP adresses?
Hello,
A customer of ours reported an issue when the first of the four IP adresses specified in the connection string to FPPool_Open() became unavailable for some reason. The customer claims the other three addresses were still available but despite that, the call to FPPool_Open() failed with the following error information returned from the SDK ( and below are placeholders. Actual names were used in the connection string):
ECode = -10020, SysECode = 0, EClass = 1, Msg = no primary cluster found, EStr = FP_NO_POOL_ERR, Trace = ClusterCloud::getPrimaryCluster(0) \ \pea_file.PEA)<_FPPool_Open(192.168.122.146,192.168.122.147,192.168.122.148,192.168.122.149?\\ \ \pea_file.PEA) \ \pea_file.PEA)
The application log also shows that the "open" calls only took about 6-7 seconds to error out, whereas SDK documentation says the retry period for a non-responding IP address is one minute.
Only FP_OPTION_OPENSTRATEGY=FP_LAZY_OPEN option was set, no other global options used. The SDK version is 3.2.607
Why did the FPPool_Open() call fail when 3 of the 4 addresses were still available? Why did it take only few seconds to fail instead of 60 seconds? Is this a bug or expected behavior with FP_LAZY_OPEN strategy? Will switching to FP_NORMAL_OPEN strategy make the SDK actually probe all specified addresses if the firts IP address fails to respond?
Thank you,
Albert Pomortsev
Principal Software Engineer,
Global360, Inc.
mckeown_paul
409 Posts
0
September 1st, 2010 03:00
Hi there
I've never know the SDK to not move onto the the 2nd 3rd or 4th etc IP address in the connection string. Your comment on it failing after 6 or 7 secs is interesting as it should take longer to timeout.
The lazy open option only effects the SDK behaviour for pool opens when there is a replica - I assume this is not the case here?
If you had an SDK log then that would shine more light on the problem but at the moment I'm afraid I do not have an answer.
bkycyfplwhwxbkb
7 Posts
0
September 1st, 2010 12:00
Thanks, I'll try to obtain the log.
bkycyfplwhwxbkb
7 Posts
0
September 2nd, 2010 11:00
Hello,
The customer generated the SDK logs (please see attached) and they clearly show that with "lazy open" strategy only the first IP address in the connection string is probed and the FPPool_Open() call fails as soon as connection to that single address fails. In the logs the "149" is a fake, non-responding address and "147" is an actual Centera address. I was able to reproduce the issue myself using the US3 online cluster. Is this an expected behavior or a bug?
Thanks,
Albert.
2 Attachments
LazyOption.txt
DefaultOption.txt
mckeown_paul
409 Posts
0
September 8th, 2010 03:00
thnis looks to me to be a bug. Have the customer place a support call into EMC Customer Services
bkycyfplwhwxbkb
7 Posts
0
September 8th, 2010 12:00
Thank you!