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

Move Ice.Admin creation to createObjectAdapter in C++ #2653

Closed

Conversation

bernardnormier
Copy link
Member

@bernardnormier bernardnormier commented Aug 18, 2024

This PR moves the creation and activation of the Ice.Admin object adapter from Ice::initialize to Communicator::createObjectAdapter in C++.

Ultimate goal:
I want to keep initialize synchronous, and both Communicator::createObjectAdapter/ObjectAdapter::activate should be asynchronous. See these API in TypeScript and #2624.

I would also like to eliminate Ice.Admin.DelayCreation. Now that the creation of Ice.Admin is always "delayed" until the application creates an OA, there should be no need for this property.
However, we rely on this property for the IceGrid/replicaGroup test. I don't understand why, and replacing it by IceGrid.Admin.Enabled=0 didn't help.

See

<property name="Ice.Admin.DelayCreation" value="1"/>

@@ -1577,20 +1577,6 @@ IceInternal::Instance::finishSetup(int& argc, const char* argv[], const Ice::Com
{
pluginManagerImpl->initializePlugins();
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is/was the only "async" activity in Ice::initialize.


adapters = _adapters;

_instance = nullptr;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Refactored this code to avoid calling instance->getAdmin() with _mutex locked. (even putting aside lock-acquisition order concerns, getAdmin should be async and therefore should not be called within a mutex lock).

@@ -59,7 +59,6 @@
<object identity="${server}" type="::Test::TestIntf2"/>
</adapter>
<property name="Identity" value="${replicaGroup}"/>
<property name="Ice.Admin.DelayCreation" value="1"/>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This setting was apparently not needed.

@@ -55,6 +55,9 @@ Sub::run(int argc, char** argv)
throw invalid_argument(os.str());
}

// With "mx", this creates the Ice.Admin object adapter.
auto adapter = communicator->createObjectAdapterWithEndpoints("SingleAdapter", "default");
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved here because one test (most likely by accident) relies on a "Xxx ready" getting printed before failing to connect to the topic manager. Failing before "Xxx ready" => test fails.

// this object adapter, as the endpoint(s) for this object adapter
// will most likely need to be firewalled for security reasons.
//
ObjectAdapterPtr adapter;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed deprecated IceBox.ServiceManager OA. As far as I can tell, we didn't test it anywhere.

string managerProxy;
if (properties->getIceProperty("Ice.Default.Locator").empty())
{
string managerEndpoints = properties->getIceProperty("IceBox.ServiceManager.Endpoints");
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed this deprecated code too.

@@ -238,23 +238,6 @@ generated from the section label.
<suffix name="MessageSizeMax" />
</class>

<class name="deprecatedthreadpool" prefix-only="true">
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

deprecatedthreadpool and deprecatedobjectadapter were used only by the deprecated IceBox.ServiceManager OA.

Copy link
Member

@externl externl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless I'm missing something this makes the Admin OA unusable for "client only" applications that never create an Object Adapter.

@bernardnormier
Copy link
Member Author

As Joe pointed out, a big issue with this PR is plugin initialization can create and activate object adapters. So moving getAdmin to createObjectAdapter is not sufficient to make Communicator::initialize "sync".

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

Successfully merging this pull request may close these issues.

2 participants