[JBoss JIRA] (WFLY-9448) Unrecoverable "..DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state.." after " Unable to acquire lock after 15 seconds"
by kobogian hitis (JIRA)
[ https://issues.jboss.org/browse/WFLY-9448?page=com.atlassian.jira.plugin.... ]
kobogian hitis updated WFLY-9448:
---------------------------------
Description:
On our system, after some time we get this:
javax.ejb.EJBTransactionRolledbackException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4957576549555554536866505268565165695766655070536957516655656852] and requestor GlobalTransaction:<node1>:682146:local. Lock is held by GlobalTransaction:<node1>:681890:local
And then we start getting the following:
ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-2) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
...
ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /contextpath/someXYZResource: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
continouously on most requests without being able to recover.
Then we need to restart. Again if at some point the "Unable to acquire lock after 15 seconds" happens, we start getting errors about the DummyTransaction, which never stop.
I believe "Unable to acquire lock after 15 seconds" should not lead to an unrecoverable state.
Each node runs with: `./standalone.sh -c=standalone-full-ha.xml -u=239.255.200.215 -b=$localIp -bmanagement=$localIp -bprivate=$localIp -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=200` . `jboss.node.name` and `$localIp` only changes between nodes.
was:
On our system, after some time we get this:
javax.ejb.EJBTransactionRolledbackException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4957576549555554536866505268565165695766655070536957516655656852] and requestor GlobalTransaction:<node1>:682146:local. Lock is held by GlobalTransaction:<node1>:681890:local
And then we start getting the following:
ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-2) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
...
ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /contextpath/someXYZResource: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
continouously on most requests without being able to recover.
Then we need to restart. Again if at some point the "Unable to acquire lock after 15 seconds" happens, we start getting errors about the DummyTransaction, which never stop.
I believe "Unable to acquire lock after 15 seconds" should not lead to an unrecoverable state.
> Unrecoverable "..DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state.." after " Unable to acquire lock after 15 seconds"
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9448
> URL: https://issues.jboss.org/browse/WFLY-9448
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Centos
> Reporter: kobogian hitis
> Assignee: Paul Ferraro
>
> On our system, after some time we get this:
> javax.ejb.EJBTransactionRolledbackException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4957576549555554536866505268565165695766655070536957516655656852] and requestor GlobalTransaction:<node1>:682146:local. Lock is held by GlobalTransaction:<node1>:681890:local
> And then we start getting the following:
> ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-2) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
> ...
> ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /contextpath/someXYZResource: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
> continouously on most requests without being able to recover.
> Then we need to restart. Again if at some point the "Unable to acquire lock after 15 seconds" happens, we start getting errors about the DummyTransaction, which never stop.
> I believe "Unable to acquire lock after 15 seconds" should not lead to an unrecoverable state.
> Each node runs with: `./standalone.sh -c=standalone-full-ha.xml -u=239.255.200.215 -b=$localIp -bmanagement=$localIp -bprivate=$localIp -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=200` . `jboss.node.name` and `$localIp` only changes between nodes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9448) Unrecoverable "..DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state.." after " Unable to acquire lock after 15 seconds"
by kobogian hitis (JIRA)
[ https://issues.jboss.org/browse/WFLY-9448?page=com.atlassian.jira.plugin.... ]
kobogian hitis updated WFLY-9448:
---------------------------------
Environment: Centos (was: Centos / Each Server run with: `./standalone.sh -c=standalone-full-ha.xml -u=239.255.200.215 -b=$localIp -bmanagement=$localIp -bprivate=$localIp -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=200` . `jboss.node.name` only changes (node1/node2).)
> Unrecoverable "..DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state.." after " Unable to acquire lock after 15 seconds"
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9448
> URL: https://issues.jboss.org/browse/WFLY-9448
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Centos
> Reporter: kobogian hitis
> Assignee: Paul Ferraro
>
> On our system, after some time we get this:
> javax.ejb.EJBTransactionRolledbackException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4957576549555554536866505268565165695766655070536957516655656852] and requestor GlobalTransaction:<node1>:682146:local. Lock is held by GlobalTransaction:<node1>:681890:local
> And then we start getting the following:
> ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-2) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
> ...
> ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /contextpath/someXYZResource: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
> continouously on most requests without being able to recover.
> Then we need to restart. Again if at some point the "Unable to acquire lock after 15 seconds" happens, we start getting errors about the DummyTransaction, which never stop.
> I believe "Unable to acquire lock after 15 seconds" should not lead to an unrecoverable state.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9448) Unrecoverable "..DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state.." after " Unable to acquire lock after 15 seconds"
by kobogian hitis (JIRA)
kobogian hitis created WFLY-9448:
------------------------------------
Summary: Unrecoverable "..DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state.." after " Unable to acquire lock after 15 seconds"
Key: WFLY-9448
URL: https://issues.jboss.org/browse/WFLY-9448
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.1.0.Final
Environment: Centos / Each Server run with: `./standalone.sh -c=standalone-full-ha.xml -u=239.255.200.215 -b=$localIp -bmanagement=$localIp -bprivate=$localIp -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=200` . `jboss.node.name` only changes (node1/node2).
Reporter: kobogian hitis
Assignee: Paul Ferraro
On our system, after some time we get this:
javax.ejb.EJBTransactionRolledbackException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4957576549555554536866505268565165695766655070536957516655656852] and requestor GlobalTransaction:<node1>:682146:local. Lock is held by GlobalTransaction:<node1>:681890:local
And then we start getting the following:
ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-2) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
...
ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /contextpath/someXYZResource: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=437353}, status=3} is not in a valid state to be invoking cache operations on.
continouously on most requests without being able to recover.
Then we need to restart. Again if at some point the "Unable to acquire lock after 15 seconds" happens, we start getting errors about the DummyTransaction, which never stop.
I believe "Unable to acquire lock after 15 seconds" should not lead to an unrecoverable state.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (JGRP-2224) Multiple discovery protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2224?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2224:
--------------------------------
If {{async_discovery}} is false, then each of the discovery protocols will be invoked sequentially, else in parallel (using separate threads for each invocation).
> Multiple discovery protocols
> ----------------------------
>
> Key: JGRP-2224
> URL: https://issues.jboss.org/browse/JGRP-2224
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.8
>
>
> Allow for multiple discovery protocols. This would allow us to use a single configuration which includes discovery protocols for multiple cloud providers.
> The discovery protocols could be queried sequentially (return on result), or in parallel.
> Investigate whether we need a super discovery protocol which instantiates the individual protocols, or whether each protocol should be changed e.g. to forward events down the stack.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (JGRP-2224) Multiple discovery protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2224?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2224:
--------------------------------
This can be done by creating a {{MULTI_PING}} discovery protocol which extends {{Discovery}} and implements {{findMembers()}}. This method creates a {{Responses}} object and then calls the internal {{findMembers(Responses)}} method (in a separate thread) on each discovery protocol defined in {{MULTI_PING}}.
The config could look like this:
{code:xml}
<MULTI_PING async_discovery="true">
<discovery_protocols>
<TCPPING initial_hosts="..."/>
<DNS_PING.../>
<KUBE_PING .../>
</discovery-protocols>
</MULTI_PING>
{code}
> Multiple discovery protocols
> ----------------------------
>
> Key: JGRP-2224
> URL: https://issues.jboss.org/browse/JGRP-2224
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.8
>
>
> Allow for multiple discovery protocols. This would allow us to use a single configuration which includes discovery protocols for multiple cloud providers.
> The discovery protocols could be queried sequentially (return on result), or in parallel.
> Investigate whether we need a super discovery protocol which instantiates the individual protocols, or whether each protocol should be changed e.g. to forward events down the stack.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (JGRP-2225) Allow for sending of message batches in JChannel and protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2225?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2225:
--------------------------------
[~pruivo] Is it likely that you send multiple messages to the _same_ destination? ACKs?
> Allow for sending of message batches in JChannel and protocols
> --------------------------------------------------------------
>
> Key: JGRP-2225
> URL: https://issues.jboss.org/browse/JGRP-2225
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> Currently, we receive messages and message batches, but we're not able to _send_ message batches. Investigate adding a {{JChannel.send(MessageBatch)}} and {{Protocol.down(MessageBatch)}}.
> The use case is that if we want to send 10 messages to the same destination, we currently send 10 messages. Because they're on the same thread, they;re _not_ likely to end up in the same batch.
> Sending a message batch down the stack ensures that all messages end up in the same message batch (unless the max bundle size is exceeded).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (JGRP-2225) Allow for sending of message batches in JChannel and protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2225?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2225:
---------------------------
Description:
Currently, we receive messages and message batches, but we're not able to _send_ message batches. Investigate adding a {{JChannel.send(MessageBatch)}} and {{Protocol.down(MessageBatch)}}.
The use case is that if we want to send 10 messages to the same destination, we currently send 10 messages. Because they're on the same thread, they;re _not_ likely to end up in the same batch.
Sending a message batch down the stack ensures that all messages end up in the same message batch (unless the max bundle size is exceeded).
was:
Currently, we receive messages and message batches, but we're not able to _send_ message batches. Investigate adding a {{JChannel.send(MessageBatch)}} and {{Protocol.down(MessageBatch)}}.
The use case is that if we want to send 10 messages to the same destination, we currently send 10 messages. Because they're on the same thread, they;re _not_ likely to end up in the same batch.
Sending a message batch down the stack ensures that all messages end up in the same message batch.
> Allow for sending of message batches in JChannel and protocols
> --------------------------------------------------------------
>
> Key: JGRP-2225
> URL: https://issues.jboss.org/browse/JGRP-2225
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> Currently, we receive messages and message batches, but we're not able to _send_ message batches. Investigate adding a {{JChannel.send(MessageBatch)}} and {{Protocol.down(MessageBatch)}}.
> The use case is that if we want to send 10 messages to the same destination, we currently send 10 messages. Because they're on the same thread, they;re _not_ likely to end up in the same batch.
> Sending a message batch down the stack ensures that all messages end up in the same message batch (unless the max bundle size is exceeded).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (ELY-1407) Elytron, IBM SPNEGO misconfiguration handling difference
by Jan Kalina (JIRA)
Jan Kalina created ELY-1407:
-------------------------------
Summary: Elytron, IBM SPNEGO misconfiguration handling difference
Key: ELY-1407
URL: https://issues.jboss.org/browse/ELY-1407
Project: WildFly Elytron
Issue Type: Bug
Components: Credentials
Affects Versions: 1.2.0.Beta6
Reporter: Jan Kalina
Assignee: Jan Kalina
Priority: Critical
Fallback on unavailable KDC is on IBM JDK too slow, because server is waiting for the KDC around 30 seconds on every HTTP request.
Should be possible to configure IBM JDK to not contact KDC, or at least to cache failed state of GSSCredential obtaining for defined time period.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3361) Elytron, IBM SPNEGO misconfiguration handling difference
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3361?page=com.atlassian.jira.plugi... ]
Jan Kalina moved ELY-1407 to WFCORE-3361:
-----------------------------------------
Project: WildFly Core (was: WildFly Elytron)
Key: WFCORE-3361 (was: ELY-1407)
Component/s: Security
(was: Credentials)
Affects Version/s: 3.0.6.Final
(was: 1.2.0.Beta6)
> Elytron, IBM SPNEGO misconfiguration handling difference
> --------------------------------------------------------
>
> Key: WFCORE-3361
> URL: https://issues.jboss.org/browse/WFCORE-3361
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.6.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> Fallback on unavailable KDC is on IBM JDK too slow, because server is waiting for the KDC around 30 seconds on every HTTP request.
> Should be possible to configure IBM JDK to not contact KDC, or at least to cache failed state of GSSCredential obtaining for defined time period.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3360) Eliminate org.wildfly.extension.elytron.ProviderUtil
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-3360:
----------------------------------------
Summary: Eliminate org.wildfly.extension.elytron.ProviderUtil
Key: WFCORE-3360
URL: https://issues.jboss.org/browse/WFCORE-3360
Project: WildFly Core
Issue Type: Task
Components: Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 4.0.0.Alpha1
WildFly Elytron contains a public utility class org.wildfly.security.util.ProviderUtil for the same purpose, we should use the code within WildFly Elytron and not custom code within the subsystem.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months