[JBoss JIRA] (WFCORE-851) Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-851?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-851:
------------------------------------------------
Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1248156|https://bugzilla.redhat.com/show_bug.cgi?id=1248156] from ON_QA to VERIFIED
> Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-851
> URL: https://issues.jboss.org/browse/WFCORE-851
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Brad Maxwell
> Assignee: Filippe Spolti
> Fix For: 2.0.5.CR1
>
>
> Description of problem:
> EJB CLient was configured with DNS FQDN to configure access to a remote EJB. If run a simple test adding an entry in /etc/hosts file pointing that FQDN to localhost for tests everything works. However, after finish the tests and remove the entry, the client still connects to localhost instead of resolve the new IP address. Even adding networkaddress.cache.ttl=30 inside security settings didn't work too.
> How reproducible:
> Everytime you use DNS names to connect to a remote EJB.
> Steps to Reproduce:
> 1. Configure a simple client that connects to a remote EJB using dns name
> 2. add an entry in /etc/hosts mapping the dns name to localhost
> 3. run the client code
> 4. remove the entry in /etc/hosts
> 5. run the client code again
> Actual results:
> EJB remote is still reached from localhost
> Expected results:
> After changing DNS record EJB will be reached in this new address
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5520) Manually migrated EAP 6.x profiles fail to boot due to 'default-clustered-sfsb-cache' used in runtime
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5520?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5520:
---------------------------------
Due Date: 28/Jan/16
Setting due date in 2 days from now.
> Manually migrated EAP 6.x profiles fail to boot due to 'default-clustered-sfsb-cache' used in runtime
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-5520
> URL: https://issues.jboss.org/browse/WFLY-5520
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR2
> Reporter: Eduardo Martins
> Assignee: Radoslav Husar
> Priority: Critical
> Attachments: eap-6.1-migrated-configs.zip, eap-6.4-migrated-configs.zip
>
>
> If you try (curated) EAP 6 standalone-ha.xml configuration on WildFly the server will fail to boot due to an EJB3 subsystem attribute.
> Server boot console log:
> mbp:migration-tests emmartins$ ./default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT/bin/standalone.sh -c standalone-ha.xml
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/emmartins/wildfly/migration-tests/default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT
> JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 11:37:25,583 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 11:37:25,896 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 11:37:25,985 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) starting
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 7) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 15) WFLYCTL0028: Attribute 'default-clustered-sfsb-cache' in the resource at address '/subsystem=ejb3' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,385 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: "WFLYEJB0451: Attribute 'default-clustered-sfsb-cache' is not supported on current version servers; it is only allowed if its value matches 'default-sfsb-cache'"
> 11:37:27,586 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem ejb3 boot operations"
> 11:37:27,588 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem ejb3 boot operations\""
> 11:37:27,591 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 11:37:27,594 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 11:37:27,603 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) stopped in 6ms
> Attached is the standalone-ha.xml config, with just threads subsystem removed, and web subsystem migrated to undertow, that should be able to boot the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5834) NPE handling request to /clusterbench/ejbservlet
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5834?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-5834:
--------------------------------------
Ok, did some investigation on this. So here is the code failing with an NPE:
{code:java}
@Override
public boolean containsLockOrBackupLock(Object key) {
return getLockedKeys().contains(key) || getBackupLockedKeys().contains(key);
}
{code}
And if you look at getBackupLockedKeys() - which is returning 'null', it sounds like (at first glance) that it's impossible for it to be 'null':
{code:java}
@Override
public Set<Object> getBackupLockedKeys() {
return backupKeyLocks == null ?
InfinispanCollections.emptySet() : backupKeyLocks;
}
{code}
Indeed either, the backupKeyLocks are not null, and returned, or the an empy collections is returned. So my assumption here is that backupKeyLocks being volatile, it get "nullified" after passing the check:
{code:java}
/** Holds all the locks for which the local node is a secondary data owner. */
protected volatile Set<Object> backupKeyLocks = null;
{code}
However, this is 1) an assumption (I completly may have misunderstand what happens here) and 2) it does gave a way to fix the issue. I'm thinking adding a synchronized block would fix the issue but it's certainly not worth it. A try-catch to silence the exception would also work, but potentially swallows other issues (and so on).
So IMHO, I'm honestly not sure what to do. I'm guessing, ignoring the issue and moving on maybe the best option here, but maybe someone else (more familliar with both the code base and the product behavior) could have a better idea ?
> 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: Romain Pelisse
>
> 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)
9 years, 11 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-987:
------------------------------------
I believe that this problem is caused by drools/jbpm interaction and in particular by the fact that jbpm is triggering a reentrant flushing of the propagation queue as demonstrated by the following stack trace. We need to figure out if we can avoid this reentrant flushing or even better if we can make it safer.
{code}
org.jbpm.workflow.instance.WorkflowRuntimeException: [droolsTest.RFGAB:47 - :4] -- null
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:179)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:366)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:325)
at org.jbpm.workflow.instance.impl.ExtendedNodeInstanceImpl.triggerCompleted(ExtendedNodeInstanceImpl.java:44)
at org.jbpm.workflow.instance.node.StateBasedNodeInstance.triggerCompleted(StateBasedNodeInstance.java:341)
at org.jbpm.workflow.instance.node.StateBasedNodeInstance.triggerCompleted(StateBasedNodeInstance.java:318)
at org.jbpm.workflow.instance.node.RuleSetNodeInstance.signalEvent(RuleSetNodeInstance.java:124)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.signalEvent(WorkflowProcessInstanceImpl.java:490)
at org.jbpm.process.instance.event.DefaultSignalManager.internalSignalEvent(DefaultSignalManager.java:82)
at org.jbpm.process.instance.event.DefaultSignalManager$SignalAction.execute(DefaultSignalManager.java:181)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2003)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.executeQueuedActions(StatefulKnowledgeSessionImpl.java:1548)
at org.jbpm.process.instance.event.DefaultSignalManager.signalEvent(DefaultSignalManager.java:74)
at org.jbpm.process.instance.ProcessRuntimeImpl$3.afterRuleFlowGroupDeactivated(ProcessRuntimeImpl.java:458)
at org.drools.core.event.AgendaEventSupport.fireAfterRuleFlowGroupDeactivated(AgendaEventSupport.java:180)
at org.drools.core.common.DefaultAgenda.getNextFocus(DefaultAgenda.java:552)
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1341)
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274)
at org.drools.test.RulesJUnitTest$1.afterRuleFlowGroupActivated(RulesJUnitTest.java:87)
at org.drools.core.event.AgendaEventSupport.fireAfterRuleFlowGroupActivated(AgendaEventSupport.java:152)
at org.drools.core.common.DefaultAgenda.activateRuleFlowGroup(DefaultAgenda.java:707)
at org.drools.core.common.DefaultAgenda.activateRuleFlowGroup(DefaultAgenda.java:695)
at org.jbpm.workflow.instance.node.RuleSetNodeInstance.internalTrigger(RuleSetNodeInstance.java:88)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:173)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:366)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:325)
at org.jbpm.workflow.instance.node.StartNodeInstance.triggerCompleted(StartNodeInstance.java:73)
at org.jbpm.workflow.instance.node.StartNodeInstance.internalTrigger(StartNodeInstance.java:44)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:173)
at org.jbpm.ruleflow.instance.RuleFlowProcessInstance.internalStart(RuleFlowProcessInstance.java:35)
at org.jbpm.process.instance.impl.ProcessInstanceImpl.start(ProcessInstanceImpl.java:236)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.start(WorkflowProcessInstanceImpl.java:439)
at org.jbpm.process.instance.ProcessRuntimeImpl.startProcessInstance(ProcessRuntimeImpl.java:208)
at org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:191)
at org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:183)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.startProcess(StatefulKnowledgeSessionImpl.java:1797)
at org.drools.test.RulesJUnitTest$ThreadAB.run(RulesJUnitTest.java:174)
Caused by: java.lang.NullPointerException
at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:343)
at org.drools.core.common.TupleSetsImpl.removeInsert(TupleSetsImpl.java:158)
at org.drools.core.common.TupleSetsImpl.addDelete(TupleSetsImpl.java:97)
at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:285)
at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:256)
at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:351)
at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:333)
at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:357)
at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:173)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:68)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2003)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.executeQueuedActions(StatefulKnowledgeSessionImpl.java:1548)
at org.jbpm.process.instance.event.DefaultSignalManager.signalEvent(DefaultSignalManager.java:74)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.setState(WorkflowProcessInstanceImpl.java:377)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.setState(WorkflowProcessInstanceImpl.java:384)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.nodeInstanceCompleted(WorkflowProcessInstanceImpl.java:592)
at org.jbpm.workflow.instance.node.EndNodeInstance.internalTrigger(EndNodeInstance.java:72)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:173)
... 41 more
{code}
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Mario Fusco
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-987:
----------------------------------
Assignee: Marco Rietveld (was: Mario Fusco)
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Marco Rietveld
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6071) Mixed domain test suite should test using the legacy domain.xml files
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-6071:
--------------------------------------
Summary: Mixed domain test suite should test using the legacy domain.xml files
Key: WFLY-6071
URL: https://issues.jboss.org/browse/WFLY-6071
Project: WildFly
Issue Type: Task
Components: Domain Management, Test Suite
Reporter: Brian Stansberry
The mixed domain testsuite is doing a lot of testing starting with the current release standard configs, then manipulating to get to something interoperable, and then launching a slave.
This is fine, but we need explicit coverage of the primary use case: take a config that worked in the legacy release, install it on the DC, and then have the slave start, confirming that the slave was able to join.
This is basically what users will do -- take profiles that worked and try and use them with a current DC and legacy slaves. Trying to take new profiles and adapt them to work on legacy slaves is more of a corner case. And testing that corner case as the primary coverage leads to holes, where the "correction" logic ends up hiding problems that shouldn't be hidden, e.g. WFCORE-1311.
So, for each legacy release we should boot the current DC with the standard domain.xml for that release and then start a legacy slave from that release.
We may need to apply some correction here too, but if we do it's a good opportunity to check why it's necessary, and whether a more user-friendly solution can be found.
That's not 100% coverage as there are things that weren't in our standard domain.xml, but it's a good smoke test. Subsystem specific test suites can check for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (LOGTOOL-76) JBoss Logging Processor should support WSDLException
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-76?page=com.atlassian.jira.plugin... ]
James Perkins closed LOGTOOL-76.
--------------------------------
Resolution: Duplicate Issue
This isn't quite a duplicate of LOGTOOL-79, but it would solve the issue so I'm closing it for now.
> JBoss Logging Processor should support WSDLException
> ----------------------------------------------------
>
> Key: LOGTOOL-76
> URL: https://issues.jboss.org/browse/LOGTOOL-76
> Project: Log Tool
> Issue Type: Bug
> Reporter: Tom Cunningham
> Assignee: David Lloyd
>
> This is a jboss-logging-processor issue - javax.wsdl.WSDLException has constructors :
> {code}
> public WSDLException(java.lang.String faultCode,
> java.lang.String msg,
> java.lang.Throwable t)
> public WSDLException(java.lang.String faultCode,
> java.lang.String msg)
> {code}
> When I try to localize with this :
> {code}
> /**
> * couldNotFindServiceInTheWSDL method definition.
> * @param portName the portName
> * @param definitionDocumentBaseURI definitionDocumentBaseURI
> * @return WSDLException
> */
> @Message(id = 35436, value = "Could not find service %s in the WSDL %s")
> WSDLException couldNotFindServiceInTheWSDL(String portName, String definitionDocumentBaseURI);
> {code}
> I see compilation errors because jboss-logging-processor doesn't know how to support the WSDLException constructors. We should support them.
> {noformat}
> Failure:
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[189,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[197,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[206,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months