[JBoss JIRA] (WFLY-5550) Formalize web session clustering modules into a proper subsystem
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-5550?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-5550:
-------------------------------
Fix Version/s: 13.0.0.Beta1
(was: 12.0.0.Final)
> Formalize web session clustering modules into a proper subsystem
> ----------------------------------------------------------------
>
> Key: WFLY-5550
> URL: https://issues.jboss.org/browse/WFLY-5550
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.CR3
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 13.0.0.Beta1
>
>
> Currently, the coupling between the undertow subsystem and the modules required for distributed web session manager and single sign-on manager support is very loose.
> Consequently, misconfiguration (e.g. a missing "web" cache-container) can prevent deployment from succeeding without an adequate explanation.
> The subsystem would define the requisite cache-container, exposed as a capability.
> This subsystem would exposes a number of profiles, containing the configuration traditionally specified in jboss-web.xml, as well as the cache configuration to use (specified by cache-container + cache name). jboss-web.xml would only need to reference a profile by name, or, if unspecified, use the default profile.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-6464) JPA 2.2 Support
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-6464?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-6464:
-------------------------------
Fix Version/s: 13.0.0.Beta1
(was: 12.0.0.Final)
> JPA 2.2 Support
> ---------------
>
> Key: WFLY-6464
> URL: https://issues.jboss.org/browse/WFLY-6464
> Project: WildFly
> Issue Type: Sub-task
> Components: JPA / Hibernate
> Reporter: David Lloyd
> Assignee: Scott Marlow
> Fix For: 13.0.0.Beta1
>
>
> From JPA 2.2 specification appendix section A.1:
> {code}
> A.1 Maintenance Release Draft
> Created document from Java Persistence 2.1 Final Release specification.
> The following annotations have been marked @Repeatable:
> AssociationOverride
> AttributeOverride
> Convert
> JoinColumn
> MapKeyJoinColumn
> NamedEntityGraph
> NamedNativeQuery
> NamedQuery
> NamedStoredProcedureQuery
> PersistenceContext
> PersistenceUnit
> PrimaryKeyJoinColumn
> SecondaryTable
> SqlResultSetMapping
> SequenceGenerator
> TableGenerator
> Added SequenceGenerators and TableGenerators annotations.
> Added support for CDI injection into AttributeConverter classes.
> Added support for the mapping of the following java.time types:
> java.time.LocalDate
> java.time.LocalTime
> java.time.LocalDateTime
> java.time.OffsetTime
> java.time.OffsetDateTime
> Added default Stream getResultStream() method to Query interface.
> Added default Stream<X> getResultStream() method to TypedQuery interface.
> Replaced reference to JAR file specification in persistence provider bootstrapping section with more general reference to Java SE service provider requirements.
> Updated persistence.xml and orm.xml schemas to 2.2 versions.
> Updated Related Documents.
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-7100) Add JGroups-based SingletonServiceBuilderFactory implementation
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-7100?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-7100:
-------------------------------
Fix Version/s: 13.0.0.Beta1
(was: 12.0.0.Final)
> Add JGroups-based SingletonServiceBuilderFactory implementation
> ---------------------------------------------------------------
>
> Key: WFLY-7100
> URL: https://issues.jboss.org/browse/WFLY-7100
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 13.0.0.Beta1
>
>
> The singleton subsystem currently requires the Infinispan subsystem. To minimize the requirements for using the singleton subsystem within the context of the host-controller, we should reimplement singleton service using JGroups directly, instead of requiring an Infinispan cache.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-6958) Use more intuitive values for consistent-hash-strategy
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-6958?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-6958:
-------------------------------
Fix Version/s: 13.0.0.Beta1
(was: 12.0.0.Final)
> Use more intuitive values for consistent-hash-strategy
> ------------------------------------------------------
>
> Key: WFLY-6958
> URL: https://issues.jboss.org/browse/WFLY-6958
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 13.0.0.Beta1
>
>
> Currently consistent-hash-strategy can have on of 2 values: INTRA_CACHE vs INTER_CACHE.
> This was initially meant to describe a consistent hash that would be consistent within a cache vs across multiple caches within a cache container. In retrospect, these value are not very descriptive.
> Better would be consistent-hash-strategy="AGE|ADDRESS" or "AGE|NAME", where the strategy uses the cache view sorted by either age, or name/address.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-6498) EJBClient UserTransactions with multiple method invocations generate lock conflicts
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-6498?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-6498:
-------------------------------
Fix Version/s: 13.0.0.Beta1
(was: 12.0.0.Final)
> EJBClient UserTransactions with multiple method invocations generate lock conflicts
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6498
> URL: https://issues.jboss.org/browse/WFLY-6498
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
> Fix For: 13.0.0.Beta1
>
>
> Using the EJBClient library, we should be able to do the following from a standalone EJBClient application:
> // create a UserTransaction associated with a clustered server node X
> // make an invocation on an EJB on X
> // make an invocation on an EJB on X
> // commit the UserTransaction
> However, doing so results in this exception which occurs during processing of the second invocation:
> {noformat}
> [0m[31m11:16:22,580 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-57) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166] and requestor GlobalTransaction:<node-0>:120:local. Lock is held by GlobalTransaction:<node-0>:118:local
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAndRecord(AbstractLockingInterceptor.java:190)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:192)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:113)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:70)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:77)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:176)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:153)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:87)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:49)
> at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:244)
> at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:124)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:333)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> {noformat}
> The exception does not arise if we perform only one invocation within the UserTransaction.
> This exception is repeatable.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-7304) Compensations subsystem
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-7304?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-7304:
-------------------------------
Fix Version/s: 13.0.0.Beta1
(was: 12.0.0.Final)
> Compensations subsystem
> -----------------------
>
> Key: WFLY-7304
> URL: https://issues.jboss.org/browse/WFLY-7304
> Project: WildFly
> Issue Type: Task
> Components: Transactions
> Reporter: Gytis Trikleris
> Assignee: Ondra Chaloupka
> Priority: Minor
> Fix For: 13.0.0.Beta1
>
>
> Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too.
> The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months