[JBoss JIRA] (WFLY-10813) OutOfMemory error when trying to display resource adapters in web console
by Claudio Miranda (Jira)
[ https://issues.jboss.org/browse/WFLY-10813?page=com.atlassian.jira.plugin... ]
Claudio Miranda updated WFLY-10813:
-----------------------------------
Attachment: standalone-full-ha.xml
> OutOfMemory error when trying to display resource adapters in web console
> -------------------------------------------------------------------------
>
> Key: WFLY-10813
> URL: https://issues.jboss.org/browse/WFLY-10813
> Project: WildFly
> Issue Type: Bug
> Components: Management, Web Console
> Affects Versions: 10.0.0.Final, 13.0.0.Final
> Reporter: Helena Knyttlová
> Assignee: Harald Pehl
> Priority: Minor
> Attachments: standalone-full-ha.xml
>
>
> We have about 25 resource adapters set through CLI. When I want to display them in web administration console it kills the whole wildfly server - server is not responding and after several minutes it ends up with OutOfMemory error and server must be restarted. We've seen this issue since wildfly 10 (it was the first version we used). With only a few resource adapters it is not happening.
> Memory settings: JAVA_OPTS="-Xms512m -Xmx1024m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> The error which appeared on WidlFly 13.0.0.Final:
> {panel:title=Log}
> ERROR [org.jboss.as.controller.management-operation] (External Management Request Threads -- 1) WFLYCTL0013: Operation ("read-resource-description") failed - address: ([
> ("subsystem" => "resource-adapters"),
> ("resource-adapter" => "AppAdapter"),
> ("connection-definitions" => "cp-host")
> ]): java.lang.OutOfMemoryError: Java heap space
> at java.util.HashMap.resize(HashMap.java:704)
> at java.util.HashMap.putVal(HashMap.java:629)
> at java.util.HashMap.put(HashMap.java:612)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:180)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:169)
> at org.jboss.dmr.ModelNode.clone(ModelNode.java:1867)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:180)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:169)
> at org.jboss.dmr.ModelNode.clone(ModelNode.java:1867)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:180)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:169)
> at org.jboss.dmr.ModelNode.clone(ModelNode.java:1867)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:180)
> at org.jboss.dmr.ObjectModelValue.copy(ObjectModelValue.java:169)
> at org.jboss.dmr.ModelNode.set(ModelNode.java:693)
> at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$ReadResourceDescriptionAssemblyHandler.execute(ReadResourceDescriptionHandler.java:618)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1404)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.jboss.as.controller.ModelControllerImpl$$Lambda$490/414756260.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$491/367363594.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler$$Lambda$790/1228674018.run(Unknown Source)
> {panel}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFWIP-148) Artemis logging codes/IDs have changed for CORE protocol
by Dimitris Andreadis (Jira)
[ https://issues.jboss.org/browse/WFWIP-148?page=com.atlassian.jira.plugin.... ]
Dimitris Andreadis commented on WFWIP-148:
------------------------------------------
[~jbertram], Error codes, Configuration, Scripts are pretty much part of a product's public "API". Changing Error codes of course is not a "bug" in the code sense, but it could potentially break the monitoring of a deployment, tied to some related action. Or else how can you ensure smooth upgrades? Changed error codes can indeed be worse than duplicated ones in the sense that the former can go undetected during an upgrade while the latter it is a known problematic state.
So to clarify, this change was made going from AMQ 7.2.1 to 7.2.2?
In any case, we definitely don't want to fork because of it, so since according to your thinking it shouldn't be a big things for customers in general, why not swapping the error codes in AMQ 7.2.3 to keep the CORE ones used in EAP stable, instead? EAP has more customers who are likely more picky than AMQ when it comes to compatibility issues.
> Artemis logging codes/IDs have changed for CORE protocol
> --------------------------------------------------------
>
> Key: WFWIP-148
> URL: https://issues.jboss.org/browse/WFWIP-148
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Justin Bertram
> Priority: Blocker
>
> Artemis logging codes for CORE protocol has changed in scope of jira: https://issues.apache.org/jira/browse/ARTEMIS-1018
> For example in WF14 if standalone JMS client failed to connect then it was logged with code AMQ119007:
> {code}
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
> {code}
> but newly it would have code AMQ219007:
> {code}
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219007: Cannot connect to server(s). Tried with all available servers.]
> {code}
> This is problem for any user/customer who had monitoring based on those codes as this will require to change it.
> The reason for change was because those codes were duplicated between AMQP and CORE protocol. As CORE protocol is default and AMQP is not supported for EAP ti would makes sense to change AMQP codes instead and keep codes for CORE protocol without any change.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFWIP-148) Artemis logging codes/IDs have changed for CORE protocol
by Bilge Ozpeynirci (Jira)
[ https://issues.jboss.org/browse/WFWIP-148?page=com.atlassian.jira.plugin.... ]
Bilge Ozpeynirci commented on WFWIP-148:
----------------------------------------
We may have to live with Andy's suggestion of documenting in the RN.
Do we know all the modified error codes to document in the Rel. Note ?
[~bmaxwell], [~raggz], if there are issues with this, bring it up.
> Artemis logging codes/IDs have changed for CORE protocol
> --------------------------------------------------------
>
> Key: WFWIP-148
> URL: https://issues.jboss.org/browse/WFWIP-148
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Justin Bertram
> Priority: Blocker
>
> Artemis logging codes for CORE protocol has changed in scope of jira: https://issues.apache.org/jira/browse/ARTEMIS-1018
> For example in WF14 if standalone JMS client failed to connect then it was logged with code AMQ119007:
> {code}
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
> {code}
> but newly it would have code AMQ219007:
> {code}
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219007: Cannot connect to server(s). Tried with all available servers.]
> {code}
> This is problem for any user/customer who had monitoring based on those codes as this will require to change it.
> The reason for change was because those codes were duplicated between AMQP and CORE protocol. As CORE protocol is default and AMQP is not supported for EAP ti would makes sense to change AMQP codes instead and keep codes for CORE protocol without any change.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (SWSQE-459) Speed up main pipeline (not including test parallelization)
by Filip Brychta (Jira)
[ https://issues.jboss.org/browse/SWSQE-459?page=com.atlassian.jira.plugin.... ]
Filip Brychta resolved SWSQE-459.
---------------------------------
Resolution: Done
Istio installation, kiali build/install and bookinfo installation take only 12 minutes now all together.
> Speed up main pipeline (not including test parallelization)
> -----------------------------------------------------------
>
> Key: SWSQE-459
> URL: https://issues.jboss.org/browse/SWSQE-459
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Minor
>
> SWSQE-450 identified a few options how to speed up main pipeline:
> * Istio-and-Kiali-on-Openshift is not allowed to be run in parallel so it's the bottle neck right now -> run it in parallel but make sure it's not running concurrently on shared openshift cluster.
> * bookinfo installation takes ~6 minutes, it should be faster when done together with istio install in previous step if possible
> * Install Kiali takes ~9 minutes, we need to find out what is the longest part. e.g. if it's building it can be run in parallel with previous step (building does not need to wait for istio installation, only deploying has to)
> Note that this task is only to speed up the pipeline itself which will save a few minutes maximally. Another step will be to create multiple openshift clusters to be able run more pipelines concurrently.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFWIP-148) Artemis logging codes/IDs have changed for CORE protocol
by Justin Bertram (Jira)
[ https://issues.jboss.org/browse/WFWIP-148?page=com.atlassian.jira.plugin.... ]
Justin Bertram commented on WFWIP-148:
--------------------------------------
[~dimitris], any code change at this point is going to be problematic because it would mean a difference between AMQ and EAP. This change has already been released to customers in AMQ 7.2.2. I don't think AMQ wants to change error codes _again_ in the next release.
It's not clear to me how modified error codes are worse than duplicate error codes. The duplicate error codes were a clear bug (although not tested by EAP). Modified error codes are potentially a problem for some users but not technically a bug. It seems to me that any customer who cares about the error codes would be impacted either way.
> Artemis logging codes/IDs have changed for CORE protocol
> --------------------------------------------------------
>
> Key: WFWIP-148
> URL: https://issues.jboss.org/browse/WFWIP-148
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Justin Bertram
> Priority: Blocker
>
> Artemis logging codes for CORE protocol has changed in scope of jira: https://issues.apache.org/jira/browse/ARTEMIS-1018
> For example in WF14 if standalone JMS client failed to connect then it was logged with code AMQ119007:
> {code}
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
> {code}
> but newly it would have code AMQ219007:
> {code}
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219007: Cannot connect to server(s). Tried with all available servers.]
> {code}
> This is problem for any user/customer who had monitoring based on those codes as this will require to change it.
> The reason for change was because those codes were duplicated between AMQP and CORE protocol. As CORE protocol is default and AMQP is not supported for EAP ti would makes sense to change AMQP codes instead and keep codes for CORE protocol without any change.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3002) Enhance performance of PMML using scorecards
by Lance Leverich (Jira)
[ https://issues.jboss.org/browse/DROOLS-3002?page=com.atlassian.jira.plugi... ]
Lance Leverich updated DROOLS-3002:
-----------------------------------
Component/s: PMML
> Enhance performance of PMML using scorecards
> --------------------------------------------
>
> Key: DROOLS-3002
> URL: https://issues.jboss.org/browse/DROOLS-3002
> Project: Drools
> Issue Type: Enhancement
> Components: PMML
> Affects Versions: 7.12.0.Final
> Reporter: Lance Leverich
> Assignee: Lance Leverich
> Priority: Major
> Labels: drools-core
>
> Re-factoring of the classes and mechanisms that generate rules and classes from a PMML resource that contains a Scorecard model.
> # Make further usage of POJOs to replace any types declared within the rule file
> # Make the generation of rules and classes be more direct (i.e. reduce/remove the rules engine use in generating rules and classes)
> # Reduce the rules generated so that the number of steps required to apply a model is minimized
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-2552) KieBase Deserialization: NullPointerException
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-2552?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-2552.
---------------------------------
Resolution: Explained
To properly serialize a KieBase you'll need to use DroolsObjectOutputStream/DroolsObjectInputStream. Replace the plain ObjectStreams you used with them and your test will succeed.
> KieBase Deserialization: NullPointerException
> ---------------------------------------------
>
> Key: DROOLS-2552
> URL: https://issues.jboss.org/browse/DROOLS-2552
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.7.0.Final
> Environment: Windows 7, Java 1.8, Drools 7.7.0.Final, jBPM 7.7.0.Final
> Reporter: Florian Braun
> Assignee: Mario Fusco
> Priority: Critical
>
> I have run into an issue with the KieBase serialization throwing a NullPointerException when using exists and parentheses around an or when rules are in a RuleFlowGroup.
> Example rules:
> package com.sample.rules
> rule "Your First Rule"
> ruleflow-group "group1"
> when
> exists ( String(this == "Hello") or String(this == "World") )
> then
> System.out.println("Hello or World");
> end
> rule "Your Second Rule"
> ruleflow-group "group1"
> when
> $string: String(this == "Hello World")
> then
> System.out.println($string);
> end
> Having the first rule wrap the or in () will cause a deserialization NPE:
> Exception in thread "main" java.lang.NullPointerException
> at org.drools.core.common.BaseNode.getSinks(BaseNode.java:241)
> at org.drools.core.impl.KnowledgeBaseImpl.rewireNodeAfterDeserialization(KnowledgeBaseImpl.java:494)
> at org.drools.core.impl.KnowledgeBaseImpl.rewireNodeAfterDeserialization(KnowledgeBaseImpl.java:511)
> at org.drools.core.impl.KnowledgeBaseImpl.rewireNodeAfterDeserialization(KnowledgeBaseImpl.java:511)
> at org.drools.core.impl.KnowledgeBaseImpl.rewireNodeAfterDeserialization(KnowledgeBaseImpl.java:511)
> at org.drools.core.impl.KnowledgeBaseImpl.rewireReteAfterDeserialization(KnowledgeBaseImpl.java:489)
> at org.drools.core.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:483)
> ....
> Some testing shows this:
> If the first rule is on its own then this error does *not* occur.
> If the first rule does not use () the error does *not* occur. This of course means that the rule behaves differently
> If the rules are not in an rfg this error does *not* occur
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFWIP-148) Artemis logging codes/IDs have changed for CORE protocol
by Dimitris Andreadis (Jira)
[ https://issues.jboss.org/browse/WFWIP-148?page=com.atlassian.jira.plugin.... ]
Dimitris Andreadis commented on WFWIP-148:
------------------------------------------
[~bilge], we know this will impact EAP customers if they depend on detecting the AMQ119007 error code, so what would be the impact if we keep the same codes for CORE and change them for AMQP instead? [~martyn-taylor] [~jbertram]
Then if we cannot decide which impact is worse, we could seek someone higher up (MarkL?) to make a decision.
Or, revert the https://issues.apache.org/jira/browse/ARTEMIS-1018 fix altogether, which seems to be only a minor issue, causing nevertheless some trouble
Or find some middle ground solution, like revert the change but add some CORE / AMQP string in the text message to allow distinguishing which protocol the failure refers to.
> Artemis logging codes/IDs have changed for CORE protocol
> --------------------------------------------------------
>
> Key: WFWIP-148
> URL: https://issues.jboss.org/browse/WFWIP-148
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Justin Bertram
> Priority: Blocker
>
> Artemis logging codes for CORE protocol has changed in scope of jira: https://issues.apache.org/jira/browse/ARTEMIS-1018
> For example in WF14 if standalone JMS client failed to connect then it was logged with code AMQ119007:
> {code}
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
> {code}
> but newly it would have code AMQ219007:
> {code}
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219007: Cannot connect to server(s). Tried with all available servers.]
> {code}
> This is problem for any user/customer who had monitoring based on those codes as this will require to change it.
> The reason for change was because those codes were duplicated between AMQP and CORE protocol. As CORE protocol is default and AMQP is not supported for EAP ti would makes sense to change AMQP codes instead and keep codes for CORE protocol without any change.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months