[JBoss JIRA] (WFWIP-31) [pretesting] ISPN005031: The supplied configuration for cache 'xyz' is missing a declaration named 'configuration' in session offloading scenario with hotrod store configured, using JDG as remote store
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFWIP-31?page=com.atlassian.jira.plugin.s... ]
Michal Vinkler closed WFWIP-31.
-------------------------------
> [pretesting] ISPN005031: The supplied configuration for cache 'xyz' is missing a declaration named 'configuration' in session offloading scenario with hotrod store configured, using JDG as remote store
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-31
> URL: https://issues.jboss.org/browse/WFWIP-31
> Project: WildFly WIP
> Issue Type: Bug
> Components: Clustering
> Reporter: Michal Vinkler
> Assignee: Radoslav Husar
>
> We hit incompatibility issue when running tests for RFE EAP7-942.
> Wildfly was built from https://github.com/rhusar/wildfly/tree/WFLY-9294
> Scenario:
> 2-node Wildfly cluster + 2-node JDG 7.2.0.CR1 cluster.
> Wildfly servers are configured to use hotrod store which is backed up by JDG cluster.
> All the servers are configured to use SSL secured connection.
> Wildfly configuration:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-failover-r...
> JDG configuration:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-failover-r...
> When the cache is started on Wildfly servers, they log this error:
> {code}
> [JBossINF] [0m[33m07:57:56,227 WARN [org.infinispan.client.hotrod.impl.protocol.Codec21] (HotRod-client-async-pool-2) ISPN004005: Error received from the server: org.infinispan.commons.CacheConfigurationException: ISPN005031: The supplied configuration for cache 'clusterbench-ee7.ear.cb.war' is missing a declaration named 'configuration':
> {code}
> Full stacktrace:
> {code}
> [JBossINF] [0m[31m07:57:56,231 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 75) MSC000001: Failed to start service org.wildfly.clustering.infinispan.cache.web.clusterbench-ee7.ear.cb.war: org.jboss.msc.service.StartException in service org.wildfly.clustering.infinispan.cache.web.clusterbench-ee7.ear.cb.war: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
> [JBossINF] at org.wildfly.clustering.service.FunctionalValueService.start(FunctionalValueService.java:70)
> [JBossINF] at org.wildfly.clustering.service.AsynchronousServiceBuilder.lambda$start$0(AsynchronousServiceBuilder.java:99)
> [JBossINF] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF] at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
> [JBossINF] at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:83)
> [JBossINF] at org.infinispan.commons.util.SecurityActions.doPrivileged(SecurityActions.java:71)
> [JBossINF] at org.infinispan.commons.util.SecurityActions.invokeAccessibly(SecurityActions.java:76)
> [JBossINF] at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:968)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.lambda$invokePrioritizedMethods$6(AbstractComponentRegistry.java:703)
> [JBossINF] at org.infinispan.factories.SecurityActions.lambda$run$1(SecurityActions.java:72)
> [JBossINF] at org.infinispan.security.Security.doPrivileged(Security.java:76)
> [JBossINF] at org.infinispan.factories.SecurityActions.run(SecurityActions.java:71)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.invokePrioritizedMethods(AbstractComponentRegistry.java:696)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:689)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:607)
> [JBossINF] at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:229)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:1020)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:421)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:644)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:589)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:475)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:461)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:447)
> [JBossINF] at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:86)
> [JBossINF] at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.get(CacheBuilder.java:71)
> [JBossINF] at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.get(CacheBuilder.java:54)
> [JBossINF] at org.wildfly.clustering.service.SuppliedValueService.lambda$new$0(SuppliedValueService.java:42)
> [JBossINF] at org.wildfly.clustering.service.FunctionalValueService.start(FunctionalValueService.java:68)
> [JBossINF] ... 7 more
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to start cache loaders
> [JBossINF] at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:179)
> [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] at java.lang.reflect.Method.invoke(Method.java:498)
> [JBossINF] at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
> [JBossINF] ... 31 more
> [JBossINF] Caused by: org.infinispan.persistence.spi.PersistenceException: org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=10 returned server error (status=0x85): org.infinispan.commons.CacheConfigurationException: ISPN005031: The supplied configuration for cache 'clusterbench-ee7.ear.cb.war' is missing a declaration named 'configuration':
> [JBossINF]
> [JBossINF]
> [JBossINF]
> [JBossINF]
> [JBossINF]
> [JBossINF]
> [JBossINF]
> [JBossINF] at org.jboss.as.clustering.infinispan.subsystem.remote.HotRodStore.init(HotRodStore.java:78)
> [JBossINF] at org.infinispan.persistence.manager.PersistenceManagerImpl.initializeBareInstance(PersistenceManagerImpl.java:752)
> [JBossINF] at org.infinispan.persistence.manager.PersistenceManagerImpl.createLoadersAndWriters(PersistenceManagerImpl.java:671)
> [JBossINF] at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:132)
> [JBossINF] ... 36 more
> [JBossINF] Caused by: org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=10 returned server error (status=0x85): org.infinispan.commons.CacheConfigurationException: ISPN005031: The supplied configuration for cache 'clusterbench-ee7.ear.cb.war' is missing a declaration named 'configuration':
> [JBossINF]
> [JBossINF]
> [JBossINF]
> [JBossINF]
> [JBossINF]
> [JBossINF]
> [JBossINF]
> [JBossINF] at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:383)
> [JBossINF] at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:177)
> [JBossINF] at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:163)
> [JBossINF] at org.infinispan.client.hotrod.impl.transport.netty.HeaderDecoder.decode(HeaderDecoder.java:85)
> [JBossINF] at org.infinispan.client.hotrod.impl.transport.netty.HintedReplayingDecoder.callDecode(HintedReplayingDecoder.java:98)
> [JBossINF] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
> [JBossINF] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [JBossINF] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [JBossINF] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> [JBossINF] at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:287)
> [JBossINF] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [JBossINF] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [JBossINF] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> [JBossINF] at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1240)
> [JBossINF] at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1041)
> [JBossINF] at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
> [JBossINF] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
> [JBossINF] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [JBossINF] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [JBossINF] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> [JBossINF] at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
> [JBossINF] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> [JBossINF] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> [JBossINF] at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
> [JBossINF] at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:1017)
> [JBossINF] at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:394)
> [JBossINF] at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:299)
> [JBossINF] at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF]
> {code}
> Wildfly Server link:
> https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-failover-...
> The cache is not started and the deployment fails.
> This is not happening when using Infinispan server built from latest master branch.
> No error is logged on JDG server side.
> Per [~rhusar] [comment|https://issues.jboss.org/browse/EAP7-942?focusedCommentId=1356321...], the root cause is ISPN-8941.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JGRP-2257) UDP#PacketReceiver stuck in busy loop when socket throws closed exception but socket is not closed
by Paul Illingworth (JIRA)
[ https://issues.jboss.org/browse/JGRP-2257?page=com.atlassian.jira.plugin.... ]
Paul Illingworth commented on JGRP-2257:
----------------------------------------
I don't think it is fixable either. Well, it would be possible to query the SocketException message to see if it is "socket closed" but this is always going to be fragile and given that it appears that this is a problem that has been seen before probably not worth doing.
I raised the ticket to more to record what was observed in case it is ever seen again.
I am more than happy for this to be closed.
> UDP#PacketReceiver stuck in busy loop when socket throws closed exception but socket is not closed
> --------------------------------------------------------------------------------------------------
>
> Key: JGRP-2257
> URL: https://issues.jboss.org/browse/JGRP-2257
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.12
> Environment: Windows Server 2016, 32GBytes memory running as a Hyper-V guest
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
> It was reported with just a single node running.
> Reporter: Paul Illingworth
> Assignee: Bela Ban
> Fix For: 4.0.12
>
>
> I have a had a report of a scenario where it looks like the UDP#PacketReceiver is stuck spinning in a busy loop. The following is a snippet of the log file from the system in question.
> {noformat}
> 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet
> java.net.SocketException: socket closed
> at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method)
> at java.net.DatagramSocket.receive(DatagramSocket.java:743)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694)
> at java.lang.Thread.run(Thread.java:748)
>
> 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet
> java.net.SocketException: socket closed
> at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method)
> at java.net.DatagramSocket.receive(DatagramSocket.java:743)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694)
> at java.lang.Thread.run(Thread.java:748)
>
> 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet
> java.net.SocketException: socket closed
> at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method)
> at java.net.DatagramSocket.receive(DatagramSocket.java:743)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Looking at the code it looks like the call to receive a packet
> {code:java}
> receiver_socket.receive(packet);
> {code}
> results in an exception being thrown because the socket is closed but then when the exception is caught
> {code:java}
> if(receiver_socket.isClosed()) {
> {code}
> method is queried which says the socket has not been closed and the loop then continues for ever.
> I guess this is related to JGRP-1669. To quote
> _I hope there is no condition which causes the socket receive() to spit out endless exceptions while not being closed..._
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JGRP-2257) UDP#PacketReceiver stuck in busy loop when socket throws closed exception but socket is not closed
by Paul Illingworth (JIRA)
[ https://issues.jboss.org/browse/JGRP-2257?page=com.atlassian.jira.plugin.... ]
Paul Illingworth edited comment on JGRP-2257 at 5/10/18 6:20 AM:
-----------------------------------------------------------------
I don't think it is fixable either. Well, it would be possible to query the SocketException message to see if it is "socket closed" but this is always going to be fragile and given that it appears that this is a problem that has not been seen before probably not worth doing.
I raised the ticket to more to record what was observed in case it is ever seen again.
I am more than happy for this to be closed.
was (Author: pillingworth):
I don't think it is fixable either. Well, it would be possible to query the SocketException message to see if it is "socket closed" but this is always going to be fragile and given that it appears that this is a problem that has been seen before probably not worth doing.
I raised the ticket to more to record what was observed in case it is ever seen again.
I am more than happy for this to be closed.
> UDP#PacketReceiver stuck in busy loop when socket throws closed exception but socket is not closed
> --------------------------------------------------------------------------------------------------
>
> Key: JGRP-2257
> URL: https://issues.jboss.org/browse/JGRP-2257
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.12
> Environment: Windows Server 2016, 32GBytes memory running as a Hyper-V guest
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
> It was reported with just a single node running.
> Reporter: Paul Illingworth
> Assignee: Bela Ban
> Fix For: 4.0.12
>
>
> I have a had a report of a scenario where it looks like the UDP#PacketReceiver is stuck spinning in a busy loop. The following is a snippet of the log file from the system in question.
> {noformat}
> 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet
> java.net.SocketException: socket closed
> at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method)
> at java.net.DatagramSocket.receive(DatagramSocket.java:743)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694)
> at java.lang.Thread.run(Thread.java:748)
>
> 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet
> java.net.SocketException: socket closed
> at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method)
> at java.net.DatagramSocket.receive(DatagramSocket.java:743)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694)
> at java.lang.Thread.run(Thread.java:748)
>
> 2018-03-16 14:05:43,273 SEVERE [] (214,unicast receiver,shared=udp) JGRP000190: failed receiving packet
> java.net.SocketException: socket closed
> at java.net.TwoStacksPlainDatagramSocketImpl.peekData(Native Method)
> at java.net.DatagramSocket.receive(DatagramSocket.java:743)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:694)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Looking at the code it looks like the call to receive a packet
> {code:java}
> receiver_socket.receive(packet);
> {code}
> results in an exception being thrown because the socket is closed but then when the exception is caught
> {code:java}
> if(receiver_socket.isClosed()) {
> {code}
> method is queried which says the socket has not been closed and the loop then continues for ever.
> I guess this is related to JGRP-1669. To quote
> _I hope there is no condition which causes the socket receive() to spit out endless exceptions while not being closed..._
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (SWSQE-200) B12 OpenShift Cluster is flaky
by Filip Brychta (JIRA)
[ https://issues.jboss.org/browse/SWSQE-200?page=com.atlassian.jira.plugin.... ]
Filip Brychta commented on SWSQE-200:
-------------------------------------
Yes, b24 and b25 are free - https://mojo.redhat.com/docs/DOC-1013097
> B12 OpenShift Cluster is flaky
> ------------------------------
>
> Key: SWSQE-200
> URL: https://issues.jboss.org/browse/SWSQE-200
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Kevin Earls
> Assignee: Guilherme Baufaker Rêgo
>
> I'm opening this mostly as a placeholder, and will update it as I get more information on the problems I've been experiencing. Since I've been using B12 I've been experiencing more frequent failures than on other clusters, including minishift on my laptop and the CNCF CI Jenkins. Here are a couple of instances:
> 1. Deploying ElasticSearch along with the Jaeger Production templates requires allocating 2G or memory, even though the default 512M works fine elsewhere. This can be seen in the Jaeger Standalone Performance tests job here: https://jenkins-jaeger-test.openshift3.jonqe.lab.eng.bos.redhat.com/job/J... . If you run the job without changing the ES_MEMORY parameter to 2Gi it will fail.
> 2. I have a set of smoke tests for Red Hat productized artifacts for the Jaeger Java client which are run using the Jaeger all-in-one template. It's fairly simple, but on B12 deployment of the Jaeger all-in-one images fails on every other build. I've made a copy of the job here: https://jenkins-jaeger-test.openshift3.jonqe.lab.eng.bos.redhat.com/job/F... and its history should be clear.
> So far I have not been able to get any useful information about why this is failing. In the OpenShift console it looks like Jaeger has started correctly. There are no errors in the logs, nor any to be found under monitoring. But if you click on the Jaeger link, you get the message "Application is not available . The application is currently not serving requests at this endpoint. It may not have been started or is still starting."
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2541) [Guided Decision Table] Selected Cell highlight ignores hidden columns
by Michael Anstis (JIRA)
Michael Anstis created DROOLS-2541:
--------------------------------------
Summary: [Guided Decision Table] Selected Cell highlight ignores hidden columns
Key: DROOLS-2541
URL: https://issues.jboss.org/browse/DROOLS-2541
Project: Drools
Issue Type: Bug
Components: Guided Decision Table Editor
Affects Versions: 7.7.0.Final
Reporter: Michael Anstis
Assignee: Michael Anstis
If you create a Guided Decision Table and hide at least one column and then select on the "Row number" cell (selecting all cells on the row) the "Selection" highlight overflows the table. This is caused by the creation of the highlight ignoring hidden columns.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2540) [Guided Decision Table] Selected Cell highlight ignores hidden columns
by Michael Anstis (JIRA)
Michael Anstis created DROOLS-2540:
--------------------------------------
Summary: [Guided Decision Table] Selected Cell highlight ignores hidden columns
Key: DROOLS-2540
URL: https://issues.jboss.org/browse/DROOLS-2540
Project: Drools
Issue Type: Bug
Components: Guided Decision Table Editor
Affects Versions: 7.7.0.Final
Reporter: Michael Anstis
Assignee: Michael Anstis
If you create a Guided Decision Table and hide at least one column and then select on the "Row number" cell (selecting all cells on the row) the "Selection" highlight overflows the table. This is caused by the creation of the highlight ignoring hidden columns.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10349) WeldBundledLibraryDeployment Test cases fail on IBM jdk
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-10349?page=com.atlassian.jira.plugin... ]
Petr Kremensky commented on WFLY-10349:
---------------------------------------
WFCORE-3816 should handle this, with this the tests no longer fails. Thanks for assistance.
> WeldBundledLibraryDeployment Test cases fail on IBM jdk
> -------------------------------------------------------
>
> Key: WFLY-10349
> URL: https://issues.jboss.org/browse/WFLY-10349
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Environment: {noformat}
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> Maven home: /usr/lib/maven
> Java version: 1.8.0_161, vendor: IBM Corporation
> Java home: /usr/lib/java/ibm-java-8.0-5.11/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.15.17-300.fc27.x86_64", arch: "amd64", family: "unix"
> $ git rev-parse --short HEAD
> 11e21f08d3
> {noformat}
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
>
> WeldBundledLibraryDeploymentEarTestCase and WeldBundledLibraryDeploymentTestCase fails on IBM jdk.
> *reproduce*
> {noformat}
> git clone https://github.com/wildfly/wildfly.git ; cd wildfly
> mvn clean install -B -DskipTests
> cd testsuite/integration/basic
> mvn test -Dtest=WeldBundledLibraryDeploymentEarTestCase,WeldBundledLibraryDeploymentTestCase -DtestLogToFile=false
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Errors:
> [ERROR] WeldBundledLibraryDeploymentEarTestCase.org.jboss.as.test.integration.weld.multideployment.WeldBundledLibraryDeploymentEarTestCase » Deployment
> [ERROR] WeldBundledLibraryDeploymentTestCase.org.jboss.as.test.integration.weld.multideployment.WeldBundledLibraryDeploymentTestCase » Deployment
> [INFO]
> [ERROR] Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
> {noformat}
>
> *server log errors*
> {noformat}
> 11:56:22,104 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.extension-index: org.jboss.msc.service.StartException in service jboss.deployment.extension-index: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1728)
> 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:811)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.server.moduleservice.ExtensionIndexService.start(ExtensionIndexService.java:94)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> ... 6 more
> 11:56:22,260 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "2b7495c2-60cb-4e65-8c99-4decc85ace30.ear")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => ["jboss.deployment.unit.\"2b7495c2-60cb-4e65-8c99-4decc85ace30.ear\".REGISTER"],
> "Services that may be the cause:" => ["jboss.deployment.unit.\"2b7495c2-60cb-4e65-8c99-4decc85ace30.ear\".REGISTER"]
> }}
> 11:56:22,261 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "2b7495c2-60cb-4e65-8c99-4decc85ace30.ear" was rolled back with the following failure message:
> {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => ["jboss.deployment.unit.\"2b7495c2-60cb-4e65-8c99-4decc85ace30.ear\".REGISTER"],
> "Services that may be the cause:" => ["jboss.deployment.unit.\"2b7495c2-60cb-4e65-8c99-4decc85ace30.ear\".REGISTER"]
> }}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months