[JBoss JIRA] (WFLY-6088) Remoting worker threads runtime current size, queue size, etc are not visible
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-6088:
----------------------------------
Summary: Remoting worker threads runtime current size, queue size, etc are not visible
Key: WFLY-6088
URL: https://issues.jboss.org/browse/WFLY-6088
Project: WildFly
Issue Type: Enhancement
Components: Remoting
Affects Versions: 10.0.0.CR5
Reporter: Brad Maxwell
Assignee: David Lloyd
The remoting subsystem uses a worker-thread-pool which can be configured such as shown below.
The runtime thread pool information is not exposed when doing read-resource:
{code}
/subsystem=remoting:read-resource(include-runtime=true, recursive=true)
{code}
{code}
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
<worker-thread-pool
read-threads="1"
task-core-threads="4"
task-keepalive="60"
task-limit="16384"
task-max-threads="16"
write-threads="1"
/>
<connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
</subsystem>
{code}
In tuning and runtime diagnosis, it would be useful to see the thread pool information such as the current size, queue-size, largest-thread-count, etc similar to the ejb3 subsystem thread pool:
{code}
/subsystem=ejb3/thread-pool=default:read-resource(include-runtime=true, recursive=true)
"result" => {
"active-count" => 0,
"completed-task-count" => 0L,
"current-thread-count" => 0,
"keepalive-time" => {
"time" => 100L,
"unit" => "MILLISECONDS"
},
"largest-thread-count" => 0,
"max-threads" => 10,
"name" => "default",
"queue-size" => 0,
"rejected-count" => 0,
"task-count" => 0L,
"thread-factory" => undefined
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5828) Format differences between default configuration and read/persisted one
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5828?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5828:
---------------------------------
Description:
Neverending classic, just like every release:
{noformat}[rhusar@syrah wildfly-10.0.0.Final-SNAPSHOT]$ diff standalone/configuration/standalone-ha.xml standalone/configuration/standalone_xml_history/standalone-ha.initial.xml
1c1
< <?xml version='1.0' encoding='UTF-8'?>
---
> <?xml version="1.0" ?>
4d3
<
36,37d34
<
<
64c61
< <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
---
> <file-handler name="file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
87d83
<
178a175
> <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
182d178
< <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
186a183
> <!-- Automatically configure pools. Alternatively, max-pool-size can be set to a specific value -->
193c190
< <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
---
> <cache name="distributable" aliases="passivating clustered" passivation-store-ref="infinispan"/>
220c217
< <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default">
---
> <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
226c223
< <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist">
---
> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
234c231
< <cache-container name="ejb" aliases="sfsb" module="org.wildfly.clustering.ejb.infinispan" default-cache="dist">
---
> <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
242c239
< <cache-container name="hibernate" module="org.hibernate.infinispan" default-cache="local-query">
---
> <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
244,247d240
< <local-cache name="local-query">
< <eviction max-entries="10000" strategy="LRU"/>
< <expiration max-idle="100000"/>
< </local-cache>
250c243
< <eviction max-entries="10000" strategy="LRU"/>
---
> <eviction strategy="LRU" max-entries="10000"/>
252a246,249
> <local-cache name="local-query">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
403c400
< <http-listener name="default" redirect-socket="https" socket-binding="http"/>
---
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
418,419c415,416
< <response-header name="server-header" header-value="WildFly/10" header-name="Server"/>
< <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/>
---
> <response-header name="server-header" header-name="Server" header-value="WildFly/10"/>
> <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
434d430
<
446d441
<
{noformat}
was:
Neverending classic, just like every release:
{noformat}
1c1
< <?xml version='1.0' encoding='UTF-8'?>
---
> <?xml version="1.0" ?>
4d3
<
36,37d34
<
<
64c61
< <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
---
> <file-handler name="file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
87d83
<
178a175
> <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
182d178
< <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
186a183
> <!-- Automatically configure pools. Alternatively, max-pool-size can be set to a specific value -->
193c190
< <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
---
> <cache name="distributable" aliases="passivating clustered" passivation-store-ref="infinispan"/>
220c217
< <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default">
---
> <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
226c223
< <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist">
---
> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
234c231
< <cache-container name="ejb" aliases="sfsb" module="org.wildfly.clustering.ejb.infinispan" default-cache="dist">
---
> <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
242c239
< <cache-container name="hibernate" module="org.hibernate.infinispan" default-cache="local-query">
---
> <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
244,247d240
< <local-cache name="local-query">
< <eviction max-entries="10000" strategy="LRU"/>
< <expiration max-idle="100000"/>
< </local-cache>
250c243
< <eviction max-entries="10000" strategy="LRU"/>
---
> <eviction strategy="LRU" max-entries="10000"/>
252a246,249
> <local-cache name="local-query">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
395c392
< <http-listener name="default" redirect-socket="https" socket-binding="http"/>
---
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
410,411c407,408
< <response-header name="server-header" header-value="JBoss-EAP/7" header-name="Server"/>
< <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/>
---
> <response-header name="server-header" header-name="Server" header-value="JBoss-EAP/7"/>
> <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
426d422
<
435d430
<
{noformat}
> Format differences between default configuration and read/persisted one
> -----------------------------------------------------------------------
>
> Key: WFLY-5828
> URL: https://issues.jboss.org/browse/WFLY-5828
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Labels: ux
>
> Neverending classic, just like every release:
> {noformat}[rhusar@syrah wildfly-10.0.0.Final-SNAPSHOT]$ diff standalone/configuration/standalone-ha.xml standalone/configuration/standalone_xml_history/standalone-ha.initial.xml
> 1c1
> < <?xml version='1.0' encoding='UTF-8'?>
> ---
> > <?xml version="1.0" ?>
> 4d3
> <
> 36,37d34
> <
> <
> 64c61
> < <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
> ---
> > <file-handler name="file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
> 87d83
> <
> 178a175
> > <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
> 182d178
> < <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
> 186a183
> > <!-- Automatically configure pools. Alternatively, max-pool-size can be set to a specific value -->
> 193c190
> < <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
> ---
> > <cache name="distributable" aliases="passivating clustered" passivation-store-ref="infinispan"/>
> 220c217
> < <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default">
> ---
> > <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
> 226c223
> < <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist">
> ---
> > <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
> 234c231
> < <cache-container name="ejb" aliases="sfsb" module="org.wildfly.clustering.ejb.infinispan" default-cache="dist">
> ---
> > <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
> 242c239
> < <cache-container name="hibernate" module="org.hibernate.infinispan" default-cache="local-query">
> ---
> > <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
> 244,247d240
> < <local-cache name="local-query">
> < <eviction max-entries="10000" strategy="LRU"/>
> < <expiration max-idle="100000"/>
> < </local-cache>
> 250c243
> < <eviction max-entries="10000" strategy="LRU"/>
> ---
> > <eviction strategy="LRU" max-entries="10000"/>
> 252a246,249
> > <local-cache name="local-query">
> > <eviction strategy="LRU" max-entries="10000"/>
> > <expiration max-idle="100000"/>
> > </local-cache>
> 403c400
> < <http-listener name="default" redirect-socket="https" socket-binding="http"/>
> ---
> > <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> 418,419c415,416
> < <response-header name="server-header" header-value="WildFly/10" header-name="Server"/>
> < <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/>
> ---
> > <response-header name="server-header" header-name="Server" header-value="WildFly/10"/>
> > <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
> 434d430
> <
> 446d441
> <
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6021) Default transaction timeout is not applied for EJB bean when set for second time
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6021?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-6021:
----------------------------------------
It's interesting then that Ondřej reports that a reload doesn't result in a behavior change, only a restart does. (The Steps to Reproduce don't mention a reload but the main JIRA description says reload is ineffective.)
It would be great if this didn't require a reload at all. That's the goal for most any attribute.
> Default transaction timeout is not applied for EJB bean when set for second time
> --------------------------------------------------------------------------------
>
> Key: WFLY-6021
> URL: https://issues.jboss.org/browse/WFLY-6021
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Reporter: Ondřej Chaloupka
> Assignee: Fedor Gavrilov
>
> It seems that transaction subsystem attribute {{default-timeout}} does not have any effect for EJB if it's redefined. It means if I set the default transaction timeout in transaction subystem for second (and next) time it's not applied for EJB beans. It's used the firstly set value.
> The transaction timeout is not changed for EJB when server is reloaded. When server is restarted it refreshes all settings and EJB starts using the expected value for timeout settings.
> If the value is read from subsystem
> {{/subsystem=transactions:read-attribute(name=default-timeout)}}
> it shows correct value (that one set for second time). But EJB seems not applying it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1340) Store "host ignore" data in the domain wide model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1340?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1340:
------------------------------------------
A WFC 2 slave will send its ignore-unused-configuration setting when it registers. If this is set to true, the DC will not use any of this domain wide data in its handling of that slave. That setting means the slave is taking responsibility for informing the DC of what should be ignored. Mixing this WFCORE-1340 functionality into that creates too much complication.
An EAP 6.x slave can't set ignore-unused-configuration, so there is no confusion for that use case, which is the primary one.
> Store "host ignore" data in the domain wide model
> -------------------------------------------------
>
> Key: WFCORE-1340
> URL: https://issues.jboss.org/browse/WFCORE-1340
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
> An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
> Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
> 1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
> 2) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this in 11, so this JIRA would just provide a fallback for 11 DCs managing 10 slaves in case that goal is not met. EAP 6 slaves would not benefit from this though.)
> Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data.
> Proposed structure:
> Resources are at address /host-ignore=*
> Attributes are:
> * slave-api-major-version
> * slave-api-minor-version
> * slave-api-micro-version
> * slave-release
> These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4) from which the api versions can be derived.
> If slave-api-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
> In addition to the above scoping attributes, the following attributes will be supported:
> * ignored-extensions
> * unignored-server-groups
> The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
> The unignored-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile, socket-binding-group and deployment resources will not be ignored; all others will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
> Adding a new group to unignored-server-groups will not cause existing slave HCs to get new data sent to them, at least not in the first round of this work. The slave will need to reconnect to get new data.
> There is other data that could be included in these resources, e.g. fine grained "ignore" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5834) NPE handling request to /clusterbench/ejbservlet
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5834?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-5834:
------------------------------------
Assignee: Radoslav Husar (was: Romain Pelisse)
Thanks for the second pair of eyes Romain! You are right about ternary operator on volatile being prone to still returning null -- both expressions are all evaluated independently. Needs a proper yet efficient synchronization. I ll take it from here, created ISPN-6122 and submitted pull request to infinispan.
> NPE handling request to /clusterbench/ejbservlet
> ------------------------------------------------
>
> Key: WFLY-5834
> URL: https://issues.jboss.org/browse/WFLY-5834
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Reporter: Michal Vinkler
> Assignee: Radoslav Husar
>
> Seen in failover-ejb-ejbservlet-jvmkill-dist-sync scenario.
> 6 seconds after failing perf20 (jvmkill), perf18 logged ISPN000136: Execution error: java.lang.NullPointerException.
> Timeline:
> {code:title=client}
> 2015/11/27 08:23:25:206 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Node 2 (perf20) is down.
> {code}
> {code:title=perf18}
> [JBossINF] [0m[31m08:23:31,049 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-70) ISPN000136: Execution error: java.lang.NullPointerException
> [JBossINF] at org.infinispan.transaction.impl.AbstractCacheTransaction.containsLockOrBackupLock(AbstractCacheTransaction.java:254)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.lambda$getTransactionWithLockedKey$177(DefaultPendingLockManager.java:252)
> [JBossINF] at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8$ValuesView.forEach(EquivalentConcurrentHashMapV8.java:4604)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.forEachTransaction(DefaultPendingLockManager.java:284)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.getTransactionWithLockedKey(DefaultPendingLockManager.java:249)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.checkForPendingLock(DefaultPendingLockManager.java:187)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForKey(DefaultPendingLockManager.java:115)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:190)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:115)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:69)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:76)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:403)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:388)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:412)
> [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:437)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:70)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:60)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:36)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:61)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:234)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:140)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:725)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
> [JBossINF] at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:231)
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:245)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:283)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Another NPE followed right after:
> {code}
> [JBossINF] [0m[31m08:23:31,050 ERROR [io.undertow.request] (default task-70) UT005023: Exception handling request to /clusterbench/ejbservlet: java.lang.NullPointerException
> [JBossINF] at org.infinispan.transaction.impl.AbstractCacheTransaction.containsLockOrBackupLock(AbstractCacheTransaction.java:254)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.lambda$getTransactionWithLockedKey$177(DefaultPendingLockManager.java:252)
> [JBossINF] at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8$ValuesView.forEach(EquivalentConcurrentHashMapV8.java:4604)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.forEachTransaction(DefaultPendingLockManager.java:284)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.getTransactionWithLockedKey(DefaultPendingLockManager.java:249)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.checkForPendingLock(DefaultPendingLockManager.java:187)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForKey(DefaultPendingLockManager.java:115)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:190)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:115)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:69)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:76)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:403)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:388)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:412)
> [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:437)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:70)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:60)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:36)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:61)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:234)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:140)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:725)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
> [JBossINF] at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:231)
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:245)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:283)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Link:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> This issue may be related:
> https://issues.jboss.org/browse/WFLY-5208
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1044) KieBase 'includes' does not handle the inclusion of KieBases that use the same package-names correctly.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1044?page=com.atlassian.jira.plugi... ]
Mario Fusco closed DROOLS-1044.
-------------------------------
Fix Version/s: 6.4.0.CR1
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/cc3a9af55
> KieBase 'includes' does not handle the inclusion of KieBases that use the same package-names correctly.
> -------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1044
> URL: https://issues.jboss.org/browse/DROOLS-1044
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Beta1
> Environment: Mac OS X 10.11.3, Oracle Hotspot 1.8.0_45
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
> Fix For: 6.4.0.CR1
>
>
> KieBase 'includes' does not handle the inclusion of KieBases that use the same package-names correctly.
> I define 2 KJARs, each with a kmodule.xml that defines a KieBase. KJAR1 has a dependency on KJAR2 in its pom.xml.
> The KieBase defined in KJAR1 includes the KieBase defined in KJAR2.
> If the KieBases get their Drools Resources (e.g. .drl) from different packages (e.g. 'rules' and 'rules2', everything works fine, e.g.:
> KJAR1 kmodule.xml:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">
> <kbase name="kbase1" equalsBehavior="equality" default="true" packages="rules" includes="kbase2">
> <ksession name="ksession1" default="true" type="stateful"/>
> </kbase>
> </kmodule>
> {code}
> KAJR2 kmodule.xml:
> {code:xml}
> <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">
> <kbase name="kbase2" equalsBehavior="equality" default="false" packages="rules2">
> <ksession name="ksession2" default="false" type="stateful"/>
> </kbase>
> </kmodule>
> {code}
> However, when both KieBases use the same "packages" name (e.g. 'rules'), only one of the resources gets included in the final KieBase.
> KJAR1 kmodule.xml:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">
> <kbase name="kbase1" equalsBehavior="equality" default="true" packages="rules" includes="kbase2">
> <ksession name="ksession1" default="true" type="stateful"/>
> </kbase>
> </kmodule>
> {code}
> KAJR2 kmodule.xml:
> {code:xml}
> <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">
> <kbase name="kbase2" equalsBehavior="equality" default="false" packages="rules">
> <ksession name="ksession2" default="false" type="stateful"/>
> </kbase>
> </kmodule>
> {code}
> Unit tests with reproducer can be found here: https://github.com/DuncanDoyle/drools-kiebase-include-issue
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months