[JBoss JIRA] (WFLY-8972) [GSS](7.1.0) static content under jboss-web.xml overlay directory is not served correctly after the content is updated
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8972?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-11708 to WFLY-8972:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8972 (was: JBEAP-11708)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Target Release: (was: 7.1.0.GA)
Affects Version/s: (was: 7.0.6.GA)
> [GSS](7.1.0) static content under jboss-web.xml overlay directory is not served correctly after the content is updated
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8972
> URL: https://issues.jboss.org/browse/WFLY-8972
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
>
> Static content under jboss-web.xml {{<overlay>}} directory is not served correctly after the content is updated.
> This issue does not happen with the exploded application, so a possible suspect is cache resource handling.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1624) Map Handling with Property Reactive Always Enabled
by KimJohn Quinn (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1624?page=com.atlassian.jira.plugi... ]
KimJohn Quinn commented on DROOLS-1624:
---------------------------------------
I just saw the comments on using Traits. I will explore this as well.
> Map Handling with Property Reactive Always Enabled
> --------------------------------------------------
>
> Key: DROOLS-1624
> URL: https://issues.jboss.org/browse/DROOLS-1624
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Final
> Environment: * JDK8
> * Docker running Alpine
> Reporter: KimJohn Quinn
> Assignee: Mario Fusco
> Priority: Minor
>
> Referencing a conversation on [Google Groups - Drools Usage|https://groups.google.com/forum/?fromgroups#!topic/drools-usage/G7r...] and as requested by Mario Fusco...
> We currently have a ruleset that relies heavily on Map facts. In Drools 6.5 we fire approximately 400 rules.
> In Drools 7.0 we get only about 50 rules unless we add the "<property key="drools.propertySpecific" value="ALLOWED"/>" to the kmodule.xml, in which case we fire the full 400 rules or by using @Watch(*) or @Watch(!*) on the rules. It "seems" like only the first evaluations of the rules are firing and then no others after that.
> Our flow generally follows something like below, within a stateful session, using rules only. We fire all rules per-request then close the session.
> Watch for changes to the Map properties
> If a certain property or properties exist a 'populate' rule fires (calls modify())
> The populate rule enriches the map fact. (calls modify())
> Based on #3, more rules fire when certain properties exist (calls modify())
> We are work heavily with rules that depend on loaded available facts up-front and computed properties throughout evaluation.
> I have a couple of usage questions regarding Drools 7, the default enabling of Property Reactive and using Maps as the facts:
> In general, how do maps work with property reactive and respond to modify/insert events? Does Drools look at the Map as a whole, any change re-evaluates the tree, or each individual property within the map re-evaluates the change?
> In Drools 7, by defaulting the property reactive setting, does that mean all rules need to be annotated or they should they work as is (dao or map-based facts) when using modify/insert?
> For reference, we are relying on this doco https://docs.jboss.org/drools/release/7.0.0.Final/drools-docs/html_single....
> I am looking into details or an example how to properly use Maps in Drools 7 with Property Reactive features always enabled (as suggested per the doco)....
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1624) Map Handling with Property Reactive Always Enabled
by KimJohn Quinn (JIRA)
KimJohn Quinn created DROOLS-1624:
-------------------------------------
Summary: Map Handling with Property Reactive Always Enabled
Key: DROOLS-1624
URL: https://issues.jboss.org/browse/DROOLS-1624
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.0.0.Final
Environment: * JDK8
* Docker running Alpine
Reporter: KimJohn Quinn
Assignee: Mario Fusco
Priority: Minor
Referencing a conversation on [Google Groups - Drools Usage|https://groups.google.com/forum/?fromgroups#!topic/drools-usage/G7r...] and as requested by Mario Fusco...
We currently have a ruleset that relies heavily on Map facts. In Drools 6.5 we fire approximately 400 rules.
In Drools 7.0 we get only about 50 rules unless we add the "<property key="drools.propertySpecific" value="ALLOWED"/>" to the kmodule.xml, in which case we fire the full 400 rules or by using @Watch(*) or @Watch(!*) on the rules. It "seems" like only the first evaluations of the rules are firing and then no others after that.
Our flow generally follows something like below, within a stateful session, using rules only. We fire all rules per-request then close the session.
Watch for changes to the Map properties
If a certain property or properties exist a 'populate' rule fires (calls modify())
The populate rule enriches the map fact. (calls modify())
Based on #3, more rules fire when certain properties exist (calls modify())
We are work heavily with rules that depend on loaded available facts up-front and computed properties throughout evaluation.
I have a couple of usage questions regarding Drools 7, the default enabling of Property Reactive and using Maps as the facts:
In general, how do maps work with property reactive and respond to modify/insert events? Does Drools look at the Map as a whole, any change re-evaluates the tree, or each individual property within the map re-evaluates the change?
In Drools 7, by defaulting the property reactive setting, does that mean all rules need to be annotated or they should they work as is (dao or map-based facts) when using modify/insert?
For reference, we are relying on this doco https://docs.jboss.org/drools/release/7.0.0.Final/drools-docs/html_single....
I am looking into details or an example how to properly use Maps in Drools 7 with Property Reactive features always enabled (as suggested per the doco)....
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-1934) Make number of thread size for ServerService Thread Pool configurable
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1934?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1934:
-------------------------------------
Component/s: Domain Management
(was: Server)
> Make number of thread size for ServerService Thread Pool configurable
> ---------------------------------------------------------------------
>
> Key: WFCORE-1934
> URL: https://issues.jboss.org/browse/WFCORE-1934
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 2.2.0.Final
> Reporter: Masafumi Miura
> Assignee: Jason Greene
> Attachments: ServerServiceThreadPool_ejb_startup_singleton.zip, ServerServiceThreadPool_persistence_unit.zip
>
>
> Provide a way to configure {{maximumPoolSize}} of {{ServerService Thread Pool}}. It defaults to {{Integer.MAX_VALUE}} and it's unable to be changed in the current implementation:
>
> {quote}
> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
> {code}
> 446 public synchronized void start(StartContext context) throws StartException {
> 447 executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 20L, TimeUnit.SECONDS,
> 448 new SynchronousQueue<Runnable>(), threadFactory);
> 449 }
> {code}
> {quote}
> Though the threads will disappear after 20 seconds of finishing a task, ulimit ({{nproc}}, max user processes) has a possibility to run out and "java.lang.OutOfMemoryError: unable to create new native thread" would occur depending on deployed applications. For example, an application coming with many {{<persistence-unit>}} entries in {{persistence.xml}} or a lot of @Startup @Singleton EJB can cause spawning a lot of {{ServerService Thread Pool}} thread.
> Even if ulimit can be configurable and it is recommended to be tuned in a production environment, making {{maximumPoolSize}} of {{ServerService Thread Pool}} configurable would be helpful.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-1934) Make number of thread size for ServerService Thread Pool configurable
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1934?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1934:
----------------------------------------
Assignee: Brian Stansberry (was: Jason Greene)
> Make number of thread size for ServerService Thread Pool configurable
> ---------------------------------------------------------------------
>
> Key: WFCORE-1934
> URL: https://issues.jboss.org/browse/WFCORE-1934
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 2.2.0.Final
> Reporter: Masafumi Miura
> Assignee: Brian Stansberry
> Attachments: ServerServiceThreadPool_ejb_startup_singleton.zip, ServerServiceThreadPool_persistence_unit.zip
>
>
> Provide a way to configure {{maximumPoolSize}} of {{ServerService Thread Pool}}. It defaults to {{Integer.MAX_VALUE}} and it's unable to be changed in the current implementation:
>
> {quote}
> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
> {code}
> 446 public synchronized void start(StartContext context) throws StartException {
> 447 executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 20L, TimeUnit.SECONDS,
> 448 new SynchronousQueue<Runnable>(), threadFactory);
> 449 }
> {code}
> {quote}
> Though the threads will disappear after 20 seconds of finishing a task, ulimit ({{nproc}}, max user processes) has a possibility to run out and "java.lang.OutOfMemoryError: unable to create new native thread" would occur depending on deployed applications. For example, an application coming with many {{<persistence-unit>}} entries in {{persistence.xml}} or a lot of @Startup @Singleton EJB can cause spawning a lot of {{ServerService Thread Pool}} thread.
> Even if ulimit can be configurable and it is recommended to be tuned in a production environment, making {{maximumPoolSize}} of {{ServerService Thread Pool}} configurable would be helpful.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-665) Server-group level jvm settings take precedence over host level settings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-665?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-665:
------------------------------------
Summary: Server-group level jvm settings take precedence over host level settings (was: When host jvm name and server jvm name are same then the host jvm settings are ignored)
> Server-group level jvm settings take precedence over host level settings
> ------------------------------------------------------------------------
>
> Key: WFCORE-665
> URL: https://issues.jboss.org/browse/WFCORE-665
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta5
> Environment: All
> Reporter: Jay SenSharma
> Assignee: Brian Stansberry
> Labels: domain-mode
>
> - If the "host.xml" has the following JVM name defined
> {code}
> <jvms>
> <jvm name="default">
> <heap size="200m" max-size="2000m"/>
> <permgen size="256m" max-size="256m"/>
> <jvm-options>
> <option value="-server"/>
> </jvm-options>
> </jvm>
> <jvm name="Test">
> <heap size="300m" max-size="2500m"/>
> <permgen size="128m" max-size="128m"/>
> </jvm>
> </jvms>
> {code}
> - If the server refers to the above JVM name as following:
> {code}
> <servers>
> <server name="server-one" group="main-server-group" auto-start="true">
> <jvm name="Test"/>
> </server>
> </servers>
> {code}
> - In above case when the server-one is booted that time it takes the value from "server-group" (in this case main-server-group) defined in the domain.xml
> {code}
> <server-groups>
> <server-group name="main-server-group" profile="full">
> <jvm name="default">
> <heap size="64m" max-size="512m"/>
> </jvm>
> {code}
> So the JVM settings defined for JVM name "Test" is overridden by server-group values:
> {code}
> 30201 jboss-modules.jar -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on -D[Server:server-one] -XX:PermSize=128m -XX:MaxPermSize=128m -Xms64m -Xmx512m -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true -Djboss.home.dir=/wildfly-9.0.0.CR1-SNAPSHOT -Djboss.modules.system.pkgs=org.jboss.byteman -Djboss.server.log.dir=/wildfly-9.0.0.CR1-SNAPSHOT/domain/servers/server-one/log -Djboss.server.temp.dir=/wildfly-9.0.0.CR1-SNAPSHOT/domain/servers/server-one/tmp -Djboss.server.data.dir=/wildfly-9.0.0.CR1-SNAPSHOT/domain/servers/server-one/data -Dlogging.configuration=file:/wildfly-9.0.0.CR1-SNAPSHOT/domain/servers/server-one/data/logging.properties
> {code}
> *NOTICE* the JVM runtime value is -Xms64m -Xmx512m, where as it was supposed to be -Xms300m -Xmx2500m as that is the "Test" jvm setting.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8968) Protocol stack for fork channel is missing defined fork protocols
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8968?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-8968:
-------------------------------
Description:
Given the fork definition:
{code:xml}
<channel name="ee" stack="udp">
<fork name="foo">
<protocol type="RSVP"/>
</fork>
</channel>
{code}
And given the code:
{code:java}
@Resource(lookup = "java:jboss/jgroups/factory/foo")
private ChannelFactory factory;
@PostConstruct
public void init() {
try {
Channel channel = this.factory.createChannel("bar");
// This assertion fails!
assert channel.getProtocolStack().findProtocol("RSVP") != null;
} catch (Exception e) {
throw new RuntimeException(e);
}
}
{code}
> Protocol stack for fork channel is missing defined fork protocols
> -----------------------------------------------------------------
>
> Key: WFLY-8968
> URL: https://issues.jboss.org/browse/WFLY-8968
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
>
> Given the fork definition:
> {code:xml}
> <channel name="ee" stack="udp">
> <fork name="foo">
> <protocol type="RSVP"/>
> </fork>
> </channel>
> {code}
> And given the code:
> {code:java}
> @Resource(lookup = "java:jboss/jgroups/factory/foo")
> private ChannelFactory factory;
> @PostConstruct
> public void init() {
> try {
> Channel channel = this.factory.createChannel("bar");
> // This assertion fails!
> assert channel.getProtocolStack().findProtocol("RSVP") != null;
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2526) Domain mode passed unwanted sys props to spawned servers
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2526?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2526:
----------------------------------------
Assignee: Brian Stansberry
> Domain mode passed unwanted sys props to spawned servers
> --------------------------------------------------------
>
> Key: WFCORE-2526
> URL: https://issues.jboss.org/browse/WFCORE-2526
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: John Mazzitelli
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 3.0.0.Beta27
>
>
> This is related to WFCORE-350, except the solution to that only involves filtering out some but not all unwanted sys props.
> I would say the solution should involve any properties, not just jboss.server.xxx properties.
> In my case, I'm trying to inject a javaagent into the host controller but I do NOT want the javaagent in the spawned servers. Because my javaagent uses JBoss Logging (JUL) I'm forced to pass in "-Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager" and
> "-Djava.util.logging.manager=org.jboss.logmanager.LogManager" so the host controller can start up.
> But these gets passed to the spawned servers and causes them to fail to boot up (because while my -javaagent command line argument isn't passed to their JVM, the -D sys props are and those combination of sys props are deadly without a JUL-enabled javaagent).
> See: http://lists.jboss.org/pipermail/wildfly-dev/2017-March/005810.html
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2673) HTTP redirect if both http and https socket-binding is configured for http-interface
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2673?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2673:
----------------------------------------
Assignee: (was: Brian Stansberry)
> HTTP redirect if both http and https socket-binding is configured for http-interface
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-2673
> URL: https://issues.jboss.org/browse/WFCORE-2673
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Ondrej Lukas
>
> In case when both http and https socket-binding is configured for management http-interface and http port is accessed then server tries to redirect automatically to https port. Access http is not possible.
> It causes that it is impossible to connect to http-interface with clients which do not supports https (even if http port is provided by application server), i.e. following ModelControllerClient is not able to connect to http-interface when both http and https socket-binding is configured:
> {code}
> ModelControllerClient client = ModelControllerClient.Factory
> .create(new ModelControllerClientConfiguration.Builder()
> .setProtocol("remote+http")
> .setPort(9990)
> .setHostName("localhost")
> .setConnectionTimeout(10000).build())
> {code}
> See:
> {code}
> curl -v -H 'Upgrade: jboss-remoting' http://localhost:9990
> * Rebuilt URL to: http://localhost:9990/
> * Hostname was NOT found in DNS cache
> * Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 9990 (#0)
> > GET / HTTP/1.1
> > User-Agent: curl/7.38.0
> > Host: localhost:9990
> > Accept: */*
> > Upgrade: jboss-remoting
> >
> < HTTP/1.1 302 Found
> < Connection: keep-alive
> < Location: https://localhost:9993/
> < Content-Length: 0
> < Date: Thu, 13 Apr 2017 11:59:56 GMT
> <
> * Connection #0 to host localhost left intact
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years