[JBoss JIRA] (WFCORE-1469) Support match-comparison operation for if-command
by Thomas Darimont (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1469?page=com.atlassian.jira.plugi... ]
Thomas Darimont updated WFCORE-1469:
------------------------------------
Description:
Conditional expressions are great help for creating generic wildfly configurations with the CLI.
Currently the {{comparison-operations}} for the {{if-expression}} are limited to
- equal (==)
- not equal (!=)
- lesser than (<)
- not lesser than (>=)
- greater than (>)
- not greater than (<=)
I'd propose an additional comparison operation: a regex based match operation with the symbol {{~=}}
wheras the left operand is a string to match against the right operand which is a regex string.
This would enable a simple way to do feature flag detection via partial regex matches.
The following sequence demonstrates this use case:
{code}
-Dfeatures="activemq jgroups"
{code}
{code}
if (features ~= ".*activemq.*") of /:resolve-expression(expression=${features})
echo configuring activemq
end-if
if (features ~= ".*jgroups.*") of /:resolve-expression(expression=${features})
echo configuring jgroups
end-if
if (features ~= ".*postgres.*") of /:resolve-expression(expression=${features})
echo configuring postgres
end-if
{code}
Example:
{code}
-Dfeatures="feature1 feature2"
[default@local:9990 /] if (features ~= ".*feature1.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature1
[default@local:9990 /] end-if
configuring feature1
[default@local:9990 /] if (features ~= ".*feature2.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature2
[default@local:9990 /] end-if
configuring feature2
[default@local:9990 /] if (features ~= ".*feature3.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature3
[default@local:9990 /] end-if
[default@local:9990 /]
{code}
was:
Conditional expressions are great help for creating generic wildfly configurations with the CLI.
Currently the {{comparison-operations}} for the {{if-expression}} are limited to
- equal (==)
- not equal (!=)
- lesser than (<)
- not lesser than (>=)
- greater than (>)
- not greater than (<=)
I'd propose an additional comparison operation: a regex based match operation with the symbol {{~=}}
wheras the left operand is a string to match against the right operand which is a regex string.
This would enable a simple way to do feature flag detection via partial regex matches.
The following sequence demonstrates this use case:
{code}
-Dfeatures="activemq jgroups"
{code}
{code}
if (features ~= ".*activemq.*") of /:resolve-expression(expression=${features})
echo configuring activemq
end-if
if (features ~= ".*jgroups.*") of /:resolve-expression(expression=${features})
echo configuring jgroups
end-if
if (features ~= ".*postgres.*") of /:resolve-expression(expression=${features})
echo configuring postgres
end-if
{code}
Example:
{code}
[default@local:9990 /] if (features ~= ".*feature1.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature1
[default@local:9990 /] end-if
configuring feature1
[default@local:9990 /] if (features ~= ".*feature2.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature2
[default@local:9990 /] end-if
configuring feature1
[default@local:9990 /] if (features ~= ".*feature3.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature3
[default@local:9990 /] end-if
[default@local:9990 /]
{code}
> Support match-comparison operation for if-command
> -------------------------------------------------
>
> Key: WFCORE-1469
> URL: https://issues.jboss.org/browse/WFCORE-1469
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Thomas Darimont
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> Conditional expressions are great help for creating generic wildfly configurations with the CLI.
> Currently the {{comparison-operations}} for the {{if-expression}} are limited to
> - equal (==)
> - not equal (!=)
> - lesser than (<)
> - not lesser than (>=)
> - greater than (>)
> - not greater than (<=)
> I'd propose an additional comparison operation: a regex based match operation with the symbol {{~=}}
> wheras the left operand is a string to match against the right operand which is a regex string.
> This would enable a simple way to do feature flag detection via partial regex matches.
> The following sequence demonstrates this use case:
> {code}
> -Dfeatures="activemq jgroups"
> {code}
> {code}
> if (features ~= ".*activemq.*") of /:resolve-expression(expression=${features})
> echo configuring activemq
> end-if
> if (features ~= ".*jgroups.*") of /:resolve-expression(expression=${features})
> echo configuring jgroups
> end-if
> if (features ~= ".*postgres.*") of /:resolve-expression(expression=${features})
> echo configuring postgres
> end-if
> {code}
> Example:
> {code}
> -Dfeatures="feature1 feature2"
> [default@local:9990 /] if (features ~= ".*feature1.*") of /:resolve-expression(expression=${features})
> [default@local:9990 /] echo configuring feature1
> [default@local:9990 /] end-if
> configuring feature1
> [default@local:9990 /] if (features ~= ".*feature2.*") of /:resolve-expression(expression=${features})
> [default@local:9990 /] echo configuring feature2
> [default@local:9990 /] end-if
> configuring feature2
> [default@local:9990 /] if (features ~= ".*feature3.*") of /:resolve-expression(expression=${features})
> [default@local:9990 /] echo configuring feature3
> [default@local:9990 /] end-if
> [default@local:9990 /]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
- 1
- 0
[JBoss JIRA] (WFCORE-1469) Support match-comparison operation for if-command
by Thomas Darimont (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1469?page=com.atlassian.jira.plugi... ]
Thomas Darimont updated WFCORE-1469:
------------------------------------
Description:
Conditional expressions are great help for creating generic wildfly configurations with the CLI.
Currently the {{comparison-operations}} for the {{if-expression}} are limited to
- equal (==)
- not equal (!=)
- lesser than (<)
- not lesser than (>=)
- greater than (>)
- not greater than (<=)
I'd propose an additional comparison operation: a regex based match operation with the symbol {{~=}}
wheras the left operand is a string to match against the right operand which is a regex string.
This would enable a simple way to do feature flag detection via partial regex matches.
The following sequence demonstrates this use case:
{code}
-Dfeatures="activemq jgroups"
{/code}
{code}
if (features ~= ".*activemq.*") of /:resolve-expression(expression=${features})
echo configuring activemq
end-if
if (features ~= ".*jgroups.*") of /:resolve-expression(expression=${features})
echo configuring jgroups
end-if
if (features ~= ".*postgres.*") of /:resolve-expression(expression=${features})
echo configuring postgres
end-if
{/code}
Example:
{code}
[default@local:9990 /] if (features ~= ".*feature1.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature1
[default@local:9990 /] end-if
configuring feature1
[default@local:9990 /] if (features ~= ".*feature2.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature2
[default@local:9990 /] end-if
configuring feature1
[default@local:9990 /] if (features ~= ".*feature3.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature3
[default@local:9990 /] end-if
[default@local:9990 /]
{/code}
was:
Conditional expressions are great help for creating generic wildfly configurations with the CLI.
Currently the {{comparison-operations}} for the {{if-expression}} are limited to
- equal (==)
- not equal (!=)
- lesser than (<)
- not lesser than (>=)
- greater than (>)
- not greater than (<=)
I'd propose an additional comparison operation: a regex based match operation with the symbol {{~=}}
wheras the left operand is a string to match against the right operand which is a regex string.
This would enable a simple way to do feature flag detection via partial regex matches.
The following sequence demonstrates this use case:
[code]
-Dfeatures="activemq jgroups"
[/code]
[code]
if (features ~= ".*activemq.*") of /:resolve-expression(expression=${features})
echo configuring activemq
end-if
if (features ~= ".*jgroups.*") of /:resolve-expression(expression=${features})
echo configuring jgroups
end-if
if (features ~= ".*postgres.*") of /:resolve-expression(expression=${features})
echo configuring postgres
end-if
[/code]
Example:
[code]
[default@local:9990 /] if (features ~= ".*feature1.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature1
[default@local:9990 /] end-if
configuring feature1
[default@local:9990 /] if (features ~= ".*feature2.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature2
[default@local:9990 /] end-if
configuring feature1
[default@local:9990 /] if (features ~= ".*feature3.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature3
[default@local:9990 /] end-if
[default@local:9990 /]
[/code]
> Support match-comparison operation for if-command
> -------------------------------------------------
>
> Key: WFCORE-1469
> URL: https://issues.jboss.org/browse/WFCORE-1469
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Thomas Darimont
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> Conditional expressions are great help for creating generic wildfly configurations with the CLI.
> Currently the {{comparison-operations}} for the {{if-expression}} are limited to
> - equal (==)
> - not equal (!=)
> - lesser than (<)
> - not lesser than (>=)
> - greater than (>)
> - not greater than (<=)
> I'd propose an additional comparison operation: a regex based match operation with the symbol {{~=}}
> wheras the left operand is a string to match against the right operand which is a regex string.
> This would enable a simple way to do feature flag detection via partial regex matches.
> The following sequence demonstrates this use case:
> {code}
> -Dfeatures="activemq jgroups"
> {/code}
> {code}
> if (features ~= ".*activemq.*") of /:resolve-expression(expression=${features})
> echo configuring activemq
> end-if
> if (features ~= ".*jgroups.*") of /:resolve-expression(expression=${features})
> echo configuring jgroups
> end-if
> if (features ~= ".*postgres.*") of /:resolve-expression(expression=${features})
> echo configuring postgres
> end-if
> {/code}
> Example:
> {code}
> [default@local:9990 /] if (features ~= ".*feature1.*") of /:resolve-expression(expression=${features})
> [default@local:9990 /] echo configuring feature1
> [default@local:9990 /] end-if
> configuring feature1
> [default@local:9990 /] if (features ~= ".*feature2.*") of /:resolve-expression(expression=${features})
> [default@local:9990 /] echo configuring feature2
> [default@local:9990 /] end-if
> configuring feature1
> [default@local:9990 /] if (features ~= ".*feature3.*") of /:resolve-expression(expression=${features})
> [default@local:9990 /] echo configuring feature3
> [default@local:9990 /] end-if
> [default@local:9990 /]
> {/code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
- 1
- 0
[JBoss JIRA] (WFCORE-1469) Support match-comparison operation for if-command
by Thomas Darimont (JIRA)
Thomas Darimont created WFCORE-1469:
---------------------------------------
Summary: Support match-comparison operation for if-command
Key: WFCORE-1469
URL: https://issues.jboss.org/browse/WFCORE-1469
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Thomas Darimont
Assignee: Alexey Loubyansky
Priority: Minor
Conditional expressions are great help for creating generic wildfly configurations with the CLI.
Currently the {{comparison-operations}} for the {{if-expression}} are limited to
- equal (==)
- not equal (!=)
- lesser than (<)
- not lesser than (>=)
- greater than (>)
- not greater than (<=)
I'd propose an additional comparison operation: a regex based match operation with the symbol {{~=}}
wheras the left operand is a string to match against the right operand which is a regex string.
This would enable a simple way to do feature flag detection via partial regex matches.
The following sequence demonstrates this use case:
[code]
-Dfeatures="activemq jgroups"
[code]
[code]
if (features ~= ".*activemq.*") of /:resolve-expression(expression=${features})
echo configuring activemq
end-if
if (features ~= ".*jgroups.*") of /:resolve-expression(expression=${features})
echo configuring jgroups
end-if
if (features ~= ".*postgres.*") of /:resolve-expression(expression=${features})
echo configuring postgres
end-if
[code]
Example:
[code]
[default@local:9990 /] if (features ~= ".*feature1.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature1
[default@local:9990 /] end-if
configuring feature1
[default@local:9990 /] if (features ~= ".*feature2.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature2
[default@local:9990 /] end-if
configuring feature1
[default@local:9990 /] if (features ~= ".*feature3.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature3
[default@local:9990 /] end-if
[default@local:9990 /]
[code]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
- 1
- 0
[JBoss JIRA] (WFCORE-1469) Support match-comparison operation for if-command
by Thomas Darimont (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1469?page=com.atlassian.jira.plugi... ]
Thomas Darimont updated WFCORE-1469:
------------------------------------
Description:
Conditional expressions are great help for creating generic wildfly configurations with the CLI.
Currently the {{comparison-operations}} for the {{if-expression}} are limited to
- equal (==)
- not equal (!=)
- lesser than (<)
- not lesser than (>=)
- greater than (>)
- not greater than (<=)
I'd propose an additional comparison operation: a regex based match operation with the symbol {{~=}}
wheras the left operand is a string to match against the right operand which is a regex string.
This would enable a simple way to do feature flag detection via partial regex matches.
The following sequence demonstrates this use case:
[code]
-Dfeatures="activemq jgroups"
[/code]
[code]
if (features ~= ".*activemq.*") of /:resolve-expression(expression=${features})
echo configuring activemq
end-if
if (features ~= ".*jgroups.*") of /:resolve-expression(expression=${features})
echo configuring jgroups
end-if
if (features ~= ".*postgres.*") of /:resolve-expression(expression=${features})
echo configuring postgres
end-if
[/code]
Example:
[code]
[default@local:9990 /] if (features ~= ".*feature1.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature1
[default@local:9990 /] end-if
configuring feature1
[default@local:9990 /] if (features ~= ".*feature2.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature2
[default@local:9990 /] end-if
configuring feature1
[default@local:9990 /] if (features ~= ".*feature3.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature3
[default@local:9990 /] end-if
[default@local:9990 /]
[/code]
was:
Conditional expressions are great help for creating generic wildfly configurations with the CLI.
Currently the {{comparison-operations}} for the {{if-expression}} are limited to
- equal (==)
- not equal (!=)
- lesser than (<)
- not lesser than (>=)
- greater than (>)
- not greater than (<=)
I'd propose an additional comparison operation: a regex based match operation with the symbol {{~=}}
wheras the left operand is a string to match against the right operand which is a regex string.
This would enable a simple way to do feature flag detection via partial regex matches.
The following sequence demonstrates this use case:
[code]
-Dfeatures="activemq jgroups"
[code]
[code]
if (features ~= ".*activemq.*") of /:resolve-expression(expression=${features})
echo configuring activemq
end-if
if (features ~= ".*jgroups.*") of /:resolve-expression(expression=${features})
echo configuring jgroups
end-if
if (features ~= ".*postgres.*") of /:resolve-expression(expression=${features})
echo configuring postgres
end-if
[code]
Example:
[code]
[default@local:9990 /] if (features ~= ".*feature1.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature1
[default@local:9990 /] end-if
configuring feature1
[default@local:9990 /] if (features ~= ".*feature2.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature2
[default@local:9990 /] end-if
configuring feature1
[default@local:9990 /] if (features ~= ".*feature3.*") of /:resolve-expression(expression=${features})
[default@local:9990 /] echo configuring feature3
[default@local:9990 /] end-if
[default@local:9990 /]
[code]
> Support match-comparison operation for if-command
> -------------------------------------------------
>
> Key: WFCORE-1469
> URL: https://issues.jboss.org/browse/WFCORE-1469
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Thomas Darimont
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> Conditional expressions are great help for creating generic wildfly configurations with the CLI.
> Currently the {{comparison-operations}} for the {{if-expression}} are limited to
> - equal (==)
> - not equal (!=)
> - lesser than (<)
> - not lesser than (>=)
> - greater than (>)
> - not greater than (<=)
> I'd propose an additional comparison operation: a regex based match operation with the symbol {{~=}}
> wheras the left operand is a string to match against the right operand which is a regex string.
> This would enable a simple way to do feature flag detection via partial regex matches.
> The following sequence demonstrates this use case:
> [code]
> -Dfeatures="activemq jgroups"
> [/code]
> [code]
> if (features ~= ".*activemq.*") of /:resolve-expression(expression=${features})
> echo configuring activemq
> end-if
> if (features ~= ".*jgroups.*") of /:resolve-expression(expression=${features})
> echo configuring jgroups
> end-if
> if (features ~= ".*postgres.*") of /:resolve-expression(expression=${features})
> echo configuring postgres
> end-if
> [/code]
> Example:
> [code]
> [default@local:9990 /] if (features ~= ".*feature1.*") of /:resolve-expression(expression=${features})
> [default@local:9990 /] echo configuring feature1
> [default@local:9990 /] end-if
> configuring feature1
> [default@local:9990 /] if (features ~= ".*feature2.*") of /:resolve-expression(expression=${features})
> [default@local:9990 /] echo configuring feature2
> [default@local:9990 /] end-if
> configuring feature1
> [default@local:9990 /] if (features ~= ".*feature3.*") of /:resolve-expression(expression=${features})
> [default@local:9990 /] echo configuring feature3
> [default@local:9990 /] end-if
> [default@local:9990 /]
> [/code]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
- 1
- 0
[JBoss JIRA] (WFLY-6498) EJBClient UserTransactions with multiple method invocations generate lock conflicts
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6498?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-6498 at 4/12/16 2:33 PM:
--------------------------------------------------------------------
I've been looking at the idea of creating an transaction context called EJBRemoteTransactionContext. This context would be accessible from anywhere on an invocation thread via a ThreadLocal ContextSelector. The EJBRemoteTransactionContext would hold information on current transaction which invocations are wrapped in:
* TransactionID
* Transaction
* TransactionManager
* TransactionSynchronizationRegistry
This is necessary as the Batchmanager does not use the same TransactionManager as the invocation.
If BatchManager had access to this information, it could:
* check to see if the invocation is in transaction scope
* if yes, check to see if there is a Batch associated with the Transaction by checking for an attachment in the transaction synchrnization registry
** if yes, attach that batch to the current thread
** if no, create a new Batch and store it in the transaction synchronization registry and attach it to the current thread
* if no, continue to do things as we do them now
initializing the thread local:
* in EJBRemoteTransactionPropagatingInterceptor
** createOrResumeUserTransaction()
** createOrResumeXidTransaction()
clean up the thread local:
* VersionOneProtocolChannelReceiver
** UserTransactionManagementTask
** XidTransactionManagementTask
* ordinarily, we would want to clean up any Batch() attached to the TransactionSynchronizationRegistry for the current transaction
* this is hard to do, because the commit/rollback messages are handled in different threads and they don't have access to the TransactionSynchronizationRegistry
* but i'm not sure we need to clean up the Batch() which was attached via TransactionSynchronizationRegistry.putResource(CURRENT_TXN_BATCH, batch), as the Transaction should be getting cleaned up after commit/rollback anyway
was (Author: rachmato):
I've been looking at the idea of creating an transaction context called EJBRemoteTransactionContext.
This context would be accessible from anywhere on an invocation thread via a ThreadLocal ContextSelector.
The EJBRemoteTransactionContext would hold information on current transaction which invocation are wrapped in:
* TransactionID
* Transaction
* TransactionManager
* TransactionSynchronizationRegistry
If BatchManager had access to this information, it could:
* check to see if the invocation is in transaction scope
* if yes, check to see if there is a Batch associated with the Transaction by checking for an attachment in the transaction synchrnization registry
** if yes, attach that batch to the current thread
** if no, create a new Batch and store it in the transaction synchronization registry and attach it to the current thread
* if no, continue to do things as we do them now
initializing the thread local:
* in EJBRemoteTransactionPropagatingInterceptor
** createOrResumeUserTransaction()
** createOrResumeXidTransaction()
clean up the thread local:
* VersionOneProtocolChannelReceiver
** UserTransactionManagementTask
** XidTransactionManagementTask
* ordinarily, we would want to clean up any Batch() attached to the TransactionSynchronizationRegistry for the current transaction
* this is hard to do, because the commit/rollback messages are handled in different threads and they don't have access to the TransactionSynchronizationRegistry
* but i'm not sure we need to clean up the Batch() which was attached via TransactionSynchronizationRegistry.putResource(CURRENT_TXN_BATCH, batch), as the Transaction should be getting cleaned up after commit/rollback anyway
> 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: 11.0.0.Alpha1
>
>
> 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
(v6.4.11#64026)
10 years
- 1
- 0
[JBoss JIRA] (WFLY-6498) EJBClient UserTransactions with multiple method invocations generate lock conflicts
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6498?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-6498 at 4/12/16 2:13 PM:
--------------------------------------------------------------------
I've been looking at the idea of creating an transaction context called EJBRemoteTransactionContext.
This context would be accessible from anywhere on an invocation thread via a ThreadLocal ContextSelector.
The EJBRemoteTransactionContext would hold information on current transaction which invocation are wrapped in:
* TransactionID
* Transaction
* TransactionManager
* TransactionSynchronizationRegistry
If BatchManager had access to this information, it could:
* check to see if the invocation is in transaction scope
* if yes, check to see if there is a Batch associated with the Transaction by checking for an attachment in the transaction synchrnization registry
** if yes, attach that batch to the current thread
** if no, create a new Batch and store it in the transaction synchronization registry and attach it to the current thread
* if no, continue to do things as we do them now
initializing the thread local:
* in EJBRemoteTransactionPropagatingInterceptor
** createOrResumeUserTransaction()
** createOrResumeXidTransaction()
clean up the thread local:
* VersionOneProtocolChannelReceiver
** UserTransactionManagementTask
** XidTransactionManagementTask
* ordinarily, we would want to clean up any Batch() attached to the TransactionSynchronizationRegistry for the current transaction
* this is hard to do, because the commit/rollback messages are handled in different threads and they don't have access to the TransactionSynchronizationRegistry
* but i'm not sure we need to clean up the Batch() which was attached via TransactionSynchronizationRegistry.putResource(CURRENT_TXN_BATCH, batch), as the Transaction should be getting cleaned up after commit/rollback anyway
was (Author: rachmato):
I've been looking at the idea of creating an transaction context called EJBRemoteTransactionContext.
This context would be accessible from anywhere on an invocation thread via a ThreadLocal ContextSelector.
The EJBRemoteTransactionContext would hold information on current transaction which invocation are wrapped in:
* TransactionID
* Transaction
* TransactionManager
* TransactionSynchronizationRegistry
If BatchManager had access to this information, it could:
* check to see if the invocation is in transaction scope
* if yes, check to see if there is a Batch associated with the Transaction by checking for an attachment in the transaction synchrnization registry
** if yes, attach that batch to the current thread
** if no, create a new Batch and store it in the transaction synchronization registry and attach it to the current thread
* if no, continue to do things as we do them now
initializing the thread local:
- in EJBRemoteTransactionPropagatingInterceptor
- createOrResumeUserTransaction()
- createOrResumeXidTransaction()
clean up the thread local:
- VersionOneProtocolChannelReceiver
- UserTransactionManagementTask
- XidTransactionManagementTask
- ordinarily, we would want to clean up any Batch() attached to the TransactionSynchronizationRegistry for the current transaction
- this is hard to do, because the commit/rollback messages are handled in different threads and they don't have access to the TransactionSynchronizationRegistry
- but i'm not sure we need to clean up the Batch() which was attached via TransactionSynchronizationRegistry.putResource(CURRENT_TXN_BATCH, batch), as the Transaction should be getting cleaned up after commit/rollback anyway
> 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: 11.0.0.Alpha1
>
>
> 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
(v6.4.11#64026)
10 years
- 1
- 0
[JBoss JIRA] (LOGTOOL-103) Remove the Parameter.targetName() method
by James Perkins (JIRA)
James Perkins created LOGTOOL-103:
-------------------------------------
Summary: Remove the Parameter.targetName() method
Key: LOGTOOL-103
URL: https://issues.jboss.org/browse/LOGTOOL-103
Project: Log Tool
Issue Type: Task
Reporter: James Perkins
Assignee: James Perkins
This method should not be required and doesn't allow, in some edge cases, for multiple annotations to be used on the same parameter.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
- 1
- 0
[JBoss JIRA] (WFLY-6498) EJBClient UserTransactions with multiple method invocations generate lock conflicts
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6498?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-6498 at 4/12/16 2:12 PM:
--------------------------------------------------------------------
I've been looking at the idea of creating an transaction context called EJBRemoteTransactionContext.
This context would be accessible from anywhere on an invocation thread via a ThreadLocal ContextSelector.
The EJBRemoteTransactionContext would hold information on current transaction which invocation are wrapped in:
* TransactionID
* Transaction
* TransactionManager
* TransactionSynchronizationRegistry
If BatchManager had access to this information, it could:
* check to see if the invocation is in transaction scope
* if yes, check to see if there is a Batch associated with the Transaction by checking for an attachment in the transaction synchrnization registry
** if yes, attach that batch to the current thread
** if no, create a new Batch and store it in the transaction synchronization registry and attach it to the current thread
* if no, continue to do things as we do them now
initializing the thread local:
- in EJBRemoteTransactionPropagatingInterceptor
- createOrResumeUserTransaction()
- createOrResumeXidTransaction()
clean up the thread local:
- VersionOneProtocolChannelReceiver
- UserTransactionManagementTask
- XidTransactionManagementTask
- ordinarily, we would want to clean up any Batch() attached to the TransactionSynchronizationRegistry for the current transaction
- this is hard to do, because the commit/rollback messages are handled in different threads and they don't have access to the TransactionSynchronizationRegistry
- but i'm not sure we need to clean up the Batch() which was attached via TransactionSynchronizationRegistry.putResource(CURRENT_TXN_BATCH, batch), as the Transaction should be getting cleaned up after commit/rollback anyway
was (Author: rachmato):
I've been looking at the idea of creating an transaction context called EJBRemoteTransactionContext.
This context would be accessible from anywhere on an invocation thread via a ThreadLocal ContextSelector.
The EJBRemoteTransactionContext would hold information on current transaction which invocation are wrapped in:
- TransactionID
- Transaction
- TransactionManager
- TransactionSynchronizationRegistry
If BatchManager had access to this information, it could:
- check to see if the invocation is in transaction scope
- if yes, check to see if there is a Batch associated with the Transaction by checking for an attachment in the transaction synchrnization registry
- if yes, attach that batch to the current thread
- if no, create a new Batch and store it in the transaction synchronization registry and attach it to the current thread
- if no, continue to do things as we do them now
- initializing the thread local:
- in EJBRemoteTransactionPropagatingInterceptor
- createOrResumeUserTransaction()
- createOrResumeXidTransaction()
- clean up:
- VersionOneProtocolChannelReceiver
- UserTransactionManagementTask
- XidTransactionManagementTask
- ordinarily, we would want to clean up any Batch() attached to the TransactionSynchronizationRegistry for the current transaction
- this is hard to do, because the commit/rollback messages are handled in different threads and they don't have access to the TransactionSynchronizationRegistry
- but i'm not sure we need to clean up the Batch() which was attached via TransactionSynchronizationRegistry.putResource(CURRENT_TXN_BATCH, batch), as the Transaction should be getting cleaned up after commit/rollback anyway
> 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: 11.0.0.Alpha1
>
>
> 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
(v6.4.11#64026)
10 years
- 1
- 0
[JBoss JIRA] (WFLY-6498) EJBClient UserTransactions with multiple method invocations generate lock conflicts
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6498?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-6498:
-------------------------------------------
I've been looking at the idea of creating an transaction context called EJBRemoteTransactionContext.
This context would be accessible from anywhere on an invocation thread via a ThreadLocal ContextSelector.
The EJBRemoteTransactionContext would hold information on current transaction which invocation are wrapped in:
- TransactionID
- Transaction
- TransactionManager
- TransactionSynchronizationRegistry
If BatchManager had access to this information, it could:
- check to see if the invocation is in transaction scope
- if yes, check to see if there is a Batch associated with the Transaction by checking for an attachment in the transaction synchrnization registry
- if yes, attach that batch to the current thread
- if no, create a new Batch and store it in the transaction synchronization registry and attach it to the current thread
- if no, continue to do things as we do them now
- initializing the thread local:
- in EJBRemoteTransactionPropagatingInterceptor
- createOrResumeUserTransaction()
- createOrResumeXidTransaction()
- clean up:
- VersionOneProtocolChannelReceiver
- UserTransactionManagementTask
- XidTransactionManagementTask
- ordinarily, we would want to clean up any Batch() attached to the TransactionSynchronizationRegistry for the current transaction
- this is hard to do, because the commit/rollback messages are handled in different threads and they don't have access to the TransactionSynchronizationRegistry
- but i'm not sure we need to clean up the Batch() which was attached via TransactionSynchronizationRegistry.putResource(CURRENT_TXN_BATCH, batch), as the Transaction should be getting cleaned up after commit/rollback anyway
> 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: 11.0.0.Alpha1
>
>
> 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
(v6.4.11#64026)
10 years
- 1
- 0
[JBoss JIRA] (ELY-494) DigestServerFactory should only use AvailableRealmsCallback to get realms, not the legacy property list
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-494?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-494:
---------------------------------
Upon further reflection, transforming the realm name is probably not a good idea: clients might depend on specific names, and they might be unforgiving about variation. Better to fail the authentication instead.
> DigestServerFactory should only use AvailableRealmsCallback to get realms, not the legacy property list
> -------------------------------------------------------------------------------------------------------
>
> Key: ELY-494
> URL: https://issues.jboss.org/browse/ELY-494
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Reporter: David Lloyd
>
> We use a different delimiter for the {{com.sun.security.sasl.digest.realm}} property than the JDK, which uses commas, spaces, newlines, or tab characters. This makes it impossible to correctly emulate the property to the mechanism while using the callback to acquire the actual list. Since code changes would likely be required to use the new version with only a comma delimiter, it does not serve any compatibility purpose to continue to support this property.
> Instead we should do three things:
> * Eliminate property support from our DigestSaslServer
> * Add a wrapping SaslServerFactory which detects when a mechanism is trying to acquire a realm list by reading the {{com.sun.security.sasl.digest.realm}} property, and uses the AvailableRealmsCallback to populate it (with a flag to support transformation of spaces, tabs, and newlines to NBSP (0xA0), and remove commas)
> * Add a wrapping SaslServerFactory which allows legacy users to specify a value for {{com.sun.security.sasl.digest.realm}}, and uses it to support AvailableRealmsCallback if that property was set, with programmable delimiters
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
- 1
- 0