[JBoss JIRA] (WFCORE-3008) Server started with blocking=true times out only on a slave host
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3008?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration updated WFCORE-3008:
--------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1464323
Bugzilla Update: Perform
> Server started with blocking=true times out only on a slave host
> ----------------------------------------------------------------
>
> Key: WFCORE-3008
> URL: https://issues.jboss.org/browse/WFCORE-3008
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.Final
> Reporter: Osamu Nagano
> Assignee: Brian Stansberry
> Attachments: repro.zip
>
>
> We use system property {{jboss.as.management.blocking.timeout}} for a slow starting server to avoid a timeout on startup. It works for a server on the master host-controller but doesn't work a server on a slave host.
> Suppose a heavy application, for example, sleeping more than 300 seconds in {{ServletContext#contextInitialized()}}, is deployed and system property {{jboss.as.management.blocking.timeout}} is set in domain.xml to avoid timeout. Under the following domain configuration, {{server-one}} fails to start if {{blocking=true}} is specified.
> * master
> ** server-zero:start(blocking=true) => Success
> * slave
> ** server-one:start(blocking=true) => Fail
> {code}
> [domain@localhost:9990 /] /host=slave/server-config=server-one:start(blocking=true)
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "WFLYCTL0409: Execution of operation 'start' on remote process at address '[(\"host\" => \"slave\")]' timed out after 305000 ms while awaiting initial response; remote process has been notified to terminate operation",
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8620) wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-8620?page=com.atlassian.jira.plugin.... ]
Amos Feng updated WFLY-8620:
----------------------------
Component/s: Build System
> wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-8620
> URL: https://issues.jboss.org/browse/WFLY-8620
> Project: WildFly
> Issue Type: Sub-task
> Components: Build System
> Reporter: Amos Feng
> Assignee: Amos Feng
> Fix For: 11.0.0.Beta1
>
>
> {noformat}
> Running org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.467 sec <<< FAILURE! - in org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> testSpecificProviderCanBeConfiguredInValidationXml(org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase) Time elapsed: 0.283 sec <<< ERROR!
> javax.validation.ValidationException: HV000100: Unable to parse META-INF/validation.xml.
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:292)
> at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:508)
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:194)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:405)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:33)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:19)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:219)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:127)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:88)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:393)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:476)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:309)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.initFactory(LazyValidatorFactory.java:81)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getDelegate(LazyValidatorFactory.java:58)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:73)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase.testSpecificProviderCanBeConfiguredInValidationXml(LazyValidatorFactoryTestCase.java:70)
> {noformat}
> It could need to add the java.xml modules
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8620) wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-8620?page=com.atlassian.jira.plugin.... ]
Amos Feng updated WFLY-8620:
----------------------------
Fix Version/s: 11.0.0.Beta1
> wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-8620
> URL: https://issues.jboss.org/browse/WFLY-8620
> Project: WildFly
> Issue Type: Sub-task
> Reporter: Amos Feng
> Assignee: Amos Feng
> Fix For: 11.0.0.Beta1
>
>
> {noformat}
> Running org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.467 sec <<< FAILURE! - in org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> testSpecificProviderCanBeConfiguredInValidationXml(org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase) Time elapsed: 0.283 sec <<< ERROR!
> javax.validation.ValidationException: HV000100: Unable to parse META-INF/validation.xml.
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:292)
> at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:508)
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:194)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:405)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:33)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:19)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:219)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:127)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:88)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:393)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:476)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:309)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.initFactory(LazyValidatorFactory.java:81)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getDelegate(LazyValidatorFactory.java:58)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:73)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase.testSpecificProviderCanBeConfiguredInValidationXml(LazyValidatorFactoryTestCase.java:70)
> {noformat}
> It could need to add the java.xml modules
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-844) Crash when node is deleted from query node
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-844?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-844.
--------------------------------
Fix Version/s: (was: 6.4.0.Beta1)
Resolution: Cannot Reproduce Bug
> Crash when node is deleted from query node
> ------------------------------------------
>
> Key: DROOLS-844
> URL: https://issues.jboss.org/browse/DROOLS-844
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final, 7.0.0.Beta1
> Reporter: Fabian Meyer
> Assignee: Mario Fusco
> Priority: Critical
>
> When a left delete is performed on a PhreakQueryNode, the fact handle of the left tuple might be null, resulting in a NullPointerException.
> Exception in thread "Thread-6" java.lang.NullPointerException
> at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:176)
> at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:46)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:460)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:360)
> at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:598)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:524)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:336)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:973)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1251)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1353)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1331)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-754) KieScanner crash while erroneously trying to resolve non necessary dependencies
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-754?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-754.
--------------------------------
Resolution: Out of Date
> KieScanner crash while erroneously trying to resolve non necessary dependencies
> -------------------------------------------------------------------------------
>
> Key: DROOLS-754
> URL: https://issues.jboss.org/browse/DROOLS-754
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Environment: kie-ci
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: 20150331.DROOLS-754.zip
>
>
> h5. Overview
> Given kie.maven.settings.custom to force KIE libraries to reference only an internal nexus repo without Maven-central proxy just for the kjar of the rules.
> Given a KieContainer created with ReleaseId, trying to create a KieScanner would fail if the kjar of the release ID contain parametrized versions in the POM, because the KiScanner does not substitute the parameter, and moreover it tries to resolve them anyway even if those dependencies are not actually needed because having scope=test.
> Even changing the internal nexus repo, althought may not be feasible, for Maven-central proxy (http://repo1.maven.org/maven2/) would fail in resolving other dependencies.
> *keypoint*: have a way to instruct KIE KieContainer AND KieScanner, to reference just-and-only an internal Nexus repo just and only for the KJar for the rules, without having to internally proxy or double-check Maven central, please?
> Could you kindly advise accordingly, please?
> h5. Details
> Given a kjar artifact named {{kiescanner-testandversionissue-rules}} with the following pom (extract):
> {code:xml}
> <properties>
> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
> <drools-version>6.2.0.Final</drools-version>
> <slf4j-version>1.7.2</slf4j-version>
> <junit-version>4.11</junit-version>
> </properties>
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-bom</artifactId>
> <type>pom</type>
> <version>${drools-version}</version>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
> <dependencies>
>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-compiler</artifactId>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>${junit-version}</version>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-log4j12</artifactId>
> <version>${slf4j-version}</version>
> <scope>test</scope>
> </dependency>
> </dependencies>
> {code}
> Please notice the dependencies are parametrized in the versions, and moreover are not really required for runtime because scope=test.
> Now assume this kjar is deployed to a maven repo, like a nexus repository.
> Now given a client application havign kie.maven.settings.custom to force KIE libraries to reference only an internal nexus repo:
> {code}
> ReleaseId rId = kieServices.newReleaseId( "com.acme", "kiescanner-testandversionissue-rules", "RELEASE" );
> KieContainer kieContainer = kieServices.newKieContainer( rId );
> LOG.info("kieContainer exists. {}", kieContainer);
> LOG.info("Now about to create kieScanner...");
> KieScanner kScanner = kieServices.newKieScanner( kieContainer );
> kScanner.start( KIE_SCANNER_INTERVAL );
> {code}
> This code will fail with the following in the log (extract):
> {code}
> INFO [com.acme.kiescanner_testandversionissue_client.App] (main) kieContainer exists. org.drools.compiler.kie.builder.impl.KieContainerImpl@1229a2b7
> INFO [com.acme.kiescanner_testandversionissue_client.App] (main) Now about to create kieScanner...
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/org/slf4j/slf4j-log4j12/$%7Bslf4j-version%7D/slf4j-log4j12-$%7Bslf4j-version%7D.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56971<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56971<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/junit/junit/$%7Bjunit-version%7D/junit-$%7Bjunit-version%7D.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56972<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56972<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/org/drools/drools-bom/$%7Bdrools-version%7D/drools-bom-$%7Bdrools-version%7D.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56973<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56973<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/org/slf4j/slf4j-log4j12/$%7Bslf4j-version%7D/slf4j-log4j12-$%7Bslf4j-version%7D.jar HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56974<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56974<->127.0.0.1:8081 closed
> WARN [org.kie.scanner.MavenRepository] (main) Unable to resolve artifact: org.slf4j:slf4j-log4j12:${slf4j-version}
> {code}
> We can notice two issues:
> * the ${...-version} is not substitued while trying to resolve these artifacts on the nexus repo, the URL contains the ${...-version} literally
> * actually why the KieScanner try to resolve them given the dependencies are scope=test ?
> Also, even changing the internal nexus repo for Maven-central proxy (http://repo1.maven.org/maven2/) by:
> nexus connect with default user admin/admin123, add proxy repo http://repo1.maven.org/maven2/), go to group "public" and add the proxy, erase local-user .m2 drools-bom to force re-resolution,
> And re-running the client application again, would instead crash in resolving the following:
> {code}
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: HEAD /nexus/content/groups/public/org/jboss/dashboard-builder/dashboard-builder-bom/6.2.0.Final/dashboard-builder-bom-6.2.0.Final.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57598<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57598<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: HEAD /nexus/content/groups/public/org/dashbuilder/dashbuilder-bom/0.2.1.Final/dashbuilder-bom-0.2.1.Final.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57599<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57599<->127.0.0.1:8081 closed
> {code}
> Could you kindly advise accordingly, please?
> h5. Conclusion
> Have a way to instruct KIE KieContainer AND KieScanner, to reference just-and-only an internal Nexus repo just and only for the KJar for the rules, without having to proxy Maven central
> Please notice:
> IFF in the custom kie-settings.xml I do remove the mirror definition, the problem WILL be that KIE libraries will try to resolve the {{kiescanner-testandversionissue-rules}} kjar in *both* Maven central and the local repo, and this is not advisable as the rule package name should go straight and just to the internal maven repo.
> h5. Steps to reproduce
> I will attach reproducer containing
> * kiescanner-testandversionissue-rules
> * kiescanner-testandversionissue-client
> * standalone nexus containing just and only repo for the kjar rules without any Maven-central proxy
> you can use the last for standalone test, otherwise you can deploy the rule and reference to another disposable internal Nexus repo by also updating the custom kie-settings.xml in the client app.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1629) PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1629?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1629:
-------------------------------------
[~ngs_mtech] Are you still going to send your pull request against master?
> PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-1629
> URL: https://issues.jboss.org/browse/DROOLS-1629
> Project: Drools
> Issue Type: Bug
> Components: core engine, kie server
> Affects Versions: 6.4.0.Final, 6.5.0.Final
> Reporter: Manuel Castro
> Assignee: Mario Fusco
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> We are defining our custom JPAPlaceHolderResolverStrategy, parametrizing the constructuctor with the persistence unit name it handles.
> When we need two of them to handle different kind of Entities probably from different DataSources, the marshalling process works properly as calling to accept method before marshalling returns true for the correct ObjectMarshallingStrategy.
> The problem occurs while unmarshalling the entities. As the class name is being used to find the correct ObjectMarshallingStrategy from the store, the class name matches two Object Marshalling Strategies, so the first one found is returned, making the environment work in a random space.
> This problem could be solved adding to ObjectMarshallingStrategy interface a getName() method in order to be able to avoid the usage of the getClass().getName() approach is being used now.
> Then PersisteHelper must use this method to store the ProtobufferHeader and then ObjectMarshallingStrategyStore must use the method to retrieve the appropiate implementation.
> In order to enable backward compatibility a NamedObjectMarshallingStrategyInterface could be added to be invoked only for updated implementors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months