[JBoss JIRA] (SWSQE-288) Kiali - Istio Checker to 0.8.0
by Filip Brychta (JIRA)
[ https://issues.jboss.org/browse/SWSQE-288?page=com.atlassian.jira.plugin.... ]
Filip Brychta updated SWSQE-288:
--------------------------------
Priority: Blocker (was: Major)
> Kiali - Istio Checker to 0.8.0
> ------------------------------
>
> Key: SWSQE-288
> URL: https://issues.jboss.org/browse/SWSQE-288
> Project: Kiali QE
> Issue Type: Sub-task
> Reporter: Hayk Hovsepyan
> Assignee: Sunil kondkar
> Priority: Blocker
>
> We have a job http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-Istio-Checker
> which checks Istio installation on OC. It works with 0.7.1 Istio.
> Main jenkins pipeline is switched to Istio 0.8.0 already.
> TODO
> Update this job and the script to support Istio 0.8.0 version pods which are:
> grafana-cd99bf478-2k9zj 1/1 Running 0 19m
> istio-citadel-ff5696f6f-6m8rv 1/1 Running 0 19m
> istio-cleanup-old-ca-qmd7k 0/1 Completed 0 19m
> istio-egressgateway-58d98d898c-4qhx9 0/1 CrashLoopBackOff 7 19m
> istio-ingressgateway-6bc7c7c4bc-867sz 0/1 CrashLoopBackOff 7 19m
> istio-mixer-post-install-kjhhk 0/1 Completed 0 19m
> istio-pilot-6c5c6b586c-gq6gt 2/2 Running 0 19m
> istio-policy-5c7fbb4b9f-j2jjd 2/2 Running 0 19m
> istio-sidecar-injector-dbd67c88d-ffkgm 1/1 Running 0 19m
> istio-statsd-prom-bridge-6dbb7dcc7f-fcl8f 1/1 Running 0 19m
> istio-telemetry-54b5bf4847-5wq78 2/2 Running 0 19m
> istio-tracing-67dbb5b89f-l52vk 1/1 Running 0 19m
> prometheus-586d95b8d9-dw9xl 1/1 Running 0 19m
> servicegraph-6d86dfc6cb-25qtp 1/1 Running 1 19m
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-105) GossipRouter: additionally listen on IP multicast group and bridge traffic
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/JGRP-105?page=com.atlassian.jira.plugin.s... ]
Vladimir Blagojevic reassigned JGRP-105:
----------------------------------------
Assignee: Bela Ban (was: Vladimir Blagojevic)
> GossipRouter: additionally listen on IP multicast group and bridge traffic
> ---------------------------------------------------------------------------
>
> Key: JGRP-105
> URL: https://issues.jboss.org/browse/JGRP-105
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.8
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: Future
>
>
> GossipRouter should be augmented to not just route traffic between TCP endpoints, but also between an IP multicast group and all TCP endpoints.
> It should be configured with the properties for a (multicast-based) group X, and then forward messages from X to all of its attached endpoints, and vice versa.
> In the future, this concept could be extended to generic bridging functionality, which will allow to construct hierarchical messaging trees, similar to the MBone
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10615) Duplicate layer 'base' in integration/elytron testsuite
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10615?page=com.atlassian.jira.plugin... ]
Jan Kalina commented on WFLY-10615:
-----------------------------------
Will be resolved by WFARQ-51 (blocked by WFLY-10631)
> Duplicate layer 'base' in integration/elytron testsuite
> -------------------------------------------------------
>
> Key: WFLY-10615
> URL: https://issues.jboss.org/browse/WFLY-10615
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 13.0.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> Testsuite wildfly/testsuite/integration/elytron has workarounded module path problem:
> {code}
> MSC000001: Failed to start service jboss.patching.manager: org.jboss.msc.service.StartException in service jboss.patching.manager: java.lang.IllegalStateException: Duplicate layer 'base'
> at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:106)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> 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)
> Caused by: java.lang.IllegalStateException: Duplicate layer 'base'
> at org.jboss.as.patching.installation.LayersFactory$ProcessedLayers.addLayer(LayersFactory.java:305)
> at org.jboss.as.patching.installation.LayersFactory.processRoot(LayersFactory.java:182)
> at org.jboss.as.patching.installation.LayersFactory.process(LayersFactory.java:127)
> at org.jboss.as.patching.installation.LayersFactory.load(LayersFactory.java:86)
> at org.jboss.as.patching.installation.InstallationManagerImpl.<init>(InstallationManagerImpl.java:47)
> at org.jboss.as.patching.installation.InstallationManager.load(InstallationManager.java:185)
> at org.jboss.as.patching.installation.InstallationManagerService.load(InstallationManagerService.java:128)
> at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:63)
> ... 8 more
> {code}
> This is currently workarounded using following in pom.xml:
> {code}
> <!-- let's override the module.path parent configuration with dummy value, to avoid the "IllegalStateException: Duplicate layer 'base'" -->
> <module.path>foo</module.path>
> {code}
> But this prevent using `org.jboss.as.test.module.util.TestModule`, as it try to put created module into "foo", which fails - adding tests using custom modules requires removing this workaround.
> The reason is {{target/wildfly/modules}} is twice in {{module.path}} system property (when in InstallationManagerService):
> {code}
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/wildfly/modules:
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/wildfly/modules:
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/modules
> {code}
> Note: when reading {{module.path}} from the test (regardless RunAsClient is used or not), the value is correct:
> {code}
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/wildfly/modules:
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/modules
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10621) Server stop indefinitely blocked by DistributableSessionManager in lifecycleLock.writeLockInterruptibly()
by Petr H (JIRA)
[ https://issues.jboss.org/browse/WFLY-10621?page=com.atlassian.jira.plugin... ]
Petr H edited comment on WFLY-10621 at 6/25/18 8:02 AM:
--------------------------------------------------------
It isn't necessarily related to shared sessions, but they may be one of the possible triggers that lead to the use of the DistributableSessionManager where the problematic code lies.
Our case is:
- non-HA profile
- single server in the group
- 4 web applications deployed
- all web modules marked as distributable (in web.xml) - this is likely another trigger that, similarly to shared sessions, causes that the DistributableSessionManager is put into the action
- no shared sessions at all
But generally the StampedLock.writeLockInterruptibly() method is able to block forever which shouldn't be probably allowed during the server stop operation. Sure, it would be better to find out what does prevent the DistributableSessionManager from getting that lock, but since it isn't the kind of lock directly visible in thread dumps, I fear some debugging would be necessary.
I may still try the latest WildFly (13 atm.), but that will take some time. The issue doesn't even occur consistently (always) so it isn't so straightforward to reproduce.
was (Author: hostalp):
It isn't necessarily related to shared sessions, but they may be one of the possible triggers that lead to the use of the DistributableSessionManager where the problematic code lies.
Our case is:
- non-HA profile
- single server in the group
- 4 web applications depoyed
- all web modules marked as distributable (in web.xml) - this is likely another trigger that, similarly to shared sessions, causes that the DistributableSessionManager is put into the action
- no shared sessions at all
But generally the StampedLock.writeLockInterruptibly() method is able to block forever which shouldn't be probably allowed during the server stop operation. Sure, it would be better to find out what does prevent the DistributableSessionManager from getting that lock, but since it isn't the kind of lock directly visible in thread dumps, I fear some debugging would be necessary.
I may still try the latest WildFly (13 atm.), but that will take some time. The issue doesn't even occur consistently (always) so it isn't so straightforward to reproduce.
> Server stop indefinitely blocked by DistributableSessionManager in lifecycleLock.writeLockInterruptibly()
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10621
> URL: https://issues.jboss.org/browse/WFLY-10621
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Environment: CentOS 7.4.1708
> Java 1.8.0_172-b11
> WildFly 11.0.0.Final
> Reporter: Petr H
> Assignee: Paul Ferraro
> Labels: clustering, sessions
> Attachments: threaddump-wfly11-stop-blocked.txt
>
>
> Note: This is report for the issue reported here first https://developer.jboss.org/thread/277883
> It can be seen at WildFly 11 and EAP 7.1 at least, however as the particular code in the DistributableSessionManager class seems to be unchanged even in WildFly 13 it's likely to occur there as well. (We test WildFly 11 because it's closest to the EAP 7.1 which is being considered for the production use later in this project)
> Stop server operation may hang indefinitely due to the thread such as the following one being blocked:
> {noformat}
> "ServerService Thread Pool -- 24" #49 prio=5 os_prio=0 tid=0x00000000035d1000 nid=0x4de1 waiting on condition [0x00007f4bddc46000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000c4e61998> (a java.util.concurrent.locks.StampedLock)
> at java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1119)
> at java.util.concurrent.locks.StampedLock.writeLockInterruptibly(StampedLock.java:413)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.stop(DistributableSessionManager.java:90)
> - locked <0x00000000c4e60090> (a org.wildfly.clustering.web.undertow.session.DistributableSessionManager)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:599)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:589)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 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.security.SecurityContextThreadSetupAction$$Lambda$1005/749195997.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:603)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> The related code in the DistributableSessionManager makes use of the [java.util.concurrent.locks.StampedLock.writeLockInterruptibly()|https://d...] method which can theoretically block indefinitely and thus prevent the server stop from ever completing.
> The change was introduced in the following commit [WFLY-7695 Block session manager stop until all sessions are closed|https://github.com/wildfly/wildfly/commit/94863deeb96c4536ec5e8266...]
> This can occur even in non-clustered environments (non-HA profile) with web applications just being marked as distributable (web.xml).
> We don't know what prevents the lock from being obtained (unable to determine from the thread dump) so we can't unfortunately do much about it at the moment from the application side.
> We only tried to change the infinispan web local-cache configuration due to _ISPN000136_ errors intermittedly occurring, but that seems to have no effect. We tried various combinations of *locking isolation* (REPEATABLE_READ, READ_COMMITED), *transaction locking* (OPTIMISTIC, PESSIMISTIC) and *transaction mode* (NONE, BATCH) settings and it seems to occur with all of them.
> Note: The issue doesn't occur always, only in some cases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10621) Server stop indefinitely blocked by DistributableSessionManager in lifecycleLock.writeLockInterruptibly()
by Petr H (JIRA)
[ https://issues.jboss.org/browse/WFLY-10621?page=com.atlassian.jira.plugin... ]
Petr H commented on WFLY-10621:
-------------------------------
It isn't necessarily related to shared sessions, but they may be one of the possible triggers that lead to the use of the DistributableSessionManager where the problematic code lies.
Our case is:
- non-HA profile
- single server in the group
- 4 web applications depoyed
- all web modules marked as distributable (in web.xml) - this is likely another trigger that, similarly to shared sessions, causes that the DistributableSessionManager is put into the action
- no shared sessions at all
But generally the StampedLock.writeLockInterruptibly() method is able to block forever which shouldn't be probably allowed during the server stop operation. Sure, it would be better to find out what does prevent the DistributableSessionManager from getting that lock, but since it isn't the kind of lock directly visible in thread dumps, I fear some debugging would be necessary.
I may still try the latest WildFly (13 atm.), but that will take some time. The issue doesn't even occur consistently (always) so it isn't so straightforward to reproduce.
> Server stop indefinitely blocked by DistributableSessionManager in lifecycleLock.writeLockInterruptibly()
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10621
> URL: https://issues.jboss.org/browse/WFLY-10621
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Environment: CentOS 7.4.1708
> Java 1.8.0_172-b11
> WildFly 11.0.0.Final
> Reporter: Petr H
> Assignee: Paul Ferraro
> Labels: clustering, sessions
> Attachments: threaddump-wfly11-stop-blocked.txt
>
>
> Note: This is report for the issue reported here first https://developer.jboss.org/thread/277883
> It can be seen at WildFly 11 and EAP 7.1 at least, however as the particular code in the DistributableSessionManager class seems to be unchanged even in WildFly 13 it's likely to occur there as well. (We test WildFly 11 because it's closest to the EAP 7.1 which is being considered for the production use later in this project)
> Stop server operation may hang indefinitely due to the thread such as the following one being blocked:
> {noformat}
> "ServerService Thread Pool -- 24" #49 prio=5 os_prio=0 tid=0x00000000035d1000 nid=0x4de1 waiting on condition [0x00007f4bddc46000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000c4e61998> (a java.util.concurrent.locks.StampedLock)
> at java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1119)
> at java.util.concurrent.locks.StampedLock.writeLockInterruptibly(StampedLock.java:413)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.stop(DistributableSessionManager.java:90)
> - locked <0x00000000c4e60090> (a org.wildfly.clustering.web.undertow.session.DistributableSessionManager)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:599)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:589)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 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.security.SecurityContextThreadSetupAction$$Lambda$1005/749195997.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:603)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> The related code in the DistributableSessionManager makes use of the [java.util.concurrent.locks.StampedLock.writeLockInterruptibly()|https://d...] method which can theoretically block indefinitely and thus prevent the server stop from ever completing.
> The change was introduced in the following commit [WFLY-7695 Block session manager stop until all sessions are closed|https://github.com/wildfly/wildfly/commit/94863deeb96c4536ec5e8266...]
> This can occur even in non-clustered environments (non-HA profile) with web applications just being marked as distributable (web.xml).
> We don't know what prevents the lock from being obtained (unable to determine from the thread dump) so we can't unfortunately do much about it at the moment from the application side.
> We only tried to change the infinispan web local-cache configuration due to _ISPN000136_ errors intermittedly occurring, but that seems to have no effect. We tried various combinations of *locking isolation* (REPEATABLE_READ, READ_COMMITED), *transaction locking* (OPTIMISTIC, PESSIMISTIC) and *transaction mode* (NONE, BATCH) settings and it seems to occur with all of them.
> Note: The issue doesn't occur always, only in some cases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2644) [DMN Designer] Deletion of the column causes last column width increase
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2644?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2644:
--------------------------------
Description:
There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
h3. Manual Accpetance Test
# Steps to reproduce fixed
# Steps to reproduce fixed when decision table / relation is not top level context entry
# Repeat steps to reproduce, save and reopen, edit the expression (x)
was:
There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
h3. Manual Accpetance Test
# Steps to reproduce fixed
# Steps to reproduce fixed when decision table / relation is not top level context entry
> [DMN Designer] Deletion of the column causes last column width increase
> -----------------------------------------------------------------------
>
> Key: DROOLS-2644
> URL: https://issues.jboss.org/browse/DROOLS-2644
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
>
> There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
> h3. Manual Accpetance Test
> # Steps to reproduce fixed
> # Steps to reproduce fixed when decision table / relation is not top level context entry
> # Repeat steps to reproduce, save and reopen, edit the expression (x)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2644) [DMN Designer] Deletion of the column causes last column width increase
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2644?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2644:
--------------------------------
Description:
There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
h3. Manual Accpetance Test
# Steps to reproduce fixed
# Steps to reproduce fixed when decision table / relation is not top level context entry
was:
There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
h3. Manual Accpetance Test
Steps to reproduce fixed
# Decision table
# Relation
> [DMN Designer] Deletion of the column causes last column width increase
> -----------------------------------------------------------------------
>
> Key: DROOLS-2644
> URL: https://issues.jboss.org/browse/DROOLS-2644
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
>
> There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
> h3. Manual Accpetance Test
> # Steps to reproduce fixed
> # Steps to reproduce fixed when decision table / relation is not top level context entry
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years