[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)
3 years, 8 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)
3 years, 8 months
[Red Hat JIRA] (DROOLS-5923) ResourceType does not work
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5923?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-5923.
---------------------------------
Resolution: Explained
You're misusing the ResourceType. Just pass the existing ResourceType.DRL and it works.
> ResourceType does not work
> --------------------------
>
> Key: DROOLS-5923
> URL: https://issues.redhat.com/browse/DROOLS-5923
> Project: Drools
> Issue Type: Bug
> Reporter: yj jiang
> Assignee: Mario Fusco
> Priority: Major
>
> I use drools as follow:
> {code:java}
> import org.kie.internal.utils.KieHelper;
> // code placeholder
> public static final ResourceType LOCAL_DRL = ResourceType.addResourceTypeToRegistry("DRL",
> "Drools Rule Language",
> "src/main/resources/com/jiang",
> "drl");
> public KieSession loadForRule2(String drlStr) {
> KieHelper helper = new KieHelper();
> helper.addContent(drlStr, LOCAL_DRL);
> return helper.build().newKieSession();
> }
> {code}
> This param *defaultPath* dose not work, I see that the code is fixed，
>
> {code:java}
> // code placeholder
> private String generateResourceName(ResourceType type) {
> return "src/main/resources/file" + counter++ + "." + type.getDefaultExtension();
> }
> {code}
> I think it should be changed as follows
> {code:java}
> // code placeholder
> private String generateResourceName(ResourceType type) {
> return type.getDefaultPath() + counter++ + "." + type.getDefaultExtension();
> }{code}
> Now，i use another function to temporarily solve
> {code:java}
> // code placeholder
> helper.addContent(drlStr, "/com/jiang/ww.drl");
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 8 months
[Red Hat JIRA] (DROOLS-5405) NPE removing a rule from KieBase
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5405?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-5405.
---------------------------------
Resolution: Cannot Reproduce
> NPE removing a rule from KieBase
> --------------------------------
>
> Key: DROOLS-5405
> URL: https://issues.redhat.com/browse/DROOLS-5405
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.37.0.Final
> Reporter: dianle zhang
> Assignee: Mario Fusco
> Priority: Major
>
> removing a rule from KieBase causes the following NPE:
> java.lang.NullPointerException: null
> at org.drools.core.phreak.AddRemoveRule.iterateLeftTuple(AddRemoveRule.java:1063) ~[drools-core-7.37.0.Final.jar:7.37.0.Final]
> at org.drools.core.phreak.AddRemoveRule.visitChild(AddRemoveRule.java:978) ~[drools-core-7.37.0.Final.jar:7.37.0.Final]
> at org.drools.core.phreak.AddRemoveRule.lambda$processLeftTuplesOnLian$1(AddRemoveRule.java:936) ~[drools-core-7.37.0.Final.jar:7.37.0.Final]
> at org.drools.core.common.DefaultFactHandle$SingleLinkedTuples.forEachLeftTuple(DefaultFactHandle.java:727) ~[drools-core-7.37.0.Final.jar:7.37.0.Final]
> at org.drools.core.common.DefaultFactHandle.forEachLeftTuple(DefaultFactHandle.java:923) ~[drools-core-7.37.0.Final.jar:7.37.0.Final]
> at org.drools.core.phreak.AddRemoveRule.processLeftTuplesOnLian(AddRemoveRule.java:931) ~[drools-core-7.37.0.Final.jar:7.37.0.Final]
> at org.drools.core.phreak.AddRemoveRule.processLeftTuples(AddRemoveRule.java:856) ~[drools-core-7.37.0.Final.jar:7.37.0.Final]
> at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:173) ~[drools-core-7.37.0.Final.jar:7.37.0.Final]
> at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:191) ~[drools-core-7.37.0.Final.jar:7.37.0.Final]
> at org.drools.core.reteoo.ReteooBuilder.removeRules(ReteooBuilder.java:177) ~[drools-core-7.37.0.Final.jar:7.37.0.Final]
> at org.drools.core.impl.KnowledgeBaseImpl.lambda$removeRule$6(KnowledgeBaseImpl.java:1553) ~[drools-core-7.37.0.Final.jar:7.37.0.Final]
> at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:745) ~[drools-core-7.37.0.Final.jar:7.37.0.Final]
> at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1537) ~[drools-core-7.37.0.Final.jar:7.37.0.Final]
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 8 months
[Red Hat JIRA] (DROOLS-5965) "and exists" used in source-pattern part of accumulate statement matches multiple times in executable model.
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5965?page=com.atlassian.jira.plug... ]
Mario Fusco moved RHDM-1587 to DROOLS-5965:
-------------------------------------------
Component/s: executable model
(was: BRE)
Docs QE Status: NEW
Key: DROOLS-5965 (was: RHDM-1587)
QE Status: NEW
Affects Version/s: (was: 7.1.0.GA)
(was: 7.9.0.GA)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Environment: (was: This issue occurs on releases from RHDM 7.1.0 to 7.9.1.)
Project: Drools (was: Red Hat Decision Manager)
> "and exists" used in source-pattern part of accumulate statement matches multiple times in executable model.
> ------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5965
> URL: https://issues.redhat.com/browse/DROOLS-5965
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Major
> Labels: support
> Attachments: reproducer_model_compiler_16a.zip
>
>
> When executing a rule like (\*1) that uses {{and exists}} in _source-pattern_ part of {{accumulate}} statement like (\*1-1) in executable model, the sub-pattern given by {{and exists}} matches multiple times. For example in rule (\*1), we insert 1 {{Car}} object and 3 {{InspectionResult}} objects with the same value of {{number}} property as the {{Car}} object, the _source-pattern_ in the {{accumulate}} statement matches 3 times. In this case, it should match only once.
> (\*1)
> {noformat}
> package com.example.reproducer
> import java.util.List
> dialect "java"
> rule "rule16a2"
> when
> $list : List() from accumulate ( $car : Car( $number : number )
> and exists InspectionResult( number == $number ); // ..... (*1-1)
> collectList($car) )
> then
> System.out.println("***** Action of rule16a2 -- $list = " + $list);
> end
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 8 months