ERROR **: assertion failed: (GVMOMI_SESSION_CONNECTED == gvmomi_session_get_state(session))

[kindlund]

Hi,

I'm seeing the following error generated by the VIX API, when using the perl bindings:

• ERROR **: file /build/mts/release/bora-127388/bora/vim/lib/gvmomi/gvmomiSession.c: line 1155 (gvmomi_session_has_version): assertion failed: (GVMOMI_SESSION_CONNECTED == gvmomi_session_get_state(session))

aborting...

Essentially, I'm trying to test my handle recovery logic -- specifically in the case where I create host and VM VIX handles, then wait for long periods of time, and then perform actual VIX operations (such as copying files).

To simulate this activity, I have a perl script which creates the host and VM VIX handles, sleeps for a period of time, and then performs the rest of the VIX operations.

During the sleep phase, I issue a CTRL-Z to the perl script, which cases all processing to pause. After about 15 mins, I issue an "fg" to resume the perl script, at which point, I encounter the previously mentioned error.

I'm pretty sure this is a bug in the VIX library, but I wanted to find out from one of the VMware reps if this type of issue has already been reported.

-- Darien

[lemke]

While your test is suspended, there's no way for it to handle various keep-alive messages, so the server side throws out the connection assuming its dead.

[kindlund]

Okay, thanks for explaining the error -- that's exactly the type of behavior I was trying to test for. The problem is: this error generates an 'abort' at the C layer and perl CANNOT catch this exception in an eval block.

So, to deal with this scenario, I see two possible solutions:

1) Add reconnection logic to the VIX API so that this error is minimized

2) When the error does occur, make this exception/assert 'catchable' by perl's eval {} block.

Since I don't have access to the VIX source code, I can't fix this issue and need someone from VMware to either say: (1) yes, it will be fixed and there's been a ticket filed or (2) no, this fix is not supported and we will not resolve this issue.

Thanks,

Darien

[lemke · Accepted solution]

I've filed a bug that we should handle this with a proper error.

[kindlund]

Perfect! Thanks for your help. Incidentally, do you happen to know when the next version of VIX will be released? I didn't know if the dev team was on a 6 month or 1 year release schedule.

[lemke]

We (developers) can't discuss timeframes of future releases.

[kindlund]

Ok; understood. Thanks for letting me know. I'll continue to post to this forum on any other VIX-related issues that I find, since they'll be tracked by the development team.

[ScottLangham]

Hi Lemke,

As a developer myself, I understand you can't discuss timeframes. However, I'm unable to make progress with the current version of VIX and am hoping your next version might sort out some stability issues.

Is it possible that you can find someone at VMWare who can discuss timeframes and ask them to comment?

I mean, if you're going to have a new release with bug fixes done within a couple of months, I'll hang around and wait for it. But, if it's going to be many months or a year away, I'm going to have reconsider my approach to the problem I'm trying to solve.

Best regards,

-Scott