[JBoss JIRA] (DROOLS-2877) Update the top level data type, considering changes in an external/nested sub data type
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2877?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2877:
--------------------------------
Attachment: Screenshot from 2018-08-31 14-59-52.png
> Update the top level data type, considering changes in an external/nested sub data type
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-2877
> URL: https://issues.jboss.org/browse/DROOLS-2877
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.11.0.Final
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Labels: drools-tools
> Attachments: Screenshot from 2018-08-31 14-59-52.png, itemDef-dependency.dmn
>
>
> User is able to achieve inconsistent state in *Manage custom data type dialog* See the attached picture. There is changed top level itemDefinition *Address* to *Adress111* however the itemDefinition *Person* stil shows it address field as *Adress*, it should be *Adress111* too.
> h2. Steps to reproduce
> - Open the attached model
> - Invoke manage custom data type dialog
> - Change the Address item definition as shown in picture
> -- Person item definition should update its fields
> - Reopen the manage dialog
> - Person will still have field of *Adress* type
> - Click edito to this field
> -- Nothing selected will be shown
> -- It should select *Adress111*
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (DROOLS-2877) Update the top level data type, considering changes in an external/nested sub data type
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2877?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2877:
--------------------------------
Description:
h2. Steps to reproduce
- Open the attached model
- Invoke manage custom data type dialog
- Change the Address item definition as shown in picture
-- Person item definition should update its fields
- Reopen the manage dialog
- Person will still have field of *Adress* type
- Click edito to this field
-- Nothing selected will be shown
-- It should select *Adress111*
> Update the top level data type, considering changes in an external/nested sub data type
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-2877
> URL: https://issues.jboss.org/browse/DROOLS-2877
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.11.0.Final
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Labels: drools-tools
>
> h2. Steps to reproduce
> - Open the attached model
> - Invoke manage custom data type dialog
> - Change the Address item definition as shown in picture
> -- Person item definition should update its fields
> - Reopen the manage dialog
> - Person will still have field of *Adress* type
> - Click edito to this field
> -- Nothing selected will be shown
> -- It should select *Adress111*
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (DROOLS-2877) Update the top level data type, considering changes in an external/nested sub data type
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2877?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2877:
--------------------------------
Description:
User is able to achieve inconsistent state in *Manage custom data type dialog* See the attached picture. There is changed top level itemDefinition *Address* to *Adress111* however the itemDefinition *Person* stil shows it address field as *Adress*, it should be *Adress111* too.
h2. Steps to reproduce
- Open the attached model
- Invoke manage custom data type dialog
- Change the Address item definition as shown in picture
-- Person item definition should update its fields
- Reopen the manage dialog
- Person will still have field of *Adress* type
- Click edito to this field
-- Nothing selected will be shown
-- It should select *Adress111*
was:
h2. Steps to reproduce
- Open the attached model
- Invoke manage custom data type dialog
- Change the Address item definition as shown in picture
-- Person item definition should update its fields
- Reopen the manage dialog
- Person will still have field of *Adress* type
- Click edito to this field
-- Nothing selected will be shown
-- It should select *Adress111*
> Update the top level data type, considering changes in an external/nested sub data type
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-2877
> URL: https://issues.jboss.org/browse/DROOLS-2877
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.11.0.Final
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Labels: drools-tools
>
> User is able to achieve inconsistent state in *Manage custom data type dialog* See the attached picture. There is changed top level itemDefinition *Address* to *Adress111* however the itemDefinition *Person* stil shows it address field as *Adress*, it should be *Adress111* too.
> h2. Steps to reproduce
> - Open the attached model
> - Invoke manage custom data type dialog
> - Change the Address item definition as shown in picture
> -- Person item definition should update its fields
> - Reopen the manage dialog
> - Person will still have field of *Adress* type
> - Click edito to this field
> -- Nothing selected will be shown
> -- It should select *Adress111*
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10630) HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10630?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10630:
-------------------------------------
This should just be a matter of using a distinct SessionListeners instance per SessionManagerFactory instead of per SessionManager.
> HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-10630
> URL: https://issues.jboss.org/browse/WFLY-10630
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final, 13.0.0.Final
> Environment: Windows 10, Java 1.8.0_131
> Reproducible with both WildFly-10.0.0.Final and Wildfly-13.0.0.Final
> Reporter: Bernhard Kabelka
> Assignee: Paul Ferraro
> Attachments: LoginForm.png, roles.properties, sessionlistener-test.ear, standalone.xml, users.properties
>
>
> For sessions shared across different WARs in a single EAR, the notification of HttpSessionListener works differently in WildFly 10.0.0.Final (and Wildfly 13.0.0.Final) than it it used to work in WildFly 8.2.0.Final:
> I have an EAR containing two WARs with enabled session sharing across the WARs. Basically, one WAR contains the web UI, and the other WAR contains the REST interfaces for AJAX calls made by the UI. The user authenticates against the UI-WAR. On logout, a REST method in the AJAX-WAR is triggered which calls HttpSession.invalidate() on the user session.
> In WildFly 8.2.0.Final, a HttpSessionListener in the UI-WAR gets notified immediately about session creation and destruction.
> In WildFly 13.0.0.Final, however, a HttpSessionListener in either WAR only gets one of the two notifications:
> * In the UI-WAR, I get a notification about the created session immediately when the login form is loaded. However, I do not receive any notification about the session destruction (unless it times out).
> * In the AJAX-WAR, I do not get any notification about the session creation at all, but I immediately receive a notification about the session destruction.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10630) HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10630?page=com.atlassian.jira.plugin... ]
Paul Ferraro reassigned WFLY-10630:
-----------------------------------
Assignee: Paul Ferraro (was: Bartosz Baranowski)
> HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-10630
> URL: https://issues.jboss.org/browse/WFLY-10630
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final, 13.0.0.Final
> Environment: Windows 10, Java 1.8.0_131
> Reproducible with both WildFly-10.0.0.Final and Wildfly-13.0.0.Final
> Reporter: Bernhard Kabelka
> Assignee: Paul Ferraro
> Attachments: LoginForm.png, roles.properties, sessionlistener-test.ear, standalone.xml, users.properties
>
>
> For sessions shared across different WARs in a single EAR, the notification of HttpSessionListener works differently in WildFly 10.0.0.Final (and Wildfly 13.0.0.Final) than it it used to work in WildFly 8.2.0.Final:
> I have an EAR containing two WARs with enabled session sharing across the WARs. Basically, one WAR contains the web UI, and the other WAR contains the REST interfaces for AJAX calls made by the UI. The user authenticates against the UI-WAR. On logout, a REST method in the AJAX-WAR is triggered which calls HttpSession.invalidate() on the user session.
> In WildFly 8.2.0.Final, a HttpSessionListener in the UI-WAR gets notified immediately about session creation and destruction.
> In WildFly 13.0.0.Final, however, a HttpSessionListener in either WAR only gets one of the two notifications:
> * In the UI-WAR, I get a notification about the created session immediately when the login form is loaded. However, I do not receive any notification about the session destruction (unless it times out).
> * In the AJAX-WAR, I do not get any notification about the session creation at all, but I immediately receive a notification about the session destruction.
--
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:
-------------------------------------
[~mnovak] I didn't mean to imply that there is an issue with the test. I was merely attempting to identity configuration changes that you *could* make now, in order to avoid the issue in the event that this bug is blocking testing.
In regards to the underlying issue, an upstream fix was merged and will be integrated as soon as the release is available.
> 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-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] (WFCORE-4018) Remove alias and read-aliases in a batch causes blocking behavior
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4018?page=com.atlassian.jira.plugi... ]
Michal Petrov commented on WFCORE-4018:
---------------------------------------
It's a synchronization issue, same thing happens if you put just the {{read-aliases}} in the batch twice, the first operation acquires a write-lock and then the second operation hangs trying to acquire a write-lock for itself.
> Remove alias and read-aliases in a batch causes blocking behavior
> -----------------------------------------------------------------
>
> Key: WFCORE-4018
> URL: https://issues.jboss.org/browse/WFCORE-4018
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
>
> Calling :remove-alias and :read-aliases on key-store resource in a composite operation makes the resource blocked.
> Generate two self signed certificates on a key-store resource and store it.
> {code}
> /host=master/server=server-three/subsystem=elytron/key-store=keysto1:generate-key-pair(alias=foobar,distinguished-name="cn=claudio,c=BR")
> /host=master/server=server-three/subsystem=elytron/key-store=keysto1:generate-key-pair(alias=foobar2,distinguished-name="cn=claudio2,c=BR")
> /host=master/server=server-three/subsystem=elytron/key-store=keysto1:store()
> /host=master/server=server-three/subsystem=elytron/key-store=keysto1:read-aliases
> {
> "outcome" => "success",
> "result" => [
> "foobar2",
> "foobar"
> ]
> }
> {code}
> {code}
> batch
> /host=master/server=server-three/subsystem=elytron/key-store=keysto1:remove-alias(alias=foobar)
> /host=master/server=server-three/subsystem=elytron/key-store=keysto1:read-aliases
> run-batch
> {code}
> The above just blocks the prompt.
> Then the blocking operation is show as:
> {code}
> /host=master/core-service=management/service=management-operations:read-resource(include-runtime,recursive)
> {
> "outcome" => "success",
> "result" => {"active-operation" => {
> "352328021" => {
> "access-mechanism" => "NATIVE",
> "address" => [
> ("host" => "master"),
> ("core-service" => "management"),
> ("service" => "management-operations")
> ],
> "caller-thread" => "management-handler-thread - 1",
> "cancelled" => false,
> "domain-rollout" => false,
> "domain-uuid" => undefined,
> "exclusive-running-time" => -1L,
> "execution-status" => "executing",
> "operation" => "read-resource",
> "running-time" => 10032404L
> },
> "-1467399640" => {
> "access-mechanism" => "NATIVE",
> "address" => [],
> "caller-thread" => "management-handler-thread - 2",
> "cancelled" => false,
> "domain-rollout" => false,
> "domain-uuid" => undefined,
> "exclusive-running-time" => -1L,
> "execution-status" => "executing",
> "operation" => "composite",
> "running-time" => 260150849919L
> }
> }}
> }
> {code}
> After timeout there is the following message on CLI prompt
> {code}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error):
> WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
> Step: step-2
> Operation: /host=master/server=server-three/subsystem=elytron/key-store=keysto1:read-aliases
> Failure: WFLYCTL0409: Execution of operation 'read-aliases' on remote process at address '[
> ("host" => "master"),
> ("server" => "server-three")
> ]' timed out after 305000 ms while awaiting initial response; remote process has been notified to terminate operation
> {code}
> To fix the problem in HAL I will run it as individual commands.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (DROOLS-2949) [DMN Designer] Change of data type is not propagated to manage dialog
by Guilherme Carreiro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2949?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro commented on DROOLS-2949:
--------------------------------------------
[~jomarko] Oops, /s/DROOLS-2762/DROOLS-2877 ;-)
> [DMN Designer] Change of data type is not propagated to manage dialog
> ---------------------------------------------------------------------
>
> Key: DROOLS-2949
> URL: https://issues.jboss.org/browse/DROOLS-2949
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.11.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Labels: drools-tools
> Attachments: Screenshot from 2018-08-31 14-59-52.png, itemDef-dependency.dmn
>
>
> User is able to achieve inconsistent state in *Manage custom data type dialog* See the attached picture. There is changed top level itemDefinition *Address* to *Adress111* however the itemDefinition *Person* stil shows it address field as *Adress*, it should be *Adress111* too.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10812) JDK11 Some security tests fail on closed channel exception
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-10812?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFLY-10812:
-----------------------------------
[~honza889] I presume that this is part of the work that needs doing to get EAP 7.2.0 passing on Java 11? In which case we need to clone this issue to JBEAP with a TR of 7.2.0.CD14 and create a PR for https://github.com/jbossas/jboss-eap7/tree/CD14
> JDK11 Some security tests fail on closed channel exception
> ----------------------------------------------------------
>
> Key: WFLY-10812
> URL: https://issues.jboss.org/browse/WFLY-10812
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Richard Opalka
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 15.0.0.Alpha1
>
>
> With latest JDK11 (build 11-ea+25) the following tests fail due to closed channel exception: modified:
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/LdapExtLikeAdvancedLdapLMTestCase.java
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/LdapExtLoginModuleTestCase.java
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/security/loginmodules/LdapLoginModuleTestCase.java
> * testsuite/integration/elytron/src/test/java/org/wildfly/test/integration/elytron/ssl/UndertowTwoWaySslNeedClientAuthTestCase.java
> * testsuite/integration/iiop/src/test/java/org/jboss/as/test/iiopssl/basic/IIOPSslInvocationTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/security/OutboundLdapConnectionClientCertTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/security/OutboundLdapConnectionTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/CertificateRolesLoginModuleTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/DatabaseCertLoginModuleTestCase.java
> * testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/HTTPSWebConnectorTestCase.java
> * testsuite/integration/ws/src/test/java/org/jboss/as/test/integration/ws/wsse/trust/WSTrustTestCase.java
> Is there a known SSL issue in JDK11? Could somebody from our security team investigate this issue?
> When these tests will start passing WF test suite will be passing 100% of tests on JDK11.
> Potential investigator from our security team may want to include this PR:
> https://github.com/wildfly/wildfly/pull/11499
> to fix known JDK11 issues.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months