[JBoss JIRA] (WFLY-5770) Lock TimeoutException on CacheRegistry.close()
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5770?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-5770:
-------------------------------
Issue Type: Bug (was: Task)
> Lock TimeoutException on CacheRegistry.close()
> ----------------------------------------------
>
> Key: WFLY-5770
> URL: https://issues.jboss.org/browse/WFLY-5770
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR5
>
>
> Just happened on node shutdown when testing locally.
> {noformat}
> 19:22:21,114 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0004: Undertow 1.3.7.Final stopping
> 19:22:21,114 ERROR [stderr] (ServerService Thread Pool -- 82) Exception in thread "ServerService Thread Pool -- 82" org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on node2 in behalf of transaction GlobalTransaction:<node2>:4223:local. Current owner GlobalTransaction:<node2>:4217:local.
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:224)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.checkForPendingLock(DefaultPendingLockManager.java:196)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForKey(DefaultPendingLockManager.java:115)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:190)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:115)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:121)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:71)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:48)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:366)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:230)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:48)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:304)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:286)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:48)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1634)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:558)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:549)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:452)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:296)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistry.lambda$close$0(CacheRegistry.java:101)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.service.concurrent.StampedLockServiceExecutor.close(StampedLockServiceExecutor.java:55)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistry.close(CacheRegistry.java:96)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistryFactory$1.close(CacheRegistryFactory.java:56)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.RegistryBuilder.stop(RegistryBuilder.java:88)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.service.AsynchronousServiceBuilder$2.run(AsynchronousServiceBuilder.java:130)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at java.lang.Thread.run(Thread.java:745)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) Suppressed: org.infinispan.commons.CacheException: javax.transaction.RollbackException: Transaction marked as rollback only.
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.close(ActiveTransactionBatch.java:50)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistry.lambda$close$0(CacheRegistry.java:102)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) ... 9 more
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) Caused by: javax.transaction.RollbackException: Transaction marked as rollback only.
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.transaction.tm.DummyTransaction.setRollbackOnly(DummyTransaction.java:146)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:374)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:230)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:48)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:304)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:286)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:48)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1634)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:558)
> 19:22:21,120 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:549)
> 19:22:21,120 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:452)
> 19:22:21,120 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:296)
> 19:22:21,120 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistry.lambda$close$0(CacheRegistry.java:101)
> 19:22:21,120 ERROR [stderr] (ServerService Thread Pool -- 82) ... 9 more
> 19:22:31,124 WARN [org.infinispan.transaction.impl.TransactionTable] (ServerService Thread Pool -- 88) ISPN000100: Stopping, but there are 1 local transactions and 0 remote transactions that did not finish in time.
> 19:22:31,125 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 88) WFLYCLINF0003: Stopped routing cache from web container
> 19:22:31,128 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel web
> 19:22:31,128 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel web
> 19:22:31,141 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0050: WildFly Full 10.0.0.CR5-SNAPSHOT (WildFly Core 2.0.3.Final) stopped in 25086ms
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (JGRP-1985) Message: make initial size of headers configurable
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-1985?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-1985:
------------------------------------
[~belaban] why not make 4 the default? Building blocks (e.g. {{RequestCorrelator}}) also add a header, so it would make sense to leave a slot for the building blocks by default.
> Message: make initial size of headers configurable
> --------------------------------------------------
>
> Key: JGRP-1985
> URL: https://issues.jboss.org/browse/JGRP-1985
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> By default a message creates a {{Headers}} instance of 3. This is usually enough (transport, either {{NAKACK2}} or {{UNICAST3}}, and possibly fragmentation). However, if a message needs 4 or more headers, there's a resize which is an additional copy of 2 small arrays.
> Goal: make the initial headers size configurable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-5907) NullPointerException during deployment ejb-ref with mappedName
by Marco Zanker (JIRA)
[ https://issues.jboss.org/browse/WFLY-5907?page=com.atlassian.jira.plugin.... ]
Marco Zanker updated WFLY-5907:
-------------------------------
Description:
If deploying a ejb3 SSB with a ejb reference to another bean (in my case an old ejb 2 SSB) with a mappedName-parameter, a NullPointerException occurs.
@EJBs({
@EJB(name = "ejb/MyOldEJB2LocalHome", beanInterface=MyOldEJB2LocalHome.class, beanName="oldejb.jar#MyOldEJB2", mappedName = "oldejb/MyOldEJB2Local"),
})
Caused by: java.lang.NullPointerException
at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.process(EjbResourceInjectionA
nnotationProcessor.java:166)
at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.processClass(EjbResourceInjec
tionAnnotationProcessor.java:146)
at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.deploy(EjbResourceInjectionAn
notationProcessor.java:106)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
Seems, if mappedName is declared, always a NullPointerException occurs.
was:
If deploying a ejb3 SSB with a ejb reference to another bean (in my case an old ejb 2 SSB) with a mappedName-parameter, a NullPointerException occurs.
@EJBs({
@EJB(name = "ejb/MyOldEJB2LocalHome", beanInterface=MyOldEJB2LocalHome.class, beanName="oldejb.jar#MyOldEJB2"),
})
Caused by: java.lang.NullPointerException
at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.process(EjbResourceInjectionA
nnotationProcessor.java:166)
at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.processClass(EjbResourceInjec
tionAnnotationProcessor.java:146)
at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.deploy(EjbResourceInjectionAn
notationProcessor.java:106)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
Seems, if mappedName is declared, always a NullPointerException occurs.
> NullPointerException during deployment ejb-ref with mappedName
> --------------------------------------------------------------
>
> Key: WFLY-5907
> URL: https://issues.jboss.org/browse/WFLY-5907
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.2.Final
> Reporter: Marco Zanker
>
> If deploying a ejb3 SSB with a ejb reference to another bean (in my case an old ejb 2 SSB) with a mappedName-parameter, a NullPointerException occurs.
> @EJBs({
> @EJB(name = "ejb/MyOldEJB2LocalHome", beanInterface=MyOldEJB2LocalHome.class, beanName="oldejb.jar#MyOldEJB2", mappedName = "oldejb/MyOldEJB2Local"),
> })
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.process(EjbResourceInjectionA
> nnotationProcessor.java:166)
> at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.processClass(EjbResourceInjec
> tionAnnotationProcessor.java:146)
> at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.deploy(EjbResourceInjectionAn
> notationProcessor.java:106)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> Seems, if mappedName is declared, always a NullPointerException occurs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on JGRP-1989:
---------------------------------------
{quote}I don't agree that most of the messages are large (or that the size is predictable at all). In Infinispan, we send a lot of small messages, e.g. a remote get command only contains a small key, or the response might be just a few bytes to indicate the operation is successful.
{quote}
In many practical use cases, even if I do many get operations the keys will be of some known type; let's even assume they are {{String}} instances, one might know that they are of some lengths in the ballpark 2 bytes to 15 bytes (for example, but I think that's a reasonable use case). In this scenario, one would make a large pool and split them in stripes of 15 bytes each.
That would "overallocate" frequently but being out of heap memory, it's a cheap but convenient trick.
I simply don't believe that applications are truly "schema-less": even if there's not an upfront declared schema, any app will have a soft schema at least which means there are patterns in data access. Of course it would not be very efficient to mix access to different types in the same cache, but that's not something we encourage either (especially considering a Cache is a generic with K,V to be defined as types).
bq. we send *a lot *of small messages
So this proposal would have *a lot *of benefits ;)
> Bundlers: reuse send buffer when transport == sync.
> ---------------------------------------------------
>
> Key: JGRP-1989
> URL: https://issues.jboss.org/browse/JGRP-1989
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}.
> Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer).
> The code in the bundler should check for this, and copy if async or not copy if sync.
> Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-2907) Trinidad applications runs fine on JBoss AS 7, but on AS 8 generates error
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2907?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed WFLY-2907.
-----------------------------
Fix Version/s: No Release
Resolution: Cannot Reproduce
Closing as there was no response from original submitter for more than a year.
If you can reproduce this problem with latest version of WildFly (atm that is 10.CR5) please reopen the issue.
> Trinidad applications runs fine on JBoss AS 7, but on AS 8 generates error
> --------------------------------------------------------------------------
>
> Key: WFLY-2907
> URL: https://issues.jboss.org/browse/WFLY-2907
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Environment: Trinidad 2
> Reporter: deepak vohra
> Fix For: No Release
>
>
> A Trinidad 2 UI page generates following exception. Application runs fine on JBoss AS 8.
> {noformat}
> java.lang.NullPointerException
> at com.sun.el.ValueExpressionLiteral.getValue(ValueExpressionLiteral.java:79) [javax.el-3.0-b07.jar:3.0-b07]
> at org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:101) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> at org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperty(UIXComponentELTag.java:109) [trinidad-api-2.0.1.jar:2.0.1]
> at org.apache.myfaces.trinidadinternal.taglib.core.nav.CoreCommandLinkTag.setProperties(CoreCommandLinkTag.java:251) [trinidad-impl-2.0.1.jar:2.0.1]
> at org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperties(UIXComponentELTag.java:96) [trinidad-api-2.0.1.jar:2.0.1]
> at javax.faces.webapp.UIComponentELTag.createComponent(UIComponentELTag.java:230) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at javax.faces.webapp.UIComponentClassicTagBase.createChild(UIComponentClassicTagBase.java:504) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at javax.faces.webapp.UIComponentClassicTagBase.findComponent(UIComponentClassicTagBase.java:742) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at javax.faces.webapp.UIComponentClassicTagBase.doStartTag(UIComponentClassicTagBase.java:1309) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at org.apache.myfaces.trinidad.webapp.UIXComponentELTag.doStartTag(UIXComponentELTag.java:67) [trinidad-api-2.0.1.jar:2.0.1]
> at org.apache.jsp.index_jsp._jspx_meth_tr_005fcommandLink_005f0(index_jsp.java:252)
> at org.apache.jsp.index_jsp._jspx_meth_tr_005fform_005f0(index_jsp.java:208)
> at org.apache.jsp.index_jsp._jspx_meth_tr_005fdocument_005f0(index_jsp.java:161)
> at org.apache.jsp.index_jsp._jspx_meth_f_005fview_005f0(index_jsp.java:118)
> at org.apache.jsp.index_jsp._jspService(index_jsp.java:80)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> ... 54 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-5716) Wrong handling of request context for remote EJB calls
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5716?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-5716.
----------------------------------
Fix Version/s: 10.0.0.CR5
(was: 10.0.0.Final)
Resolution: Done
> Wrong handling of request context for remote EJB calls
> ------------------------------------------------------
>
> Key: WFLY-5716
> URL: https://issues.jboss.org/browse/WFLY-5716
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 9.0.0.Final, 10.0.0.CR4
> Reporter: Ste Gr
> Assignee: Martin Kouba
> Fix For: 10.0.0.CR5
>
> Attachments: wfly5716.zip
>
>
> Two applications deployed to Wildfly. The first one provides a singleton remote ejb which uses request scoped beans (in this case a RESOURCE_LOCAL entity manager manged by a CDI producer/disposer, but +all+ request scoped beans are affected). The second application uses that EJB to get some data only accessible by the first application.
> A request is made to the second app from a browser. The app will get the remote EJB and invokes two methods on it. The first method produces the entity manager, accesses the database and returns the result. The entity manager will be disposed again. The second method won't produce a new entity manager but tries to re-use the one from the previous invokation. This fails as the entity manager was disposed.
> If the same use-case is made using the first app everythings works as desired. But it doesn't look right (or the request context is joined because it is the same application). It produces the the entity manager on the first invocation and closes it as soon as the whole request made from the browser is completed. Thats why the second invokation has a valid entity manager to work with.
> I don't know the spec but:
> - either the first EJB invokation from second app to first app is not allowed to dispose the request context (all the request scoped beans)
> - or each invokation must get its own request context (entity manager must be produced and disposed again).
> I've made a [stackoverflow thread|http://stackoverflow.com/q/33826720/1741604] which shows some code examples.
> (JBoss AS 7.1.3.Final is also affected but it is not available in 'affected version/s')
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months