[JBoss JIRA] (DROOLS-1372) Each call to KieContainer.updateToVersion(ReleaseId version) creates a new classloader for unmodifed rules in the KieModule
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1372?page=com.atlassian.jira.plugi... ]
Bill Tuminaro updated DROOLS-1372:
----------------------------------
Attachment: drools-1372_two.PNG
drools-1372_one.PNG
> Each call to KieContainer.updateToVersion(ReleaseId version) creates a new classloader for unmodifed rules in the KieModule
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1372
> URL: https://issues.jboss.org/browse/DROOLS-1372
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: UpdateToVersionCreatingNewClassloaders.java, drools-1372_one.PNG, drools-1372_two.PNG
>
>
> I have attached a reproducer named UpdateToVersionCreatingNewClassloaders.java that creates a KieContainer with a KieModule that contains a single rule (rule name 1081) and then runs a loop that adds 1 rule and removes 1 rule and calls KieContainer.updateToVersion(). Along the way it creates .dmp files.
> If you examine the .dmp files name updrule#_3.drl (i.e. updrule1_3.drl , updrule3_3.drl ) you will see that the number of classloaders for the rule named org.drools.compiler.integrationTests.Rule_10810DefaultConsequenceInvoker increases by 1 each iteration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (DROOLS-1372) Each call to KieContainer.updateToVersion(ReleaseId version) creates a new classloader for unmodifed rules in the KieModule
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1372?page=com.atlassian.jira.plugi... ]
Bill Tuminaro updated DROOLS-1372:
----------------------------------
Attachment: UpdateToVersionCreatingNewClassloaders.java
> Each call to KieContainer.updateToVersion(ReleaseId version) creates a new classloader for unmodifed rules in the KieModule
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1372
> URL: https://issues.jboss.org/browse/DROOLS-1372
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: UpdateToVersionCreatingNewClassloaders.java
>
>
> I have attached a reproducer named UpdateToVersionCreatingNewClassloaders.java that creates a KieContainer with a KieModule that contains a single rule (rule name 1081) and then runs a loop that adds 1 rule and removes 1 rule and calls KieContainer.updateToVersion(). Along the way it creates .dmp files.
> If you examine the .dmp files name updrule#_3.drl (i.e. updrule1_3.drl , updrule3_3.drl ) you will see that the number of classloaders for the rule named org.drools.compiler.integrationTests.Rule_10810DefaultConsequenceInvoker increases by 1 each iteration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (DROOLS-1372) Each call to KieContainer.updateToVersion(ReleaseId version) creates a new classloader for unmodifed rules in the KieModule
by Bill Tuminaro (JIRA)
Bill Tuminaro created DROOLS-1372:
-------------------------------------
Summary: Each call to KieContainer.updateToVersion(ReleaseId version) creates a new classloader for unmodifed rules in the KieModule
Key: DROOLS-1372
URL: https://issues.jboss.org/browse/DROOLS-1372
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Reporter: Bill Tuminaro
Assignee: Mario Fusco
I have attached a reproducer named UpdateToVersionCreatingNewClassloaders.java that creates a KieContainer with a KieModule that contains a single rule (rule name 1081) and then runs a loop that adds 1 rule and removes 1 rule and calls KieContainer.updateToVersion(). Along the way it creates .dmp files.
If you examine the .dmp files name updrule#_3.drl (i.e. updrule1_3.drl , updrule3_3.drl ) you will see that the number of classloaders for the rule named org.drools.compiler.integrationTests.Rule_10810DefaultConsequenceInvoker increases by 1 each iteration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFCORE-2056) wildfly-openssl - wfssl.dll is not automatically loaded on Windows
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2056?page=com.atlassian.jira.plugi... ]
Stuart Douglas moved JBEAP-7544 to WFCORE-2056:
-----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2056 (was: JBEAP-7544)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
Server
(was: Security)
(was: Server)
Affects Version/s: (was: 7.1.0.DR8)
> wildfly-openssl - wfssl.dll is not automatically loaded on Windows
> ------------------------------------------------------------------
>
> Key: WFCORE-2056
> URL: https://issues.jboss.org/browse/WFCORE-2056
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Server
> Environment: Windows 8.1 Pro, 64b
> OpenSSL taken from JBCS 2.4.6 (OpenSSL 1.0.1e)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Labels: wilfly-openssl
>
> It seems that libraries to support OpenSSL via {{wildfly-openssl}} does not bind automatically under the Windows right now.
> When I am on Linux, to setup OpenSSL, all I need to do is to have installed OpenSSL on my machine or provide path to my custom OpenSSL libs via "org.wildfly.openssl.path" property. Then I start EAP, set up "openssl.TLS" provider and I am ready to go.
> On windows although this seems to be a little bit complicated. When I start EAP with path to my OpenSSL libraries (JBCS OpenSSL) and set up "openssl.TLS" provider, after reload operation I get following error message:
> {code}
> 2016-11-28 12:27:44,512 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:108)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
> at java.security.Provider$Service.newInstance(Unknown Source)
> at sun.security.jca.GetInstance.getInstance(Unknown Source)
> at sun.security.jca.GetInstance.getInstance(Unknown Source)
> at javax.net.ssl.SSLContext.getInstance(Unknown Source)
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:97)
> ... 5 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.wildfly.openssl.SSL.init(SSL.java:81)
> at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:119)
> at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:427)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
> at java.lang.reflect.Constructor.newInstance(Unknown Source)
> ... 10 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.wildfly.openssl.SSL.init(SSL.java:76)
> ... 16 more
> Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path
> at java.lang.ClassLoader.loadLibrary(Unknown Source)
> at java.lang.Runtime.loadLibrary0(Unknown Source)
> at java.lang.System.loadLibrary(Unknown Source)
> at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:188)
> ... 21 more
> {code}
> It seems that "wfssl" library that serves to search and bind OpenSSL libs does not load automatically although it is already present as a module in EAP. When I specify also {{org.wildfly.openssl.libwfssl.path}} property with path to the {{wfssl.dll}} file in the EAP modules, then OpenSSL is successfully initialized during the EAP startup and https requests from clients seems to be working too.
> My expectation here is that when "wfssl.dll" library is present as a module in EAP on Windows, it is loaded automatically and user does not have to specify its location.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (ELY-801) ModifiableSecurityRealm#getRealmIdentityIterator() is a bit wrong
by David Lloyd (JIRA)
David Lloyd created ELY-801:
-------------------------------
Summary: ModifiableSecurityRealm#getRealmIdentityIterator() is a bit wrong
Key: ELY-801
URL: https://issues.jboss.org/browse/ELY-801
Project: WildFly Elytron
Issue Type: Bug
Components: API / SPI
Reporter: David Lloyd
Priority: Minor
After the fixes for iterator closing which pertain mainly to the file system realm, we have a new interface CloseableIterator which adds a close() method which throws IOException. However this doesn't fit the general mold for identity handling, and only the FS realm would ever throw IOException (others would throw SQLException or NamingException for example).
Fix this in a couple ways:
# Drop CloseableIterator and replace it with a ModifiableRealmIdentityIterator which extends {{Iterator<ModifiableRealmIdentity>}} and {{AutoCloseable}}
# Override {{close()}} to throw {{RealmUnavailableException}}
Then make the associated changes to the realm(s).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (ELY-784) Schema problems in elytron-1_0.xsd
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-784?page=com.atlassian.jira.plugin.sy... ]
David Lloyd resolved ELY-784.
-----------------------------
Fix Version/s: 1.1.0.Beta17
Resolution: Done
> Schema problems in elytron-1_0.xsd
> ----------------------------------
>
> Key: ELY-784
> URL: https://issues.jboss.org/browse/ELY-784
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.1.0.Beta17
>
>
> It looks like I made a mistake in the XSD - for whatever reason I was under the impression that it was possible to embed a "choice" under an "all"; my IDE now has decided to point out that this is not allowed (not sure why it didn't do so earlier).
> So now there needs to be a solution which allows this element setup, hopefully without resorting to "sequence".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (DROOLS-1371) Too many classloaders use too much memory for a large rule set
by Bill Tuminaro (JIRA)
Bill Tuminaro created DROOLS-1371:
-------------------------------------
Summary: Too many classloaders use too much memory for a large rule set
Key: DROOLS-1371
URL: https://issues.jboss.org/browse/DROOLS-1371
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Reporter: Bill Tuminaro
Assignee: Mario Fusco
Why are there so many classloaders after I create a KieSession for a KieFileSystem and KieContainer that only contains one rule?
The extra classloaders for each rule are consuming too much memory for a rule set that contains several thousand rules.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFCORE-218) wildfly web management console hangs during deploy from cli
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-218?page=com.atlassian.jira.plugin... ]
Brian Stansberry edited comment on WFCORE-218 at 11/28/16 3:52 PM:
-------------------------------------------------------------------
I briefly considered not holding any long lasting topology lock and simply getting the set of hosts under a short lived lock. But that is not reliable:
1) T1 is doing a domain-wide write, on DC OperationCoordinatorStepHandler gathers the registered servers and creates DomainSlaveHandler to do the HC rollout.
2) New HC starts, connects, gets exclusive lock, starts registration stuff.
3) T1 gets to the Stage.MODEL handler that detects a write, tries to get exclusive lock, blocks
4) New HC reg is completed, exclusive lock released
5) T1 gets lock, proceeds
6) T1 gets to DomainSlaveHandler, rolls out the change to the set of slaves provided in 1) above, which does not include New HC.
7) New HC misses the update.
The situation with servers I believe is simpler. There the set of host and server proxies is a ref to the complete, dynamically updated set. Which servers get called depends on the rollout plan. The rollout plan is created after Stage.MODEL, so the exclusive lock will be held when it is created. So any "New Server" joining in a race with the change will either a) block in registration acquiring the exclusive lock until after the change is complete or b) cause the change to block in Stage.MODEL until reg is complete, with New Server then being picked up by DomainRolloutStepHandler the same as if it had been registered before the change op even began.
The way the server case is handled by DomainRolloutStepHandler suggests a possible easy fix for the host case as well. DomainSlaveHandler should be constructed with a ref to the complete dynamically updated map of host proxies (the way DomainRolloutStepHandler is). It should also be given the set of host names to update, or null if the update is global. If the list of host names is not null, that means the op only targets particular hosts, with no possibility of that set being added to in the course of execution. So, if if the change is global, the write lock in a Stage.MODEL step will ensure that any new host is either registered before DomainSlaveHandler executes, or is blocking waiting for the change op to complete. If the change is not global, the registration of a new slave is irrelevant to DomainSlaveHandler; it just works with the set of hosts it knows about.
Reads still need some thought though. The current behavior of overly aggressively taking the exclusive lock prevents some possible scenarios, like a client periodically reading a bunch of metrics getting a failure because a host or server is removed by another op in the middle of the read. This could be a real scenario now that things like multi-process reads and the query op are supported.
was (Author: brian.stansberry):
I briefly considered not holding any long lasting topology lock and simply getting the set of hosts under a short lived lock. But that is not reliable:
1) T1 is doing a domain-wide write, on DC OperationCoordinatorStepHandler gathers the registered servers and creates DomainSlaveHandler to do the HC rollout.
2) New HC starts, connects, gets exclusive lock, starts registration stuff.
3) T1 gets to the Stage.MODEL handler that detects a write, tries to get exclusive lock, blocks
4) New HC reg is completed, exclusive lock released
5) T1 gets lock, proceeds
6) T1 gets to DomainSlaveHandler, rolls out the change to the set of slaves provided in 1) above, which does not include New HC.
7) New HC misses the update.
The situation with servers I believe is simpler. There the set of host and server proxies is the complete set. Which servers get called depends on the rollout plan. The rollout plan is created after Stage.MODEL, so the exclusive lock will be held when it is created. So any "New Server" joining in a race with the change will either a) block in registration acquiring the exclusinve lock until after the change is complete or b) cause the change to block in Stage.MODEL until reg is complete, with New Server then being picked up by DomainRolloutStepHandler the same as if it had been registered before the change op even began.
The way the server case is handled by DomainRolloutStepHandler suggests a possible easy fix for the host case as well. DomainSlaveHandler should be constructed with a ref to the dynamically changing map of host proxies (the way DomainRolloutStepHandler is). It should also be given the set of host names to update, or null if the update is global. If the list of host names is not null, that means the op only targets particular hosts, with no possibility of that set being added to in the course of execution. So, if if the change is global, the write lock in a Stage.MODEL step will ensure that any new host is either registered before DomainSlaveHandler executes, or is blocking waiting for the change op to complete. If the change is not global, the registration of a new slave is irrelevant to DomainSlaveHandler; it just works with the set of hosts it knows about.
> wildfly web management console hangs during deploy from cli
> -----------------------------------------------------------
>
> Key: WFCORE-218
> URL: https://issues.jboss.org/browse/WFCORE-218
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha1
> Reporter: Ian Kent
> Attachments: threaddump-1415735255304.tdump
>
>
> We are running wildfly in domain mode with the following configuration.
> host A running domain controlller
> host B running host controller with one app sever
> host C running host controller with one app server
> host D running host controller with one app server
> When we deloy war using jboss-cli the web console is blocked for usage until deploy completes. I have run jvisualvm and it does not appear that domain controller process is starved for resources (cpu, memory, threads).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months