[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza edited comment on WFLY-14284 at 1/22/21 8:24 AM:
---------------------------------------------------------------------------
Hi [~ochaloup]
The $local authentication is not disabled according to what I can see. If it's this.
{code:java}
<security-realms>
<security-realm name="ManagementRealm">
<server-identities>
<secret value="YWRtaW5AYWxmYQo="/>
</server-identities>
<authentication>
<local default-user="$local" skip-group-loading="true"/>
<properties path="mgmt-users.properties" relative-to="jboss.domain.config.dir"/>
</authentication>
<authorization map-groups-to-roles="false">
<properties path="mgmt-groups.properties" relative-to="jboss.domain.config.dir"/>
</authorization>
</security-realm>
<security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="application.keystore" relative-to="jboss.domain.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<local default-user="$local" allowed-users="*" skip-group-loading="true"/>
<properties path="application-users.properties" relative-to="jboss.domain.config.dir"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/>
</authorization>
</security-realm>
<security-realm name="remote-ejb-security-realm">
<server-identities>
<secret value="ZWpi"/>
</server-identities>
</security-realm>
</security-realms>
{code}
Our lookup in almost of case is like this
{code:java}
Properties props = new Properties();
props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); Context context = new InitialContext(props);
StringBuilder jndiName = new StringBuilder();
jndiName.append("ejb:");
jndiName.append(module.getApplicationName()); jndiName.append("/"); jndiName.append(module.getModuleName()); jndiName.append("/"); jndiName.append(ejbName); jndiName.append("!"); jndiName.append(intefaceName);
Object bean = context.lookup(jndiName.toString());
{code}
I'll configure to remote+http instead of http-remoting (it commes from Wildfly 10 configuration) and -Dwildfly.config.url with wildfly-config.xml and I will observe the server logs and behavior on the stoping operations
On error scenario we have a wildfly domain with our applications and four servers working behind a haproxy load balance
I'll set jboss.tx.node.id on server instances in order to get a better scenario too.
Some information about your point:
1 - We are a software development providing to many companies and we are configuring ejb as remote call because we have three modules that can be deployed together on the same instance or on different instance according to our client needs. It's just by convenience.
2 - On this scenario we don't using @EJB or java:app with local lookup because we have a large software ecosystem and we need to normalize all development activities to a standard ways (in this case using Context lookup) in order to get more easy and flexible development activities and get more predictable thing to solve problems. There are many places we are using local lookup but in this case is where are sure there is no remote call.
3 - Becouse our company directives we don't use nom specification annotation like @ClientTransaction
I'll bring some more information about our tests after do it.
By the time I say thanks
was (Author: JIRAUSER147207):
Hi [~ochaloup]
The $local authentication is not disabled according to what I can see. If it's this.
{code:java}
<security-realms>
<security-realm name="ManagementRealm">
<server-identities>
<secret value="YWRtaW5AYWxmYQo="/>
</server-identities>
<authentication>
<local default-user="$local" skip-group-loading="true"/>
<properties path="mgmt-users.properties" relative-to="jboss.domain.config.dir"/>
</authentication>
<authorization map-groups-to-roles="false">
<properties path="mgmt-groups.properties" relative-to="jboss.domain.config.dir"/>
</authorization>
</security-realm>
<security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="application.keystore" relative-to="jboss.domain.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<local default-user="$local" allowed-users="*" skip-group-loading="true"/>
<properties path="application-users.properties" relative-to="jboss.domain.config.dir"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/>
</authorization>
</security-realm>
<security-realm name="remote-ejb-security-realm">
<server-identities>
<secret value="ZWpi"/>
</server-identities>
</security-realm>
</security-realms>
{code}
I'll configure to remote+http instead of http-remoting (it commes from Wildfly 10 configuration) and -Dwildfly.config.url with wildfly-config.xml and I will observe the server logs and behavior on the stoping operations
On error scenario we have a wildfly domain with our applications and four servers working behind a haproxy load balance
I'll set jboss.tx.node.id on server instances in order to get a better scenario too.
Some information about your point:
1 - We are a software development providing to many companies and we are configuring ejb as remote call because we have three modules that can be deployed together on the same instance or on different instance according to our client needs. It's just by convenience.
2 - On this scenario we don't using @EJB or java:app with local lookup because we have a large software ecosystem and we need to normalize all development activities to a standard ways (in this case using Context lookup) in order to get more easy and flexible development activities and get more predictable thing to solve problems. There are many places we are using local lookup but in this case is where are sure there is no remote call.
3 - Becouse our company directives we don't use nom specification annotation like @ClientTransaction
I'll bring some more information about our tests after do it.
By the time I say thanks
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza commented on WFLY-14284:
--------------------------------------------------
Hi [~ochaloup]
The $local authentication is not disabled according to what I can see. If it's this.
{code:java}
<security-realms>
<security-realm name="ManagementRealm">
<server-identities>
<secret value="YWRtaW5AYWxmYQo="/>
</server-identities>
<authentication>
<local default-user="$local" skip-group-loading="true"/>
<properties path="mgmt-users.properties" relative-to="jboss.domain.config.dir"/>
</authentication>
<authorization map-groups-to-roles="false">
<properties path="mgmt-groups.properties" relative-to="jboss.domain.config.dir"/>
</authorization>
</security-realm>
<security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="application.keystore" relative-to="jboss.domain.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<local default-user="$local" allowed-users="*" skip-group-loading="true"/>
<properties path="application-users.properties" relative-to="jboss.domain.config.dir"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/>
</authorization>
</security-realm>
<security-realm name="remote-ejb-security-realm">
<server-identities>
<secret value="ZWpi"/>
</server-identities>
</security-realm>
</security-realms>
{code}
I'll configure to remote+http instead of http-remoting (it commes from Wildfly 10 configuration) and -Dwildfly.config.url with wildfly-config.xml and I will observe the server logs and behavior on the stoping operations
On error scenario we have a wildfly domain with our applications and four servers working behind a haproxy load balance
I'll set jboss.tx.node.id on server instances in order to get a better scenario too.
Some information about your point:
1 - We are a software development providing to many companies and we are configuring ejb as remote call because we have three modules that can be deployed together on the same instance or on different instance according to our client needs. It's just by convenience.
2 - On this scenario we don't using @EJB or java:app with local lookup because we have a large software ecosystem and we need to normalize all development activities to a standard ways (in this case using Context lookup) in order to get more easy and flexible development activities and get more predictable thing to solve problems. There are many places we are using local lookup but in this case is where are sure there is no remote call.
3 - Becouse our company directives we don't use nom specification annotation like @ClientTransaction
I'll bring some more information about our tests after do it.
By the time I say thanks
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months