[JBoss JIRA] (JGRP-2287) Thread safety issues and race conditions in VERIFY_SUSPECT
by Paul Ferraro (JIRA)
Paul Ferraro created JGRP-2287:
----------------------------------
Summary: Thread safety issues and race conditions in VERIFY_SUSPECT
Key: JGRP-2287
URL: https://issues.jboss.org/browse/JGRP-2287
Project: JGroups
Issue Type: Bug
Affects Versions: 4.0.13
Reporter: Paul Ferraro
Assignee: Bela Ban
Priority: Critical
While addressing JGRP-2286, I noticed a number of thread safety issues and race conditions in VERIFY_SUSPECT, e.g.
1. "suspects" DelayQueue is accessed concurrently within synchronized block by most of the code, however, the run() method calls isEmpty(), size(), and most notably, drainTo(...) without sufficient exclusivity. drainTo is particularly problematic in the case of concurrent modifications.
2. "timer" Thread is non-volatile, but its reference is set by multiple threads.
3. The startTimer() method only creates a new thread if Thread.isAlive() returns false. However, if the thread is just completing (i.e. exiting its loop), this method can return true, and the verification of suspected members can be delayed until the next suspect event.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10736) Server in cluster hangs during start after previous kill
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10736?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10736:
-------------------------------------
Again, the source of the problem is the following:
06:03:12,437 INFO [org.infinispan.CLUSTER] (thread-8,ejb,node-1) ISPN000094: Received new cluster view for channel ejb: [node-1|2] (3) [node-1, node-2, node-2]
06:03:12,437 INFO [org.infinispan.CLUSTER] (thread-8,ejb,node-1) ISPN100000: Node node-2 joined the cluster
06:03:12,441 INFO [org.infinispan.CLUSTER] (thread-8,ejb,node-1) ISPN000094: Received new cluster view for channel ejb: [node-1|2] (3) [node-1, node-2, node-2]
06:03:12,441 INFO [org.infinispan.CLUSTER] (thread-8,ejb,node-1) ISPN100000: Node node-2 joined the cluster
06:03:12,442 INFO [org.infinispan.CLUSTER] (thread-8,ejb,node-1) ISPN000094: Received new cluster view for channel ejb: [node-1|2] (3) [node-1, node-2, node-2]
06:03:12,442 INFO [org.infinispan.CLUSTER] (thread-8,ejb,node-1) ISPN100000: Node node-2 joined the cluster
06:03:12,442 INFO [org.infinispan.CLUSTER] (thread-8,ejb,node-1) ISPN000094: Received new cluster view for channel ejb: [node-1|2] (3) [node-1, node-2, node-2]
Here's what I believe is happening:
1. FD_SOCK detects that node-2 failed very quickly due to its socket closing.
2. FD_SOCK sends a SUSPECT event up the stack
3. node-2 restarts, using the same physical address
4. SUSPECT event is handled by VERIFY_SUSPECT which sends a message to the suspected member.
5. The restarted server receives the message (intended for the old member) and replies with an I_AM_NOT_DEAD response, thus the killed member never leaves the view.
Ideally, VERIFY_SUSPECT shouldn't be prone to false positives like this. I've opened https://issues.jboss.org/browse/JGRP-2286 to solve this problem in JGroups directly. I have a fix prepared, and am in the process of verifying it locally.
In the meantime, I can think of a couple workarounds:
1. Remove VERIFY_SUSPECT from the stack. This will certainly solve the problem, but will have some negative consequences. In particular, suspected members will immediately be removed from the view. This means an increased likelihood of false positives from failure detection. If this proves very problematic, we can mitigate this somewhat by increasing the timeouts used by FD_ALL.
2. Decrease the timeout used by VERIFY_SUSPECT. This should have the effect of shrinking the window where a reincarnated member joins before the previously killed member is removed by VERIFY_SUSPECT. Currently, this is set to 2 seconds. However, given that WF starts very quickly, we can try reducing this. However, this also reduces the amount of time a suspected member has to respond - and can still result in an overloaded member being removed from the view too quickly. That said, this option is still preferable to #1. I'll try to verify locally whether this is sufficient to reduce the likelihood of the above issue to an acceptable level.
[~mnovak] Can you try the following modification to the JGroups subsystem to see if this adequately works around the problem?
{noformat}
<protocol type="VERIFY_SUSPECT">
<property name="timeout">1000</property>
</protocol>
{noformat}
{quote}afaik in OpenShift node name is taken from name of the pod. It can be for example "eap-app-2-pzhlk". If EAP/WF crashes inside the pod then it's restarted immediately in the same pod and has the same node name "eap-app-2-pzhlk".{quote}
The fact that the restarted pod has the same logical name is inconsequential - JGroups member identity is based on UUID, not logical name. AIUI, the Kubernetes dynamically assigns addresses to pods when they start, so it would most likely have a distinct physical address. On bare metal, the same physical address is used, hence the problem above.
> Server in cluster hangs during start after previous kill
> --------------------------------------------------------
>
> Key: WFLY-10736
> URL: https://issues.jboss.org/browse/WFLY-10736
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Miroslav Novak
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: blocker-WF14
> Fix For: 15.0.0.Alpha1
>
> Attachments: Lodh2TestCase.testRemoteJcaInboundOnly-traces.zip, Lodh2TestCase.testRemoteJcaInboundOnly.zip, Lodh2TestCase.testRemoteJcaInboundOnly2.zip, clusterKilTest.zip, logs-traces.zip, logs-traces2.zip, logs-traces3.zip, logs-traces4.zip, logs-with-workaround.zip, node-1-thread-dump-before-kill-shutdown-sequence.txt, server-with-mdb.log, standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> There is regression in JGroups or Infinispan in one of our tests for fault tolerance of JMS bridges. However work on JMS bridge appears to be unrelated. Issue was hit in WF weekly run.
> Test Scenario:
> * There are two servers. InQueue is deployed on Node 1,
> * OutQueue is deployed on Node 2. Both servers are started.
> * Large byte messages are sent to InQueue deployed on Node 1. Bridge between servers/queues transfers messages from node 1 to node 2.
> * Node 1 is killed and started again.
> * All messages are received from OutQueue deployed on Node 2.
> Result:
> Node 1 does not start after kill and hangs. There is following exception logged in node 2:
> {code}
> :26:17,894 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100000: Node node-1 joined the cluster
> 09:26:18,520 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,523 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,868 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) ISPN000310: Starting cluster-wide rebalance for cache default, topology CacheTopology{id=17, phase=READ_OLD_WRITE_ALL, rebalanceId=6, currentCH=ReplicatedConsistentHash{ns = 256, owners = (2)[node-2: 122, node-1: 134]}, pendingCH=ReplicatedConsistentHash{ns = 256, owners = (3)[node-2: 84, node-1: 90, node-1: 82]}, unionCH=null, actualMembers=[node-2, node-1, node-1], persistentUUIDs=[12443bfb-e88a-46f3-919e-9213bf38ce19, 2873237f-d881-463f-8a5a-940bf1d764e5, a05ea8af-a83b-42a9-b937-dc2da1cae6d1]}
> 09:26:18,869 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-2]ISPN100002: Started rebalance with topology id 17
> 09:26:18,870 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t5) [Context=default][Scope=node-2]ISPN100003: Node node-2 finished rebalance phase with topology id 17
> 09:26:18,981 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-1]ISPN100003: Node node-1 finished rebalance phase with topology id 17
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p15-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p16-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> {code}
> There is default JGroups udp stack configured which is used by Infinispan. Both of the servers (jgroups udp) are bound to 127.0.0.1. Node 2 has port offset 1000.
> Attaching thread dump from node 1 when it hangs during start.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (JBSER-96) SUN JDK 1.5 on client side and IBM JDK 1.5 on server side doesn't work together
by Clebert Suconic (JIRA)
[ https://issues.jboss.org/browse/JBSER-96?page=com.atlassian.jira.plugin.s... ]
Clebert Suconic closed JBSER-96.
--------------------------------
Resolution: Out of Date
> SUN JDK 1.5 on client side and IBM JDK 1.5 on server side doesn't work together
> -------------------------------------------------------------------------------
>
> Key: JBSER-96
> URL: https://issues.jboss.org/browse/JBSER-96
> Project: JBoss Serialization
> Issue Type: Bug
> Affects Versions: 1.0.3 GA
> Environment: 1. Client: Windows, SUN JDK 1.5.0_12, JBoss Client
> 2. Server: AS/400 with i5, IBM JKD 1.5 (J9), JBoss Server
> Reporter: Matthias Raab
> Assignee: Clebert Suconic
> Priority: Critical
>
> Failure during serialization on client side: "Current classpath has lesser fields on java.math.BigDecimal than its original version"
> Stacktrace
> java.io.IOException
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
> at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
> at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
> at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:163)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
> at de.carus.cjfc.tfc.dto.TMDTOExchange.readExternal(TMDTOExchange.java:3092)
> at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
> at org.jboss.invocation.MarshalledValue.get(MarshalledValue.java:78)
> at org.jboss.invocation.http.interfaces.Util.invoke(Util.java:169)
> at org.jboss.invocation.http.interfaces.HttpInvokerProxy.invoke(HttpInvokerProxy.java:103)
> at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227)
> at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:167)
> at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
> at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
> at org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.java:106)
> at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
> at $Proxy5.read(Unknown Source)
> at de.carus.cjfc.tfc.bu.ejb.TMUseCaseMgrEJBClient.read(TMUseCaseMgrEJBClient.java:246)
> at de.carus.cjfc.tfc.bu.usecase.TMUseCaseMgr.executeSearch(TMUseCaseMgr.java:1702)
> at de.carus.cjfc.tfc.bu.usecase.TMUseCaseMgr.search(TMUseCaseMgr.java:1686)
> at de.carus.cjfc.tfc.bu.model.TMModelContext.search(TMModelContext.java:212)
> at de.carus.cjfc.tfc.bu.usecase.TMUSelector.search(TMUSelector.java:427)
> at de.carus.cjfc.tfc.bu.usecase.TMUSelector.search(TMUSelector.java:400)
> at de.alea.amc.core.bu.usecase.center.UCCompanySelector.find(UCCompanySelector.java:177)
> at de.alea.amc.core.bu.model.user.MAMCUser.getAllowedSystemClients(MAMCUser.java:529)
> at de.alea.amc.core.pr.swt.user.LoginDialog.okPressed(LoginDialog.java:207)
> at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:464)
> at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:616)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:227)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:820)
> at org.eclipse.jface.window.Window.open(Window.java:796)
> at de.alea.amc.core.pr.swt.user.LoginAction.run(LoginAction.java:30)
> at de.alea.amc.pr.AmcRunnable$ApplicationStarter.runStartActions(AmcRunnable.java:133)
> at de.alea.amc.pr.AmcRunnable$ApplicationStarter.run(AmcRunnable.java:52)
> at de.alea.amc.pr.swt.rcpframe.AMCSafeRunnableRunner.run(AMCSafeRunnableRunner.java:48)
> at de.alea.amc.pr.AmcRunnable.run(AmcRunnable.java:165)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethod(EclipseAppContainer.java:533)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:155)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:504)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1144)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
> ... 63 more
> Caused by: java.io.IOException
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
> at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
> at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
> at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
> at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
> at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
> at java.util.ArrayList.readObject(ArrayList.java:591)
> ... 67 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
> ... 81 more
> Caused by: java.io.IOException: Current classpath has lesser fields on java.math.BigDecimal than its original version
> at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:98)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
> at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
> at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
> at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
> at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
> at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
> at java.util.ArrayList.readObject(ArrayList.java:591)
> ... 85 more
> java.io.IOException
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
> at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
> at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
> at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:163)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
> at de.carus.cjfc.tfc.dto.TMDTOExchange.readExternal(TMDTOExchange.java:3092)
> at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
> at org.jboss.invocation.MarshalledValue.get(MarshalledValue.java:78)
> at org.jboss.invocation.http.interfaces.Util.invoke(Util.java:169)
> at org.jboss.invocation.http.interfaces.HttpInvokerProxy.invoke(HttpInvokerProxy.java:103)
> at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:227)
> at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:167)
> at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
> at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
> at org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterceptor.java:106)
> at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86)
> at $Proxy5.read(Unknown Source)
> at de.carus.cjfc.tfc.bu.ejb.TMUseCaseMgrEJBClient.read(TMUseCaseMgrEJBClient.java:246)
> at de.carus.cjfc.tfc.bu.usecase.TMUseCaseMgr.executeSearch(TMUseCaseMgr.java:1702)
> at de.carus.cjfc.tfc.bu.usecase.TMUseCaseMgr.search(TMUseCaseMgr.java:1686)
> at de.carus.cjfc.tfc.bu.model.TMModelContext.search(TMModelContext.java:212)
> at de.carus.cjfc.tfc.bu.usecase.TMUSelector.search(TMUSelector.java:427)
> at de.carus.cjfc.tfc.bu.usecase.TMUSelector.search(TMUSelector.java:400)
> at de.alea.amc.core.bu.usecase.center.UCCompanySelector.find(UCCompanySelector.java:177)
> at de.alea.amc.core.bu.model.user.MAMCUser.getAllowedSystemClients(MAMCUser.java:529)
> at de.alea.amc.core.pr.swt.user.LoginDialog.okPressed(LoginDialog.java:207)
> at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:464)
> at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:616)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:227)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:820)
> at org.eclipse.jface.window.Window.open(Window.java:796)
> at de.alea.amc.core.pr.swt.user.LoginAction.run(LoginAction.java:30)
> at de.alea.amc.pr.AmcRunnable$ApplicationStarter.runStartActions(AmcRunnable.java:133)
> at de.alea.amc.pr.AmcRunnable$ApplicationStarter.run(AmcRunnable.java:52)
> at de.alea.amc.pr.swt.rcpframe.AMCSafeRunnableRunner.run(AMCSafeRunnableRunner.java:48)
> at de.alea.amc.pr.AmcRunnable.run(AmcRunnable.java:165)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethod(EclipseAppContainer.java:533)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:155)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:504)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1144)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
> ... 63 more
> Caused by: java.io.IOException
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:107)
> at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:269)
> at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
> at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
> at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
> at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
> at java.util.ArrayList.readObject(ArrayList.java:591)
> ... 67 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithMethod(RegularObjectPersister.java:103)
> ... 81 more
> Caused by: java.io.IOException: Current classpath has lesser fields on java.math.BigDecimal than its original version
> at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:98)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
> at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
> at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
> at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
> at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
> at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
> at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
> at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
> at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride(ObjectInputStreamProxy.java:68)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
> at java.util.ArrayList.readObject(ArrayList.java:591)
> ... 85 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (DROOLS-2989) Avoid refire of rules with synthetic Fact Handles
by Luca Molteni (JIRA)
Luca Molteni created DROOLS-2989:
------------------------------------
Summary: Avoid refire of rules with synthetic Fact Handles
Key: DROOLS-2989
URL: https://issues.jboss.org/browse/DROOLS-2989
Project: Drools
Issue Type: Enhancement
Components: core engine
Reporter: Luca Molteni
Assignee: Luca Molteni
Currently the FromNode and the AccumulateNode create "synthetic" fact handles, that means they're not serialized and they're recreated in memory each time we need the access.
There's already a way to avoid the refiring of the rules but involves serializing and deserializing these synthetic Fact Handles without the objects.
We now want a better way to do it by serializing the objects without their FactHandles and at the same time keep the same behaviour as before (same number of rules should fire)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10661) IllegalMonitorStateException if session invalidated after redirect
by Jan Stourac (JIRA)
[ https://issues.jboss.org/browse/WFLY-10661?page=com.atlassian.jira.plugin... ]
Jan Stourac commented on WFLY-10661:
------------------------------------
I've created a followup issue WFLY-11008.
> IllegalMonitorStateException if session invalidated after redirect
> ------------------------------------------------------------------
>
> Key: WFLY-10661
> URL: https://issues.jboss.org/browse/WFLY-10661
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Environment: EAP 7.1.3
> Reporter: Aaron Ogburn
> Assignee: Paul Ferraro
> Priority: Minor
> Fix For: 14.0.0.Beta2
>
> Attachments: stacktrace.txt, undertow1374.war
>
>
> response.sendRedirect unlocks the session. So attempting session.invalidate after any sendRedirect throws an IllegalMonitorStateException when it attempts to unlock it again:
> {code}
> 16:35:11,267 INFO [stdout] (default task-1) --------------------------->StampedLock.unlock java.util.concurrent.locks.StampedLock@2a03fe4a[Unlocked] 257
> 16:35:11,267 INFO [stdout] (default task-1) java.util.concurrent.locks.StampedLock.unlock(StampedLock.java:603)
> 16:35:11,267 INFO [stdout] (default task-1) org.wildfly.clustering.web.undertow.session.DistributableSessionManager.lambda$getSessionCloseTask$1(DistributableSessionManager.java:103)
> 16:35:11,267 INFO [stdout] (default task-1) org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:96)
> 16:35:11,267 INFO [stdout] (default task-1) io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:860)
> 16:35:11,267 INFO [stdout] (default task-1) io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:572)
> 16:35:11,267 INFO [stdout] (default task-1) io.undertow.servlet.spec.HttpServletResponseImpl.sendRedirect(HttpServletResponseImpl.java:203)
> 16:35:11,267 INFO [stdout] (default task-1) org.apache.jsp.hi_jsp._jspService(hi_jsp.java:136)
> ...
> Caused by: java.lang.IllegalMonitorStateException
> at java.util.concurrent.locks.StampedLock.unlock(StampedLock.java:609)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.lambda$getSessionCloseTask$1(DistributableSessionManager.java:103)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:218)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at org.apache.jsp.hi_jsp._jspService(hi_jsp.java:137)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-11008) Infinispan IllegalStateException when session invalidated after redirect
by Jan Stourac (JIRA)
Jan Stourac created WFLY-11008:
----------------------------------
Summary: Infinispan IllegalStateException when session invalidated after redirect
Key: WFLY-11008
URL: https://issues.jboss.org/browse/WFLY-11008
Project: WildFly
Issue Type: Bug
Components: Clustering, Web (Undertow)
Affects Versions: 14.0.0.Final
Reporter: Jan Stourac
Assignee: Paul Ferraro
Attachments: undertow1374.war
When accessing jsp file which contains redirect followed by session invalidation:
{code}
<%
response.sendRedirect("/foobar");
request.getSession().invalidate();
%>
{code}
there is an IllegalStateException thrown in server.log:
{code}
17:59:19,878 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /undertow1374/index.jsp: java.lang.IllegalStateException: Transaction TransactionImpl{xid=Xid{formatId=1, globalTransactionId=ABAB36940C34C83ED47BB18DC57542C10000000000000006,branchQualifier=ABAB36940C34C83ED47BB18DC57542C10000000000000006}, status=COMMITTED} is not in a valid state to be invoking cache operations on.
at org.infinispan.interceptors.impl.TxInterceptor.enlist(TxInterceptor.java:424)
at org.infinispan.interceptors.impl.TxInterceptor.enlistIfNeeded(TxInterceptor.java:331)
at org.infinispan.interceptors.impl.TxInterceptor.visitLockControlCommand(TxInterceptor.java:216)
at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:123)
at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90)
at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:248)
at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:1018)
at org.infinispan.cache.impl.DecoratedCache.lock(DecoratedCache.java:188)
at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:285)
at org.infinispan.cache.impl.EncoderCache.lock(EncoderCache.java:318)
at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:285)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:120)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:110)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:39)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:87)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:37)
at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:61)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:388)
at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:208)
at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:120)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
Suppressed: org.infinispan.util.logging.TraceException
at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.get(SimpleAsyncInvocationStage.java:41)
at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:250)
... 63 more
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors
by Jan Lieskovsky (JIRA)
[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ]
Jan Lieskovsky commented on WFLY-11007:
---------------------------------------
Thanks, Sebastian!
Adding Darran to the Cc-list yet. Per this [ticket|https://bugs.erlang.org/browse/ERL-83] it happens when the server has a very long list of trusted CAs, the TLS record might overflow the maximum allowed 16384 (2^14) length, required by [RFC 5246 section 6.2.1|https://tools.ietf.org/html/rfc5246#section-6.2.1]. What's not clear to me yet, if the current behaviour is the OpenShift's service certificate secrets service's fault, or JBoss EAP server's fault.
Since the 2nd attempt (with your own certificate) worked for you. Could you retry to rerun it with that own certificate, for which the scenario worked, but this time to put much more trusted CA certificates into the truststore? Some example longer CA file is [here|http://curl.haxx.se/ca/cacert.pem].
Alternatively, you can retry the scenario with autogenerated OpenShift certificates, but comment out that code part inserting the whole Java system PKI CA certs into the truststore (insert just that one certificate you need, the client cert verification to succeed into the truststore).
If these modified scenarios work, some component (like said, not completely sure yet, which of them it is. But since the truststore is created on EAP server side, it might be issue on EAP part) is producing longer TLS records than actually allowed by the RFC, and it should be addressed.
If you manage to reproduce the issue, with the own certificate (having a lot CA cert entries in the truststore), or not reproduce the issue with the OpenShift certificate, not having that much CA cert entries in the truststore, like in the default case, we might be wiser, what's causing the issue.
> Using OpenShift generated certificates and client auth cause TLS errors
> -----------------------------------------------------------------------
>
> Key: WFLY-11007
> URL: https://issues.jboss.org/browse/WFLY-11007
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 13.0.0.Final
> Reporter: Sebastian Łaskawiec
> Assignee: Stuart Douglas
>
> h2. Summary
> It seems that when using OpenShift generated certificates and client auth (with {{want-client-auth="true"}}) the TLS handshake fails with {{RECV TLSv1.2 ALERT: fatal, record_overflow}} message.
> h2. Explanation
> I'm using {{oc cluster up}} and deploying Keycloak (WF 13 based) on OpenShift local cluster using the (1) template. The service in the the template uses OpenShift generated certificates ({{"service.alpha.openshift.io/serving-cert-secret-name": "keycloak-x509-https-secret"}}). Both files are mounted in the Keycloak pod and translated into keystore and truststore (see the configuration after the transformation (2)). Once the pod is up and running, I'm issuing a {{curl}} command as shown in (3). {{curl}} fails saying that {{* error:1408F092:SSL routines:ssl3_get_record:data length too long}}. The server logs with TLS Handshake debugging turned on might be found here (4). As shown in the link, the server has written {{16384}} bytes.
> I also did a test with manually created certificates (5). The result might be found here (6). As shown in the link, we've written {{16050}} bytes instead of {{16384}} and the handshake was successful.
> h2. Possible solution
> Perhaps we should cut the list CAs transmitted by the server when asking for client auth when it exceeds certain number of bytes. It would be helpful to write a warn message too.
> Links:
> - (1) Keycloak OCP Template https://gist.github.com/slaskawi/57ed810a7109a02a9d884b61ce2e7f13
> - (2) Transformed configuration https://gist.github.com/slaskawi/92aead6c519b867621129b640b4a3c88
> - (3) curl command https://gist.github.com/slaskawi/3bc32b8e96c2499cb7b48c3c5cb28616
> - (4) https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#file-lo...
> - (5) Keycloak and OpenShift integration demo https://github.com/keycloak/openshift-integration/blob/master/install-key...
> - (6) https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-lo...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months