Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mtsComponentManager::Connect() returns true even when interfaces fail to connect. #43

Open
Will-McMahan opened this issue Mar 14, 2016 · 2 comments

Comments

@Will-McMahan
Copy link

Hi,

I'm seeing some unexpected behavior using v1.0.6 on Ubuntu 14.04. When running the return value for mtsComponentManager::Connect() appears to be returning TRUE even when the interfaces were not successfully connected. In the code below, I expect the printed value ret to be 0, but I'm seeing 1.

#include <cisstMultiTask/mtsTaskManager.h>

int main ( int argc, char *argv[] )
{

    cmnLogger::SetMask ( CMN_LOG_ALLOW_DEFAULT );
    cmnLogger::SetMaskClassAll ( CMN_LOG_ALLOW_DEFAULT );
    cmnLogger::SetMaskFunction ( CMN_LOG_ALLOW_DEFAULT );
    cmnLogger::SetMaskDefaultLog ( CMN_LOG_ALLOW_DEFAULT );
    cmnLogger::AddChannel ( std::cout, CMN_LOG_ALLOW_DEFAULT );

    // Component manager
    mtsComponentManager *taskManager = mtsComponentManager::GetInstance();

    bool ret = taskManager->Connect ( "", "", "", "" );
    std::cout << "***" << ret << "***" << std::endl;

    return 0;
}
@adeguet1
Copy link
Collaborator

Hello,

In the initial implementation, the Connect method was just a lookup in maps of components and interfaces to figure out if the connections was feasible and could return something useful. Since we introduced a multi-process layer, the Connect method is just sending a request to a global component manager, potentially in a different process/different computer. Unfortunately, the request is not blocking so there is no easy way in the current implementation to know if the connection was possible or not. This is a known limitation and we hope to fix it.

For now, users tend to rely on two mechanisms to see if their interfaces are connected:

Anton


Anton Deguet
www.lcsr.jhu.edu

On Mar 14, 2016, at 4:03 PM, William McMahan notifications@github.com wrote:

Hi,

I'm seeing some unexpected behavior using v1.0.6 on Ubuntu 14.04. When running the return value for mtsComponentManager::Connect() appears to be returning TRUE even when the interfaces were not successfully connected. In the code below, I expect the printed value ret to be 0, but I'm seeing 1.

#include <cisstMultiTask/mtsTaskManager.h>

int main ( int argc, char *argv[] )
{

cmnLogger::SetMask ( CMN_LOG_ALLOW_DEFAULT );
cmnLogger::SetMaskClassAll ( CMN_LOG_ALLOW_DEFAULT );
cmnLogger::SetMaskFunction ( CMN_LOG_ALLOW_DEFAULT );
cmnLogger::SetMaskDefaultLog ( CMN_LOG_ALLOW_DEFAULT );
cmnLogger::AddChannel ( std::cout, CMN_LOG_ALLOW_DEFAULT );

// Component manager
mtsComponentManager *taskManager = mtsComponentManager::GetInstance();

bool ret = taskManager->Connect ( "", "", "", "" );
std::cout << "***" << ret << "***" << std::endl;

return 0;

}

Reply to this email directly or view it on GitHub #43.

@Will-McMahan
Copy link
Author

Thanks for the response Anton.

My use case here was to create an automated integration test using assertions that could verify that the tasks used in our primary application were properly defined. This failed test would remind a developer that they have to change both sides of an interface.

From the two mechanisms you described, i'll either need to parse the cisstLog.txt. Or have each task with a required interface also have a TestReqInterfaceConnection() method which runs each of the execution methods and checks the execution results. Is there a more direct mechanism I could use?

Thanks for the help.

P.S. I'd suggest making a change in the doxygen to indicate that the Connect method as currently implemented always returns True.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants