[JBoss JIRA] (DROOLS-669) Create "behavesAs" operator to support traiting
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-669?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-669:
------------------------------------------
Fix Version/s: 7.0.0.Final
(was: 7.0.0.CR2)
> Create "behavesAs" operator to support traiting
> -----------------------------------------------
>
> Key: DROOLS-669
> URL: https://issues.jboss.org/browse/DROOLS-669
> Project: Drools
> Issue Type: Feature Request
> Affects Versions: 6.2.0.CR3
> Reporter: Davide Sottara
> Assignee: Davide Sottara
> Fix For: 7.0.0.Final
>
>
> Define an operator that would check if an object can provide *natively* all the methods required by an interface. This would ensure that, upon donning the interface as a trait, no soft field would be required, and that all methods in the interface would have a concrete implementation.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-607) Match.getObjects() should reflect the patterns' order
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-607?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-607:
------------------------------------------
Fix Version/s: 7.0.0.Final
(was: 7.0.0.CR2)
> Match.getObjects() should reflect the patterns' order
> -----------------------------------------------------
>
> Key: DROOLS-607
> URL: https://issues.jboss.org/browse/DROOLS-607
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.1.0.Final
> Reporter: Davide Sottara
> Assignee: Mark Proctor
> Priority: Minor
> Fix For: 7.0.0.Final
>
>
> if Match.getObjects() is called on a rule with LHS A() B() C(),
> the resulting list will have the matching objects in reversed order
> - that is, [c, b, a] - making it more difficult to analyze it.
> The object's position in the list should reflect the LHS.
> The order should be preserved even when subnetworks are present.
> For example, A() not B() C() should then result in the list [a, *, c ]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING attempts to delete row too late
by John Ament (JIRA)
[ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.... ]
John Ament commented on WFLY-8488:
----------------------------------
unfortunately, while testing in 11 Alpha1, I get the following error:
{code}
stener=https' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
22:31:33,478 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 9) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "jgroups"),
("stack" => "tcp"),
("protocol" => "JDBC_PING")
]) - failure description: "WFLYCTL0155: 'data-source' may not be null"
22:31:33,545 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem jgroups boot operations"
22:31:33,546 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem jgroups boot operations\""
22:31:33,549 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
22:31:33,564 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0050: WildFly Full 11.0.0.Alpha1 (WildFly Core 3.0.0.Beta11) stopped in 9ms
{code}
This is what my stack looks like
{code}
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<!-- socket-protocol type="MPING" socket-binding="jgroups-mping" -->
<protocol type="JDBC_PING">
<property name="datasource_jndi_name">java:jboss/datasources/ExampleDS</property>
</protocol>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK"/>
<protocol type="FD_ALL"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
{code}
> Usage of JGroups JDBC_PING attempts to delete row too late
> ----------------------------------------------------------
>
> Key: WFLY-8488
> URL: https://issues.jboss.org/browse/WFLY-8488
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: John Ament
> Assignee: Paul Ferraro
>
> I was recently working on spinning up a Keycloak cluster. We're deployed to AWS, can't leverage UDP and wanted to have a discovery mechanism that was easy to use, so tried out JDBC_PING. While I got the cluster running, when shutting down a node I would receive an exception on the console when attempting to remove the node from the cluster. It attempts to do a delete on the row in the database after the DataSource has been shut down.
> In my setup, I'm pointing JGroups at the same DataSource as Keycloak, I'm not using the properties approach. I can switch to the properties approach, but I would prefer a single pool rather than multiple connections.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-1560) Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1560?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-1560:
-----------------------------------
After testing this for several hours, I see the reverse of the attached heap graph. Actual heap usage goes down and stays constantly under 80MB. I'll leave the test run a while longer, but it appears to me this is no longer an issue.
> Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1560
> URL: https://issues.jboss.org/browse/WFCORE-1560
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.8.Final
> Environment: OS: CentOS 7.2
> Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
> Wildfly-10.0.0-Final
> Reporter: Michael Noack
> Assignee: Ken Wills
> Priority: Critical
> Fix For: 3.0.0.Beta17
>
> Attachments: JVM-DC.png, console-dc.log, host-controller.log, process-controller.log
>
>
> When executing management commands using jboss-cli.sh against the domain controller of a cluster repeatedly the host controller uses up more and more memory in oldgen. After several thousands of runs of jboss-cli the host controller eventually becomes unresponsive (see attached picture for memory consumption, dc became entirely unresponsive at roughly 6:30am):
> [root@dc broken]# /opt/wildfly-10.0.0.Final-DC/bin/./jboss-cli.sh --connect --user="username" --password="password" --command=":read-children-names(child-type=host)"
> Failed to connect to the controller: The controller is not available at xx.xx.xx.xx:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out
> I discovered the issue when testing whether https://issues.jboss.org/browse/WFCORE-974 was actually resolved in wildfly-10.0.0.Final as advertised. I can confirm that the issue is different, since no OOM-Exceptions are thrown. However the DC still becomes useless, since it won't accept any connections anymore. -I will check whether the work-around from WFCORE-974 applies to this issue as well.- However the work-around from WFCORE-974 doesn't fix this issue.
> Please note that the attached logs are UTC, while the monitoring is UTC+2. Also the collection values are misleading since I haven't adapted my monitoring to the new output of jstat in JDK8. PU and PC are thus MU and MC.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2719) Better use the ManagementResourceRegistration data in JMX query handling
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2719?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2719:
------------------------------------------
https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... is an initial shot at this. Needs testing, plus verification of its performance impact.
> Better use the ManagementResourceRegistration data in JMX query handling
> ------------------------------------------------------------------------
>
> Key: WFCORE-2719
> URL: https://issues.jboss.org/browse/WFCORE-2719
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management, JMX
> Reporter: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match.
> Imagine a query for {code}jboss.*:j2eetype=*,*{code} or, less extreme, {code}jboss.as:socket-binding=*,*{code}
> No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level.
> Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify parts of the tree where a Resource search is necessary.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2720) Adding keystore with generate-self-signed-certificate-host and without key-password specified fails upon first request
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2720?page=com.atlassian.jira.plugi... ]
Stuart Douglas moved JBEAP-10517 to WFCORE-2720:
------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2720 (was: JBEAP-10517)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
Server
(was: Security)
(was: Server)
(was: Web (Undertow))
Affects Version/s: (was: 7.1.0.DR11)
> Adding keystore with generate-self-signed-certificate-host and without key-password specified fails upon first request
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2720
> URL: https://issues.jboss.org/browse/WFCORE-2720
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Server
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: legacy
>
> If I create keystore with generate-self-signed-certificate-host defined, and define https listener to use such keystore, upon first request, when it is being created it fails with \[1\]. Any following requests results in this log message \[2\]. All the requests are hanging till client timeouts them.
> If the key-password is really needed, I believe it should be validated upon configuration creation.
> Also the requests should be terminated and rejected with 500 due server failing to initialize the ssl context due server being incorrectly configured.
>
> \[1\]
> {noformat}
> 13:15:45,781 ERROR [org.xnio.listener] (default I/O-6) XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: WFLYDM0114: Failed to lazily initialize SSL context
> at org.jboss.as.domain.management.security.SSLContextService$LazyInitSSLContext$LazyInitSpi.doInit(SSLContextService.java:231)
> at org.jboss.as.domain.management.security.SSLContextService$LazyInitSSLContext$LazyInitSpi.engineCreateSSLEngine(SSLContextService.java:257)
> at javax.net.ssl.SSLContext.createSSLEngine(SSLContext.java:361)
> at io.undertow.protocols.ssl.UndertowAcceptingSslChannel.accept(UndertowAcceptingSslChannel.java:139)
> at io.undertow.protocols.ssl.UndertowAcceptingSslChannel.accept(UndertowAcceptingSslChannel.java:56)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:131)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> Caused by: java.lang.RuntimeException: WFLYDM0112: Failed to generate self signed certificate
> at org.jboss.as.domain.management.security.FileKeyManagerService.generateFileKeyStore(FileKeyManagerService.java:219)
> at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:185)
> at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:125)
> at org.jboss.as.domain.management.security.AbstractKeyManagerService.getKeyManagers(AbstractKeyManagerService.java:104)
> at org.jboss.as.domain.management.security.SSLContextService$LazyInitSSLContext$LazyInitSpi.doInit(SSLContextService.java:228)
> ... 12 more
> Caused by: java.lang.IllegalArgumentException: password can't be null
> at sun.security.provider.KeyProtector.<init>(KeyProtector.java:135)
> at sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:266)
> at sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)
> at sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)
> at sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)
> at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
> at org.jboss.as.domain.management.security.FileKeyManagerService.generateFileKeyStore(FileKeyManagerService.java:212)
> ... 16 more
> {noformat}
> \[2\]
> {noformat}
> 13:34:05,862 ERROR [org.xnio.listener] (default I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalStateException: SSLContextImpl is not initialized
> at sun.security.ssl.SSLContextImpl.engineCreateSSLEngine(SSLContextImpl.java:207)
> at javax.net.ssl.SSLContext.createSSLEngine(SSLContext.java:361)
> at org.jboss.as.domain.management.security.SSLContextService$LazyInitSSLContext$LazyInitSpi.engineCreateSSLEngine(SSLContextService.java:258)
> at javax.net.ssl.SSLContext.createSSLEngine(SSLContext.java:361)
> at io.undertow.protocols.ssl.UndertowAcceptingSslChannel.accept(UndertowAcceptingSslChannel.java:139)
> at io.undertow.protocols.ssl.UndertowAcceptingSslChannel.accept(UndertowAcceptingSslChannel.java:56)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:131)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2719) Better use the ManagementResourceRegistration data in JMX query handling
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2719?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2719:
-------------------------------------
Description:
For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match.
Imagine a query for {code}jboss.*:j2eetype=*,*{code} or, less extreme, {code}jboss.as:socket-binding=*,*{code}
No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level.
Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify parts of the tree where a Resource search is necessary.
was:
For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match.
Imagine a query for
jboss.*:j2eetype=*,*
or, less extreme:
jboss.as:socket-binding=*,*
No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level.
Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify parts of the tree where a Resource search is necessary.
> Better use the ManagementResourceRegistration data in JMX query handling
> ------------------------------------------------------------------------
>
> Key: WFCORE-2719
> URL: https://issues.jboss.org/browse/WFCORE-2719
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management, JMX
> Reporter: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match.
> Imagine a query for {code}jboss.*:j2eetype=*,*{code} or, less extreme, {code}jboss.as:socket-binding=*,*{code}
> No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level.
> Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify parts of the tree where a Resource search is necessary.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2719) Better use the ManagementResourceRegistration data in JMX query handling
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2719:
----------------------------------------
Summary: Better use the ManagementResourceRegistration data in JMX query handling
Key: WFCORE-2719
URL: https://issues.jboss.org/browse/WFCORE-2719
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management, JMX
Reporter: Brian Stansberry
Fix For: 4.0.0.Beta1
For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match.
Imagine a query for
jboss.*:j2eetype=*,*
or, less extreme:
jboss.as:socket-binding=*,*
No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level.
Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify parts of the tree where a Resource search is necessary.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years