CORBA.FAILURE getting a component after reloading its container

[marco-buttu]

I think there is an issue in Python (I do not know in C++ or Java) after reloading the container. I am using the latest ACS release (2017-02). Here is a test that fails (the complete file is in attachment), because the last but one line raises a CORBA.FAILURE:

    def test_get_component_after_reloading_container(self):
        component = self.client.getComponent(self.component_name)
        foo = component.find_characteristic('foo')
        # Stop the container
        self.container.stop()
        self.container.wait_until_not_running()
        # Restart the container
        self.container.start()
        self.container.wait_until_running()
        # Get again the component, but it is the same if you do not do it
        component = self.client.getComponent(self.component_name)
        foo = component.find_characteristic('foo')  # BOOM!
        self.assertEqual(foo, [])

Basically, if I get the component, stop the container, re-start the container, and get again the component, then at the first use of the component (calling a method, for instance) I get a CORBA.FAILURE. After that everything works fine (if you catch the exception...).

test_get_component.py.txt

[acaproni]

Marco, the reference to the component should be valid even after restarting the container i.e. you should not need to get the component again. Did you try to call a method of the component after resrting the container but without getting the component again?

[marco-buttu]

Commit c8ee545 is just a workaround I am using to fix the problem. I am not sending a pull request because I hope someone can find the time to investigate and fix the issue from the root...

[marco-buttu]

Hi @acaproni , thanks :-) unfortunately, it is the same :( If you comment the getComponent() line in the test, you get again a CORBA.FAILURE

[bjeram]

could you try the same from Object Explorer? B.

…

On 23/06/2017 11:31, Marco Buttu wrote: I think there is an issue in Python (I do not know in C++ or Java) after reloading the container. I am using the latest ACS release (2017-02). Here is a test that fails (the complete file is in attachment), because the last but one line raises a |CORBA.FAILURE|: |def test_get_component_after_reloading_container(self): component = self.client.getComponent(self.component_name) foo = component.find_characteristic('foo') # Stop the container self.container.stop() self.container.wait_until_not_running() # Restart the container self.container.start() self.container.wait_until_running() # Get again the container component = self.client.getComponent(self.component_name) foo = component.find_characteristic('foo') # BOOM! self.assertEqual(foo, []) | Basically, if I get the component, stop the container, re-start the container, and get again the component, then at the first use of the component (calling a method, for instance) I get a |CORBA.FAILURE|. After that everything works fine (if you catch the exception...). I will send a pull request, but it is just a workaround I am using to fix the problem. I hope someone can find the time to investigate the fix the issue from the root. test_get_component.py.txt <https://github.com/ACS-Community/ACS/files/1097324/test_get_component.py.txt> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#54>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJJOrhxYNLcz4z_cuU6FnSNJzZWW9cSoks5sG4XcgaJpZM4ODV6Y>.

[marco-buttu]

@bjeram , no issue with object explorer, so I think it only happens from the Python side.

[tstaig]

Sorry for the delay, I have ran into this issue before too. I don't know if you have had luck with this (other than the workaround). But it doesn't seem to be a bug, but rather a design decision made by OmniORBpy:
http://www.omniorb-support.com/pipermail/omniorb-list/2011-February/030906.html
The alternative to the try/catch you're doing would be to install a system exception handler, to automatically retry once, hence hiding the need to try/catch every time you are under this condition. See:
http://omniorb.sourceforge.net/omnipy3/omniORBpy/omniORBpy004.html
Section 4.7 explains the details about system exeption handlers for OmniORBpy, for your situation you're specially interested in section 4.7.3. Hope this helps.

I can confirm that both TAO and JacORB didn't make the same design decision and work right away with the existing reference after restarting the container.