[JBoss JIRA] (WFLY-12718) Clustering: replicated-cache sampling errors
by Tommasso Borgato (Jira)
[ https://issues.jboss.org/browse/WFLY-12718?page=com.atlassian.jira.plugin... ]
Tommasso Borgato updated WFLY-12718:
------------------------------------
Description:
The issue is about replicated-cache in fail-over tests.
WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
{noformat}
The test is run with wildfly-18.0.0.Final.zip;
The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
hence this looks like a regression;
As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a sampling error;
Here are the runs that exhibit this issue:
- **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
- **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
We also repeated the tests to make sure it can be reproduced:
- **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...]
- **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...]
was:
The issue is about replicated-cache in fail-over tests.
WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
/subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
{noformat}
The test is run with wildfly-18.0.0.Final.zip;
The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
hence this looks like a regression;
As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a sampling error;
Here are the runs that exhibit this issue:
- **22.82% Fail Rate** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
- **0% Fail Rate** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
> Clustering: replicated-cache sampling errors
> --------------------------------------------
>
> Key: WFLY-12718
> URL: https://issues.jboss.org/browse/WFLY-12718
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Final
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The issue is about replicated-cache in fail-over tests.
> WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
> /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
> {noformat}
> The test is run with wildfly-18.0.0.Final.zip;
> The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
> hence this looks like a regression;
> As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a sampling error;
> Here are the runs that exhibit this issue:
> - **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
> We also repeated the tests to make sure it can be reproduced:
> - **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-4684) Parser and Canonical Model Compiler error on Conditional Named Consequence
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4684?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-4684:
--------------------------------
Sprint: 2019 Week 44-46 (from Okt 28)
> Parser and Canonical Model Compiler error on Conditional Named Consequence
> --------------------------------------------------------------------------
>
> Key: DROOLS-4684
> URL: https://issues.jboss.org/browse/DROOLS-4684
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.28.0.Final
> Environment: macOS 10.14.6, OpenJDK 1.8.0_222
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
> Priority: Major
>
> See reproducer here: https://github.com/DuncanDoyle/drools-conditional-named-consequence-issue
> When you use a Conditional Named Consequence {code}if{code} definition directly after an {code}accumulate{code}, Drools gives the following error when parsing the DRL:
> {code}
> [ERROR] Failed to execute goal org.kie:kie-maven-plugin:7.28.0.Final:build (default-build) on project drools-conditional-named-consequence-issue: Execution default-build of goal org.kie:kie-maven-plugin:7.28.0.Final:build failed: Unable to get KieModule, Errors Existed: Error Messages:
> [ERROR] Message [id=1, kieBase=defaultKieBase, level=ERROR, path=rules.drl, line=19, column=0
> [ERROR] text=Unable to resolve ObjectType 'if']
> [ERROR] ---
> [ERROR] Warning Messages:
> [ERROR] ---
> [ERROR] Info Messages:
> [ERROR]
> {code}
> When you add a constraint between the {code}accumulate{code} and the {code}if{code} statement of the Conditional Named Consequence, it works fine.
> Also when you try to generate the canonical model from a DRL that contains a Conditional Named Consequence, you get the following error:
> {code}
> [ERROR] Failed to execute goal org.kie:kie-maven-plugin:7.28.0.Final:generateModel (default-generateModel) on project drools-conditional-named-consequence-issue: A type incompatibility occurred while executing org.kie:kie-maven-plugin:7.28.0.Final:generateModel: org.drools.compiler.lang.descr.NamedConsequenceDescr cannot be cast to org.drools.compiler.lang.descr.PatternDescr
> {code}
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-12725) ajp huge header
by zai xuan (Jira)
zai xuan created WFLY-12725:
-------------------------------
Summary: ajp huge header
Key: WFLY-12725
URL: https://issues.jboss.org/browse/WFLY-12725
Project: WildFly
Issue Type: Bug
Affects Versions: 18.0.0.Final
Environment: windows7
Reporter: zai xuan
Assignee: Brian Stansberry
There are long headers in the AJP connection, resulting in errors.
++++++++++++++++++++
12:44:37,327 ERROR [io.undertow.request] (default I/O-1) UT005001: An exception
occurred processing the request: java.lang.ArrayIndexOutOfBoundsException: 16
at io.undertow.server.protocol.ajp.AjpRequestParser.headers(AjpRequestPa
rser.java:490)
at io.undertow.server.protocol.ajp.AjpRequestParser.parseString(AjpReque
stParser.java:536)
at io.undertow.server.protocol.ajp.AjpRequestParser.parse(AjpRequestPars
er.java:353)
at io.undertow.server.protocol.ajp.AjpReadListener.handleEvent(AjpReadLi
stener.java:169)
at io.undertow.server.protocol.ajp.AjpReadListener.handleEvent(AjpReadLi
stener.java:56)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java
:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(R
eadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
++++++++++++++++++++
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-12724) Improve batch thread-pool configuration to support thread-pool core-size
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12724?page=com.atlassian.jira.plugin... ]
Cheng Fang updated WFLY-12724:
------------------------------
Description:
The batch subsystem thread-pool currently does not allow to configure its core size. Its core size is always the same as its max size. Upon new task submission, a new thread is created up to the max thread limit, even when there are idle thread available. And pooled threads (core threads) will stay active and will not time out. Need to improve the thead pool configuration to allow for more efficient use of thread resources.
current batch subsystem schema snippet:
{code:xml}
<xs:complexType name="thread-poolType">
<xs:annotation>
<xs:documentation>
<![CDATA[
A thread pool executor with an unbounded queue. Such a thread pool has a core size and a queue with no
upper bound. When a task is submitted, if the number of running threads is less than the core size,
a new thread is created. Otherwise, the task is placed in queue. If too many tasks are allowed to be
submitted to this type of executor, an out of memory condition may occur.
The "max-threads" attribute must be used to specify the thread pool size. The nested
"keepalive-time" element may used to specify the amount of time that pool threads should
be kept running when idle; if not specified, threads will run until the executor is shut down.
The "thread-factory" element specifies the bean name of a specific thread factory to use to create worker
threads.
]]>
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="max-threads" type="threads:countType"/>
<xs:element name="keepalive-time" type="threads:time" minOccurs="0"/>
<xs:element name="thread-factory" type="threads:ref" minOccurs="0"/>
</xs:all>
<xs:attribute name="name" use="required" type="xs:string"/>
</xs:complexType>
{code}
Example of batch subsystem in server configuration file:
{code:xml}
<subsystem xmlns="urn:jboss:domain:batch-jberet:2.0">
<default-job-repository name="in-memory"/>
<default-thread-pool name="batch"/>
<job-repository name="in-memory">
<in-memory/>
</job-repository>
<thread-pool name="batch">
<max-threads count="10"/>
<keepalive-time time="30" unit="seconds"/>
</thread-pool>
</subsystem>
{code}
Example of batch subsystem management resources:
{code}
[standalone@localhost:9990 /] /subsystem=batch-jberet:read-resource
{
"outcome" => "success",
"result" => {
"restart-jobs-on-resume" => true,
"security-domain" => undefined,
"default-job-repository" => "in-memory",
"default-thread-pool" => "batch",
"in-memory-job-repository" => {"in-memory" => undefined},
"jdbc-job-repository" => undefined,
"thread-factory" => undefined,
"thread-pool" => {"batch" => undefined}
}
}
{code}
was:
The batch subsystem thread-pool currently does not allow to configure its core size. Its core size is always the same as its max size. Upon new task submission, a new thread is created up to the max thread limit, even when there are idle thread available. And pooled threads (core threads) will stay active and will not time out. Need to improve the thead pool configuration to allow for more efficient use of thread resources.
current batch subsystem schema snippet:
{code:xml}
<xs:complexType name="thread-poolType">
<xs:annotation>
<xs:documentation>
<![CDATA[
A thread pool executor with an unbounded queue. Such a thread pool has a core size and a queue with no
upper bound. When a task is submitted, if the number of running threads is less than the core size,
a new thread is created. Otherwise, the task is placed in queue. If too many tasks are allowed to be
submitted to this type of executor, an out of memory condition may occur.
The "max-threads" attribute must be used to specify the thread pool size. The nested
"keepalive-time" element may used to specify the amount of time that pool threads should
be kept running when idle; if not specified, threads will run until the executor is shut down.
The "thread-factory" element specifies the bean name of a specific thread factory to use to create worker
threads.
]]>
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="max-threads" type="threads:countType"/>
<xs:element name="keepalive-time" type="threads:time" minOccurs="0"/>
<xs:element name="thread-factory" type="threads:ref" minOccurs="0"/>
</xs:all>
<xs:attribute name="name" use="required" type="xs:string"/>
</xs:complexType>
{code}
Example of batch subsystem in server configuration file:
{code:xml}
<subsystem xmlns="urn:jboss:domain:batch-jberet:2.0">
<default-job-repository name="in-memory"/>
<default-thread-pool name="batch"/>
<job-repository name="in-memory">
<in-memory/>
</job-repository>
<thread-pool name="batch">
<max-threads count="10"/>
<keepalive-time time="30" unit="seconds"/>
</thread-pool>
</subsystem>
{code}
Example of batch subsystem management resources:
{code}
[standalone@localhost:9990 /] /subsystem=batch-jberet:read-resource
{
"outcome" => "success",
"result" => {
"restart-jobs-on-resume" => true,
"security-domain" => undefined,
"default-job-repository" => "in-memory",
"default-thread-pool" => "batch",
"in-memory-job-repository" => {"in-memory" => undefined},
"jdbc-job-repository" => undefined,
"thread-factory" => undefined,
"thread-pool" => {"batch" => undefined}
}
}
{code}
> Improve batch thread-pool configuration to support thread-pool core-size
> ------------------------------------------------------------------------
>
> Key: WFLY-12724
> URL: https://issues.jboss.org/browse/WFLY-12724
> Project: WildFly
> Issue Type: Feature Request
> Components: Batch
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
>
> The batch subsystem thread-pool currently does not allow to configure its core size. Its core size is always the same as its max size. Upon new task submission, a new thread is created up to the max thread limit, even when there are idle thread available. And pooled threads (core threads) will stay active and will not time out. Need to improve the thead pool configuration to allow for more efficient use of thread resources.
> current batch subsystem schema snippet:
> {code:xml}
> <xs:complexType name="thread-poolType">
> <xs:annotation>
> <xs:documentation>
> <![CDATA[
> A thread pool executor with an unbounded queue. Such a thread pool has a core size and a queue with no
> upper bound. When a task is submitted, if the number of running threads is less than the core size,
> a new thread is created. Otherwise, the task is placed in queue. If too many tasks are allowed to be
> submitted to this type of executor, an out of memory condition may occur.
> The "max-threads" attribute must be used to specify the thread pool size. The nested
> "keepalive-time" element may used to specify the amount of time that pool threads should
> be kept running when idle; if not specified, threads will run until the executor is shut down.
> The "thread-factory" element specifies the bean name of a specific thread factory to use to create worker
> threads.
> ]]>
> </xs:documentation>
> </xs:annotation>
> <xs:all>
> <xs:element name="max-threads" type="threads:countType"/>
> <xs:element name="keepalive-time" type="threads:time" minOccurs="0"/>
> <xs:element name="thread-factory" type="threads:ref" minOccurs="0"/>
> </xs:all>
> <xs:attribute name="name" use="required" type="xs:string"/>
> </xs:complexType>
> {code}
> Example of batch subsystem in server configuration file:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:batch-jberet:2.0">
> <default-job-repository name="in-memory"/>
> <default-thread-pool name="batch"/>
> <job-repository name="in-memory">
> <in-memory/>
> </job-repository>
> <thread-pool name="batch">
> <max-threads count="10"/>
> <keepalive-time time="30" unit="seconds"/>
> </thread-pool>
> </subsystem>
> {code}
> Example of batch subsystem management resources:
> {code}
> [standalone@localhost:9990 /] /subsystem=batch-jberet:read-resource
> {
> "outcome" => "success",
> "result" => {
> "restart-jobs-on-resume" => true,
> "security-domain" => undefined,
> "default-job-repository" => "in-memory",
> "default-thread-pool" => "batch",
> "in-memory-job-repository" => {"in-memory" => undefined},
> "jdbc-job-repository" => undefined,
> "thread-factory" => undefined,
> "thread-pool" => {"batch" => undefined}
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-12724) Improve batch thread-pool configuration to support thread-pool core-size
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12724?page=com.atlassian.jira.plugin... ]
Cheng Fang updated WFLY-12724:
------------------------------
Description:
The batch subsystem thread-pool currently does not allow to configure its core size. Its core size is always the same as its max size. Upon new task submission, a new thread is created up to the max thread limit, even when there are idle thread available. And pooled threads (core threads) will stay active and will not time out. Need to improve the thead pool configuration to allow for more efficient use of thread resources.
current batch subsystem schema snippet:
{code:xml}
<xs:complexType name="thread-poolType">
<xs:annotation>
<xs:documentation>
<![CDATA[
A thread pool executor with an unbounded queue. Such a thread pool has a core size and a queue with no
upper bound. When a task is submitted, if the number of running threads is less than the core size,
a new thread is created. Otherwise, the task is placed in queue. If too many tasks are allowed to be
submitted to this type of executor, an out of memory condition may occur.
The "max-threads" attribute must be used to specify the thread pool size. The nested
"keepalive-time" element may used to specify the amount of time that pool threads should
be kept running when idle; if not specified, threads will run until the executor is shut down.
The "thread-factory" element specifies the bean name of a specific thread factory to use to create worker
threads.
]]>
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="max-threads" type="threads:countType"/>
<xs:element name="keepalive-time" type="threads:time" minOccurs="0"/>
<xs:element name="thread-factory" type="threads:ref" minOccurs="0"/>
</xs:all>
<xs:attribute name="name" use="required" type="xs:string"/>
</xs:complexType>
{code}
Example of batch subsystem in server configuration file:
{code:xml}
<subsystem xmlns="urn:jboss:domain:batch-jberet:2.0">
<default-job-repository name="in-memory"/>
<default-thread-pool name="batch"/>
<job-repository name="in-memory">
<in-memory/>
</job-repository>
<thread-pool name="batch">
<max-threads count="10"/>
<keepalive-time time="30" unit="seconds"/>
</thread-pool>
</subsystem>
{code}
Example of batch subsystem management resources:
{code}
[standalone@localhost:9990 /] /subsystem=batch-jberet:read-resource
{
"outcome" => "success",
"result" => {
"restart-jobs-on-resume" => true,
"security-domain" => undefined,
"default-job-repository" => "in-memory",
"default-thread-pool" => "batch",
"in-memory-job-repository" => {"in-memory" => undefined},
"jdbc-job-repository" => undefined,
"thread-factory" => undefined,
"thread-pool" => {"batch" => undefined}
}
}
{code}
> Improve batch thread-pool configuration to support thread-pool core-size
> ------------------------------------------------------------------------
>
> Key: WFLY-12724
> URL: https://issues.jboss.org/browse/WFLY-12724
> Project: WildFly
> Issue Type: Feature Request
> Components: Batch
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
>
> The batch subsystem thread-pool currently does not allow to configure its core size. Its core size is always the same as its max size. Upon new task submission, a new thread is created up to the max thread limit, even when there are idle thread available. And pooled threads (core threads) will stay active and will not time out. Need to improve the thead pool configuration to allow for more efficient use of thread resources.
> current batch subsystem schema snippet:
> {code:xml}
> <xs:complexType name="thread-poolType">
> <xs:annotation>
> <xs:documentation>
> <![CDATA[
> A thread pool executor with an unbounded queue. Such a thread pool has a core size and a queue with no
> upper bound. When a task is submitted, if the number of running threads is less than the core size,
> a new thread is created. Otherwise, the task is placed in queue. If too many tasks are allowed to be
> submitted to this type of executor, an out of memory condition may occur.
> The "max-threads" attribute must be used to specify the thread pool size. The nested
> "keepalive-time" element may used to specify the amount of time that pool threads should
> be kept running when idle; if not specified, threads will run until the executor is shut down.
> The "thread-factory" element specifies the bean name of a specific thread factory to use to create worker
> threads.
> ]]>
> </xs:documentation>
> </xs:annotation>
> <xs:all>
> <xs:element name="max-threads" type="threads:countType"/>
> <xs:element name="keepalive-time" type="threads:time" minOccurs="0"/>
> <xs:element name="thread-factory" type="threads:ref" minOccurs="0"/>
> </xs:all>
> <xs:attribute name="name" use="required" type="xs:string"/>
> </xs:complexType>
> {code}
> Example of batch subsystem in server configuration file:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:batch-jberet:2.0">
> <default-job-repository name="in-memory"/>
> <default-thread-pool name="batch"/>
> <job-repository name="in-memory">
> <in-memory/>
> </job-repository>
> <thread-pool name="batch">
> <max-threads count="10"/>
> <keepalive-time time="30" unit="seconds"/>
> </thread-pool>
> </subsystem>
> {code}
> Example of batch subsystem management resources:
> {code}
> [standalone@localhost:9990 /] /subsystem=batch-jberet:read-resource
> {
> "outcome" => "success",
> "result" => {
> "restart-jobs-on-resume" => true,
> "security-domain" => undefined,
> "default-job-repository" => "in-memory",
> "default-thread-pool" => "batch",
> "in-memory-job-repository" => {"in-memory" => undefined},
> "jdbc-job-repository" => undefined,
> "thread-factory" => undefined,
> "thread-pool" => {"batch" => undefined}
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-12723) Add a mp-config Galleon layer
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12723:
---------------------------------------
Summary: Add a mp-config Galleon layer
Key: WFLY-12723
URL: https://issues.jboss.org/browse/WFLY-12723
Project: WildFly
Issue Type: Enhancement
Components: MP Config
Reporter: Brian Stansberry
Assignee: Brian Stansberry
As we work on adding MP OpenAPI, MP JWT and MP FT, we're going to want to add a Galleon layer for each in order to allow customization of the precise set of functionality a user wants.
Each of these has a dependency on MP Config, so we should add a layer independent of the current 'observability' layer so the other layers can depend on config without provisioning health/metrics/opentracing.
The 'observability' layer itself would depend on mp-config.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months