[JBoss JIRA] (WFLY-10839) RetryingInvoker fails with millisecond timeouts (IllegalArgumentException: nanosecond timeout value out of range)
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10839?page=com.atlassian.jira.plugin... ]
Radoslav Husar reassigned WFLY-10839:
-------------------------------------
Assignee: Radoslav Husar (was: Paul Ferraro)
> RetryingInvoker fails with millisecond timeouts (IllegalArgumentException: nanosecond timeout value out of range)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10839
> URL: https://issues.jboss.org/browse/WFLY-10839
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: No Release
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 14.0.0.CR1
>
>
> This is because Duration stores the value as seconds + nanosecond precision, while Thread.sleep requests nanoseconds as remainder to milliseconds, i.e. less than or equal to 999_999.
> {code}
> 15:18:43,654 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 82) MSC000001: Failed to start service org.wildfly.clustering.cache.registry.ejb.client-mappings: org.jboss.msc.service.StartException in service org.wildfly.clustering.cache.registry.ejb.client-mappings: java.lang.IllegalArgumentException: nanosecond timeout value out of range
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:70) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> at org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$start$0(AsyncServiceConfigurator.java:117) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_181]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> Caused by: java.lang.IllegalArgumentException: nanosecond timeout value out of range
> at java.lang.Thread.sleep(Thread.java:332) [rt.jar:1.8.0_181]
> at org.wildfly.clustering.ee.retry.RetryingInvoker.invoke(RetryingInvoker.java:60)
> at org.wildfly.clustering.ee.retry.RetryingInvoker.invoke(RetryingInvoker.java:78)
> at org.wildfly.clustering.server.registry.CacheRegistry.<init>(CacheRegistry.java:105)
> at org.wildfly.clustering.server.registry.CacheRegistryFactoryServiceConfigurator.apply(CacheRegistryFactoryServiceConfigurator.java:64)
> at org.wildfly.clustering.server.registry.CacheRegistryFactoryServiceConfigurator.apply(CacheRegistryFactoryServiceConfigurator.java:48)
> at org.wildfly.clustering.server.registry.FunctionalRegistryFactory.createRegistry(FunctionalRegistryFactory.java:55)
> at org.wildfly.clustering.server.registry.RegistryServiceConfigurator.get(RegistryServiceConfigurator.java:69)
> at org.wildfly.clustering.server.registry.RegistryServiceConfigurator.get(RegistryServiceConfigurator.java:53)
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:67) [wildfly-clustering-service-14.0.0.Beta2-SNAPSHOT.jar:14.0.0.Beta2-SNAPSHOT]
> ... 7 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-65) [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/WFWIP-65?page=com.atlassian.jira.plugin.s... ]
Clebert Suconic commented on WFWIP-65:
--------------------------------------
[~mnovak] that's not the point. All the changes from GE will make it into 1.x.
> [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
> -------------------------------------------------------------------------
>
> Key: WFWIP-65
> URL: https://issues.jboss.org/browse/WFWIP-65
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: DedicatedFailoverTestCaseWithMdb.testShutdownWithFailback.zip
>
>
> There is regression againt Artemis 1.5.5.0012 in scenario with failover of Artemis RA from live to backup (shared store, dedicated topology). After backup activates after failover, connections of RA does not failover to backup (or are disconnected from backup just after failover)
> Test scenario:
> * There are three servers. Live server (Node 1) and backupserver (Node 2) are in dedicated HA topology.
> * InQueue and OutQueue are deployed on live and backup. Send messages to InQueue on live server.
> * When all messages are sent, deploy message driven bean on Node 3.
> * MDB sends messages form InQueue to OutQueue.
> * Shutdown live server. Wait for backup server to alive, then start live server again and stop backup.
> * Receive messages from OutQueue from live server.
> Results:
> After live server is stopped and backup activates, no messages are processed by MDB. Looking at trace logs it seems that MDB does reconnect to backup but it's then disconnected. Then I don't see connector to backup server between tried connectors during reconnection.
> Attaching reproduce and logs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-90) [Artemis 2.x upgrade] Undelivered messages in remote jca topology after restart
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/WFWIP-90?page=com.atlassian.jira.plugin.s... ]
Clebert Suconic updated WFWIP-90:
---------------------------------
Comment: was deleted
(was: [~martyn-taylor] you marked this as done. was an error?)
> [Artemis 2.x upgrade] Undelivered messages in remote jca topology after restart
> -------------------------------------------------------------------------------
>
> Key: WFWIP-90
> URL: https://issues.jboss.org/browse/WFWIP-90
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
>
> There are undelivered messages in scenario with where servers in remote JCA topology are restarted. There are undelivered message after test.
> Test scenario:
> * Start 2 server in Artemis cluster
> * Start 2 servers with MDB connected to Artemis cluster
> ** MDB resends messages from InQueue to OutQueue from/to remote cluster
> * Send messages to InQueue
> * Restart all server (one by one)
> * Consumes messages from OutQueue
> Results:
> After the test there are missing messages in OutQueue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-90) [Artemis 2.x upgrade] Undelivered messages in remote jca topology after restart
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/WFWIP-90?page=com.atlassian.jira.plugin.s... ]
Clebert Suconic commented on WFWIP-90:
--------------------------------------
[~martyn-taylor] you marked this as done. was an error?
> [Artemis 2.x upgrade] Undelivered messages in remote jca topology after restart
> -------------------------------------------------------------------------------
>
> Key: WFWIP-90
> URL: https://issues.jboss.org/browse/WFWIP-90
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
>
> There are undelivered messages in scenario with where servers in remote JCA topology are restarted. There are undelivered message after test.
> Test scenario:
> * Start 2 server in Artemis cluster
> * Start 2 servers with MDB connected to Artemis cluster
> ** MDB resends messages from InQueue to OutQueue from/to remote cluster
> * Send messages to InQueue
> * Restart all server (one by one)
> * Consumes messages from OutQueue
> Results:
> After the test there are missing messages in OutQueue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1639) FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-1639?page=com.atlassian.jira.plugin.s... ]
Farah Juma reassigned ELY-1639:
-------------------------------
Assignee: Jan Kalina (was: Farah Juma)
> FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
> -------------------------------------------------------------
>
> Key: ELY-1639
> URL: https://issues.jboss.org/browse/ELY-1639
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
> Attachments: cli-wildfly-config.xml
>
>
> Fix of ELY-1622 introduced regression. It is not possible to do 1 way ssl (no key-store-ssl-certificate in wildfly-config.xml) with exception
> {code}
> 14:13:56,143 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:330)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:291)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> Caused by: org.jboss.as.cli.CommandLineException: Failed to resolve host 'localhost'
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1256)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328)
> ... 5 more
> Caused by: java.io.IOException: Failed to obtain SSLContext
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:156)
> at org.jboss.as.cli.impl.ModelControllerClientFactory$2.getClient(ModelControllerClientFactory.java:85)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1222)
> ... 8 more
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseKeyManager(SSLContextImpl.java:149)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:66)
> at javax.net.ssl.SSLContext.init(SSLContext.java:282)
> at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:221)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:208)
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:153)
> ... 10 more
> {code}
> It is because after fix Fix of ELY-1622 custom keymanager is used. But it is forbidden by jdk FIPS PKCS11.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4029) PrincipalResourceDefinition.Type should override toString with lower-case value
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4029?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-4029.
--------------------------------------
Resolution: Won't Do
I've decided not to pursue this. Doing it resulted in failures in core-model-test transformers tests, which are probably no big deal and resolvable via the test fixture. But that just pushed this over the edge in terms of risk vs reward, effort vs benefit.
In case we decide later to take this up this was the functional change:
{code}
diff --git a/domain-management/src/main/java/org/jboss/as/domain/management/access/PrincipalResourceDefinition.java b/domain-management/src/main/java/org/jboss/as/domain/management/access/PrincipalResourceDefinition.java
index c81a8388b3..0f925a02f2 100644
--- a/domain-management/src/main/java/org/jboss/as/domain/management/access/PrincipalResourceDefinition.java
+++ b/domain-management/src/main/java/org/jboss/as/domain/management/access/PrincipalResourceDefinition.java
@@ -25,6 +25,8 @@ package org.jboss.as.domain.management.access;
import static org.jboss.as.controller.descriptions.ModelDescriptionConstants.EXCLUDE;
import static org.jboss.as.controller.descriptions.ModelDescriptionConstants.INCLUDE;
+import java.util.Locale;
+
import org.jboss.as.controller.ModelVersion;
import org.jboss.as.controller.OperationContext;
import org.jboss.as.controller.OperationFailedException;
@@ -43,14 +45,20 @@ import org.jboss.dmr.ModelNode;
import org.jboss.dmr.ModelType;
/**
- * A {@link ResourceDefinition} representing a Principal either specified in the include or exclude list of a role mapping.
+ * A {@link org.jboss.as.controller.ResourceDefinition} representing a Principal either specified in the include or exclude list of a role mapping.
*
* @author <a href="mailto:darran.lofthouse@jboss.com">Darran Lofthouse</a>
*/
public class PrincipalResourceDefinition extends SimpleResourceDefinition {
public enum Type {
- GROUP, USER
+ GROUP, USER;
+
+ @Override
+ public String toString() {
+ // Use lower case form
+ return super.toString().toLowerCase(Locale.ENGLISH);
+ }
}
public static final SimpleAttributeDefinition TYPE = new SimpleAttributeDefinitionBuilder(ModelDescriptionConstants.TYPE,
@@ -86,7 +94,7 @@ public class PrincipalResourceDefinition extends SimpleResourceDefinition {
static AuthorizerConfiguration.PrincipalType getPrincipalType(final OperationContext context, final ModelNode model)
throws OperationFailedException {
- return AuthorizerConfiguration.PrincipalType.valueOf(TYPE.resolveValue(context, model.get(TYPE.getName())).asString());
+ return AuthorizerConfiguration.PrincipalType.valueOf(TYPE.resolveValue(context, model.get(TYPE.getName())).asString().toUpperCase(Locale.ENGLISH));
}
static String getRealm(final OperationContext context, final ModelNode model) throws OperationFailedException {
{code}
> PrincipalResourceDefinition.Type should override toString with lower-case value
> -------------------------------------------------------------------------------
>
> Key: WFCORE-4029
> URL: https://issues.jboss.org/browse/WFCORE-4029
> Project: WildFly Core
> Issue Type: Enhancement
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> Eliminate the need for this:
> https://github.com/wildfly/wildfly-core/pull/3431/files#diff-a3d05632a7de...
> Using the lower case values in the config docs is nicer, but because the lower case gets thrown away Galleon has to put upper case in our standard configs or think the user made a config change when read-config-as-feature reports upper case.
> [~aloubyansky] FYI.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2397) PMML modules have classloader issues in OSGi
by Lance Leverich (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2397?page=com.atlassian.jira.plugi... ]
Lance Leverich updated DROOLS-2397:
-----------------------------------
Labels: drools-core (was: )
> PMML modules have classloader issues in OSGi
> --------------------------------------------
>
> Key: DROOLS-2397
> URL: https://issues.jboss.org/browse/DROOLS-2397
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.6.0.Final
> Environment: Equinox OSGi container, Java 8
> Reporter: Jens Reimann
> Assignee: Lance Leverich
> Labels: drools-core
>
> The drools PMML modules (drools-pmml and kie-pmml) both suffer from a few class loader issues when running inside an OSGi container.
> The KieBase built for transforming the PMML model to Drools model selects the wrong class loader (based on the context class loader). The JAXB instance creator fails with the same problem.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2892) Session reset doesn't clear path memory
by Christian Liebhardt (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2892?page=com.atlassian.jira.plugi... ]
Christian Liebhardt updated DROOLS-2892:
----------------------------------------
Description:
As discussed in https://groups.google.com/forum/#!topic/drools-usage/V8ypP1o5SwM :
In order to reduce memory allocations we are calling _StatefulKnowledgeSessionImpl.reset()_ to bring a disposed session back into life. From our understanding this is the same method which the Drools session cache would use. During our tests we found that some of our rules don't trigger if we use this approach. We also found that the reset method leaves _PathMemory_ instances behind in the memory. As soon as we cleared the memory explicitly by calling _session.getNodeMemories().clear()_ after every _session.reset()_ the rules fired again as usual. So we are wondering if the current implementation of _session.reset()_ is incomplete.
We are aware that _session.reset()_ is an internal method. However this issue should also affect the session cache feature of Drools. At the same time it would be nice to have a public interface to _session.reset()_ since in our application reusing a session is beneficial but we don't need the session cache as we can easily remember the last session which we used for processing and it seems more straightforward to just bring that one back to life instead of storing and retrieving it from a cache.
was:
As discussed in https://groups.google.com/forum/#!topic/drools-usage/V8ypP1o5SwM :
In order to reduce memory allocations we are calling _StatefulKnowledgeSessionImpl.reset()_ to bring a disposed session back into life. From our understanding this is the same method which the Drools session cache would use. During our tests we found that some of our rules don't trigger if we use this approach. We also found that the reset method leaves _PathMemory _instances behind in the memory. As soon as we cleared the memory explicitly by calling _session.getNodeMemories().clear()_ after every _session.reset()_ the rules fired again as usual. So we are wondering if the current implementation of _session.reset()_ is incomplete.
We are aware that _session.reset()_ is an internal method. However this issue should also affect the session cache feature of Drools. At the same time it would be nice to have a public interface to _session.reset()_ since in our application reusing a session is beneficial but we don't need the session cache as we can easily remember the last session which we used for processing and it seems more straightforward to just bring that one back to life instead of storing and retrieving it from a cache.
> Session reset doesn't clear path memory
> ---------------------------------------
>
> Key: DROOLS-2892
> URL: https://issues.jboss.org/browse/DROOLS-2892
> Project: Drools
> Issue Type: Bug
> Reporter: Christian Liebhardt
> Assignee: Mario Fusco
>
> As discussed in https://groups.google.com/forum/#!topic/drools-usage/V8ypP1o5SwM :
> In order to reduce memory allocations we are calling _StatefulKnowledgeSessionImpl.reset()_ to bring a disposed session back into life. From our understanding this is the same method which the Drools session cache would use. During our tests we found that some of our rules don't trigger if we use this approach. We also found that the reset method leaves _PathMemory_ instances behind in the memory. As soon as we cleared the memory explicitly by calling _session.getNodeMemories().clear()_ after every _session.reset()_ the rules fired again as usual. So we are wondering if the current implementation of _session.reset()_ is incomplete.
> We are aware that _session.reset()_ is an internal method. However this issue should also affect the session cache feature of Drools. At the same time it would be nice to have a public interface to _session.reset()_ since in our application reusing a session is beneficial but we don't need the session cache as we can easily remember the last session which we used for processing and it seems more straightforward to just bring that one back to life instead of storing and retrieving it from a cache.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months