WFLYCTL0379: System boot is in process; execution of remote management operations is not currently available

[M K]

Hi,

we are trying to read some values from the WildFly configuration during the deployment of our application. We are basically using the following code:

try (ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990))
{
    ModelNode rootAddress = Operations.createAddress(...);
    ModelNode op = Operations.createReadAttributeOperation(rootAddress, ...);

    final ModelNode result = executeAndEvaluateResult(client, op);
    return Operations.readResult(result).get(...).asString();
}

On most of our machines this works fine, but on some machines we receive the following error:

WFLYCTL0379: System boot is in process; execution of remote management operations is not currently available

Maybe some timing concidences? I want to add that we always want to access the local server where our application is being deployed, so it's not "remote management" per se.

This leads us the following questions:

1. Do you have any idea why this works sometimes?
   
2. How can we properly access our local WildFly configuration during the deployment of our application from our application?

Thank you very much in advance!

Greetings

Manuel

[M K]

It could be that it works when starting WildFly and deploying our application from IntelliJ, but not when starting WildFly standalone with our EAR in the deployments directory. It would make sense that WildFly is in a different state because of these different deployment methods. Anyhow, question 2 still stands, thanks in advance!

[Jean Francois Denise]

Hi,

you should implement a retry in case you connect to a starting server. For example, in WildFly CLI we do: https://github.com/wildfly/wildfly-core/blob/main/cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java#L1463

JF.

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/ca0ad504-dc55-481c-b91f-1ff258174aeen%40googlegroups.com.

[M K]

Thanks for your reply. When is the server done starting? Only when all deployments are done?

I can give try/catch/retry a shot, but I don't think I can delay all these calls until deployment is done. The values are needed during the bootstrap process of our application and I don't know if deployment will ever finish without successfully reading the configuration.

I'll probably need a way to get the configuration during starting of the server. Is there a way?

Greetings

Manuel

[M K]

As I feared, this just ends with the server in a deadlocked state. So another idea would be to delay deployment until WildFly is fully started and the management interface is available.

Can anyone help with delaying deployment until WildFly is fully started by using the provided Windows Service?

Thanks in advance!

Greetings

Manuel

[Yeray Borges Santana]

Hello M K,

Management Operations for external callers are only available when your server has booted up. The server receives a set of management operations read from the configuration file and once all the management operations have finished, the server transitions to running and allows the execution of new management operations. Executing management operations meanwhile the server is starting could mess up the server configuration and how it starts.

Managed deployments (deployments done via management API [standalone@localhost:9990 /] deploy ....) are saved in your configuration file, so they are also translated to management operations. The server will wait for all deployments before being ready to accept new operations externally (JMX, Management Clients, Web Console ...). I think the server could allow read-only management operations once he knows the handlers for those management operations are ready, but that will require a request for enhancement (RFE) and should be discussed and the changes justified.

As Jean Francois commented before, so far the only approach is a retry strategy. As soon as the deployment operation finishes (successfully or failed) you should be able to execute more operations, so I understand you should not get into a deadlock state with a retry strategy.

Out of curiosity, what do you need to read when your server is starting?

On Tue, Oct 31, 2023 at 6:36 AM M K <mko...@gmail.com> wrote:

As I feared, this just ends with the server in a deadlocked state. So another idea would be to delay deployment until WildFly is fully started and the management interface is available.

Can anyone help with delaying deployment until WildFly is fully started by using the provided Windows Service?

You could rely on the deployment scanner and do your deployments in a manual mode where deployment markers are used to control them. You have to copy your deployment into $WFLY_HOME/standalone/deployments folder, disable the auto-deploy facility of the deployment scanner and write deployment markers on the $WFLY_HOME/standalone/deployments directory, for example, ensure your manual deployment uses the .skipdeploy marker when you are starting your server, and then mark your deployment with .dodeploy when you are ready to deploy it.

Take a look at $WFLY_HOME/standalone/deployments/README.txt

 

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/1ebc47b4-7c50-439b-9620-b0ff6e4b20e6n%40googlegroups.com.

[M K]

Hi,

thanks for your extensive reply!

As stated above a retry strategy does lead us to a deadlocked server. We are reading the path to the key store and the key store and key manager passwords from the configuration. We need these to initialize a JWS web service (that might be a legacy way) and to migrate encrypted passwords in our database to a better cipher. Both of these have to happen during deployment, not after.

Previously we just parsed the standalone.xml file, but we are now switching to the YamlConfigurationExtension so the standalone.xml no longer contains the whole truth.

Disabling the automatic deployment would be an option, but then we would need a mechanism that actually does the manual deployment after starting the Windows service. A possibility would be to write our own tool that starts WildFly and then manually starts deployment by using the markers or the CLI and install that as a Windows service using PowerShell instead of the one provided by WildFly.

It seems there is no "easy way"? ;-)

Thank you!

Greetings

Manuel

[Emmanuel Hugonnet]

You can register a listener to know when the server is started like ProcessStateListener.
You can find some tests like ProcessStateListenerTestCase in the manual mode tests of WildFly core

Emmanuel

>> 1. Do you have any idea why this works sometimes?
>> 2. How can we properly access our local WildFly configuration during the deployment of our application from our application?

>>
>> Thank you very much in advance!
>>
>> Greetings
>> Manuel
>>
>> --
>> You received this message because you are subscribed to the Google Groups "WildFly" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/wildfly/ca0ad504-dc55-481c-b91f-1ff258174aeen%40googlegroups.com

>> <https://groups.google.com/d/msgid/wildfly/ca0ad504-dc55-481c-b91f-1ff258174aeen%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google Groups "WildFly" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/wildfly/1ebc47b4-7c50-439b-9620-b0ff6e4b20e6n%40googlegroups.com
> <https://groups.google.com/d/msgid/wildfly/1ebc47b4-7c50-439b-9620-b0ff6e4b20e6n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[M K]

Hi Emmanuel,

thanks for your reply! That doesn't help if we need to access the configuration DURING deployment though, right?

Greetings

Manuel

[Emmanuel Hugonnet]

No but maybe it can help with deploying your application once the server has booted.
Emmanuel

> <https://groups.google.com/d/msgid/wildfly/1ebc47b4-7c50-439b-9620-b0ff6e4b20e6n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> You received this message because you are subscribed to the Google Groups "WildFly" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/wildfly/c4726d7e-a365-43f6-97ba-a3d9a95fe7d7n%40googlegroups.com
> <https://groups.google.com/d/msgid/wildfly/c4726d7e-a365-43f6-97ba-a3d9a95fe7d7n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Yeray Borges Santana]

That's a good point, Emmanuel, I thought retry was the only option.

M K, cannot your configuration be externalized and injected into the server? Instead of looking at the server as the root source for this information, externalize it outside of the server and use it as the root for all the parties interested.

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/50a7dcf1-daa5-4ab7-ad09-bcba36c228b5%40redhat.com.

[M K]

I don't think that would work Yeray. As I wrote above I'm reading key store information which is also needed by the server itself during startup (for the HTTPS certificate, for example). How would I tell WildFly to get the path and passwords from somewhere else and not the standalone.xml/config.yaml?

But now I know what's happening and why it's happening and there is no "provided" way to achieve what I need, so I'll figure something out. Thanks a lot for your ideas!

Greetings

Manuel