May 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12086) Hibernate 2lc should be enabled if Hibernate cache properties are enabled and shared cache mode is not set to NONE

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-12086?page=com.atlassian.jira.plugin... ] Scott Marlow closed WFLY-12086. ------------------------------- > Hibernate 2lc should be enabled if Hibernate cache properties are enabled and shared cache mode is not set to NONE > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-12086 > URL: https://issues.jboss.org/browse/WFLY-12086 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 14.0.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Blocker > Fix For: 17.0.0.Beta1 > > > In org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.addProviderDependencies(PersistenceUnitMetadata pu), enable second level cache if persistence unit has hibernate.cache.use_query_cache or hibernate.cache.use_second_level_cache is true, then the second level cache should be enabled unless shared cache mode is set to NONE. > Workaround: > {code} > <shared-cache-mode>ALL</shared-cache-mode> > {code} > Or > {code} > <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12099) Cannot change transaction log store type via CLI

by Kabir Khan (Jira)

Kabir Khan created WFLY-12099: --------------------------------- Summary: Cannot change transaction log store type via CLI Key: WFLY-12099 URL: https://issues.jboss.org/browse/WFLY-12099 Project: WildFly Issue Type: Bug Components: Transactions Affects Versions: 17.0.0.Alpha1 Reporter: Kabir Khan Assignee: Ondrej Chaloupka For the OpenShift image work we need to be able to handle configuration of datasources. There is an effort underway to replace the current template marker replacement done in standalone.xml with CLI commands. While this works for the datasource subsystem itself, the OpenShift image scripts also touch other subsystems. For example if it is configured to use the Tx subsystem JDBC log store, we need to change the value of the /subsystem=transactions/log-store=log-store's 'type' attribute and to set the values of jdbc-action-store-table-prefix, jdbc-communication-store-table-prefix and jdbc-state-store-table-prefix and jdbc-store-datasource attributes on the subsystem itself. The equivalent in the existing xml marker replacement is to inject the following xml into the subsystem (the 'os77c791d37250' is calculated by the OpenShift launch scripts): {code} <jdbc-store datasource-jndi-name="java:jboss/datasources/testtx_postgresqlObjectStore"> <action table-prefix="os77c791d37250"/> <communication table-prefix="os77c791d37250"/> <state table-prefix="os77c791d37250"/> </jdbc-store> {code} However, this is not possible to do via CLI. Starting the server without a jdbc-store, you end up with the following {code} [standalone@localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource { "outcome" => "success", "result" => { "type" => "default", "transactions" => undefined } } {code} If you try to write the 'type' attribute it gives the error than it is read-only {code} [standalone@embedded /] /subsystem=transactions/log-store=log-store:write-attribute(name=type, value=jdbc) { "outcome" => "failed", "failure-description" => "WFLYCTL0048: Attribute type is not writable", "rolled-back" => true } {code} If you try to delete the resource and add it again, it gives another error: {code} [standalone@embedded /] /subsystem=transactions/log-store=log-store:remove { "outcome" => "success", "result" => undefined } [standalone@embedded /] /subsystem=transactions/log-store=log-store:add(type=jdbc) { "outcome" => "failed", "failure-description" => "WFLYCTL0212: Duplicate resource [ (\"subsystem\" => \"transactions\"), (\"log-store\" => \"log-store\") ]", "rolled-back" => true } {code} Despite the change looking like it has taken effect: {code} [standalone@embedded /] /subsystem=transactions/log-store=log-store:read-resource { "outcome" => "success", "result" => { "type" => "jdbc", "transactions" => undefined } } {code} However, it is not persisted in xml, so restarting the server it says the type is 'default' again -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-752) Update CR for Service Mesh TP11

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-752?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo resolved SWSQE-752. ------------------------------------------- Resolution: Done > Update CR for Service Mesh TP11 > ------------------------------- > > Key: SWSQE-752 > URL: https://issues.jboss.org/browse/SWSQE-752 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > Priority: Major > > CR has changed from > > {code:yaml} > apiVersion: istio.openshift.com/v1alpha3 > kind: ControlPlane > metadata: > name: basic-install > {code} > to > {code:yaml} > > apiVersion: maistra.io/v1 > kind: ServiceMeshControlPlane > metadata: > name: basic-install > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-752) Update CR for Service Mesh TP11

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-752?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo reassigned SWSQE-752: --------------------------------------------- Assignee: Guilherme Baufaker Rêgo > Update CR for Service Mesh TP11 > ------------------------------- > > Key: SWSQE-752 > URL: https://issues.jboss.org/browse/SWSQE-752 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > Priority: Major > > CR has changed from > > {code:yaml} > apiVersion: istio.openshift.com/v1alpha3 > kind: ControlPlane > metadata: > name: basic-install > {code} > to > {code:yaml} > > apiVersion: maistra.io/v1 > kind: ServiceMeshControlPlane > metadata: > name: basic-install > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-752) Update CR for Service Mesh TP11

by Guilherme Baufaker Rêgo (Jira)

Guilherme Baufaker Rêgo created SWSQE-752: --------------------------------------------- Summary: Update CR for Service Mesh TP11 Key: SWSQE-752 URL: https://issues.jboss.org/browse/SWSQE-752 Project: Kiali QE Issue Type: Sub-task Reporter: Guilherme Baufaker Rêgo CR has changed from {code:yaml} apiVersion: istio.openshift.com/v1alpha3 kind: ControlPlane metadata: name: basic-install {code} to {code:yaml} apiVersion: maistra.io/v1 kind: ServiceMeshControlPlane metadata: name: basic-install {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-751) Deactivate Old Jobs

by Guilherme Baufaker Rêgo (Jira)

Guilherme Baufaker Rêgo created SWSQE-751: --------------------------------------------- Summary: Deactivate Old Jobs Key: SWSQE-751 URL: https://issues.jboss.org/browse/SWSQE-751 Project: Kiali QE Issue Type: Sub-task Reporter: Guilherme Baufaker Rêgo Jobs to be activated: -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12098) Thread context class loader is wrong for ScheduledExecutorService threads

by Paul Pogonyshev (Jira)

Paul Pogonyshev created WFLY-12098: -------------------------------------- Summary: Thread context class loader is wrong for ScheduledExecutorService threads Key: WFLY-12098 URL: https://issues.jboss.org/browse/WFLY-12098 Project: WildFly Issue Type: Bug Components: Class Loading Affects Versions: 16.0.0.Final Reporter: Paul Pogonyshev Assignee: Richard Opalka Tasks submitted to the standard ScheduledExecutorService (JNDI: java:comp/DefaultManagedScheduledExecutorService) are executed in threads with class loader that cannot find application classes. This is a regression in 16.0 compared to 14.0 (haven't tested 15). Tasks submitted to the simple ExecutorService (JNDI: java:comp/DefaultManagedExecutorService) see the correct class loader. I.e. if I submit something like () -> { System.out.println (Thread.currentThread ().getContextClassLoader (); } to both services (i.e. exactly the same task), I get the following output. For ScheduledExecutorService (wrong): ModuleClassLoader for Module "org.jboss.as.ee" version 16.0.0.Final from local module loader @275710fc (finder: local module finder @525f1e4e (roots: [...]/wildfly/modules,[...]/wildfly/modules/system/layers/base)) For ExecutorService (as expected): ModuleClassLoader for Module "deployment.[...].war" from Service Module Loader Plain ExecutorService sees exactly the same class loader as normal threads in which HTTP request are processed. In version 14.0 this was also true for ScheduledExecutorService. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4032) Add src/main/resources as compiler root directory to Maven plugin

by Luca Molteni (Jira)

[ https://issues.jboss.org/browse/DROOLS-4032?page=com.atlassian.jira.plugi... ] Luca Molteni updated DROOLS-4032: --------------------------------- Tester: Tibor Zimanyi > Add src/main/resources as compiler root directory to Maven plugin > ----------------------------------------------------------------- > > Key: DROOLS-4032 > URL: https://issues.jboss.org/browse/DROOLS-4032 > Project: Drools > Issue Type: Task > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core, submarine > Fix For: 8.0.0.Final > > > this is required for the Quarkus extension to work -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2346) TCP_NIO2 deadlock during stop on Windows

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2346?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2346: -------------------------------- The deadlock is caused by one thread closing the Acceptor's _selector_ and the Acceptor thread handling a new connection. A quick solution would be to set {{running}} to false in the Acceptor (e.g. in a {{close}} method in the Acceptor), and the Acceptor itself closing its selector when {{running==false}}. > TCP_NIO2 deadlock during stop on Windows > ---------------------------------------- > > Key: JGRP-2346 > URL: https://issues.jboss.org/browse/JGRP-2346 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.18 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.0 > > > Hopefully the thread dump is enough to find it: > {noformat} > "testng-CustomFailurePolicyTxTest" #60 prio=0 tid=0x3c nid=NA blocked > java.lang.Thread.State: BLOCKED > at java.nio.channels.spi.AbstractSelectableChannel.removeKey(AbstractSelectableChannel.java:130) > - waiting to lock <0x7ae7c881> (a java.lang.Object) > at java.nio.channels.spi.AbstractSelector.deregister(AbstractSelector.java:188) > at sun.nio.ch.WindowsSelectorImpl.implClose(WindowsSelectorImpl.java:514) > - locked <0x6cc2bf11> (a java.lang.Object) > at sun.nio.ch.SelectorImpl.implCloseSelector(SelectorImpl.java:113) > - locked <0x2ab0aa2d> (a sun.nio.ch.Util$3) > - locked <0x2f9dc993> (a java.util.Collections$UnmodifiableSet) > - locked <0xfeca69a> (a sun.nio.ch.WindowsSelectorImpl) > at java.nio.channels.spi.AbstractSelector.close(AbstractSelector.java:111) > at org.jgroups.util.Util.close(Util.java:428) > at org.jgroups.util.Util.close(Util.java:439) > at org.jgroups.blocks.cs.NioServer.stop(NioServer.java:127) > - locked <0x21bca9ea> (a org.jgroups.blocks.cs.NioServer) > at org.jgroups.protocols.TCP_NIO2.handleDisconnect(TCP_NIO2.java:136) > at org.jgroups.protocols.TP.handleDownEvent(TP.java:1607) > at org.jgroups.protocols.BasicTCP.handleDownEvent(BasicTCP.java:129) > at org.jgroups.protocols.TP.down(TP.java:1082) > at org.jgroups.protocols.Discovery.down(Discovery.java:425) > at org.infinispan.test.fwk.TEST_PING.down(TEST_PING.java:208) > at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:379) > at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:236) > at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:101) > at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:553) > at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:570) > at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:346) > at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1076) > at org.jgroups.protocols.tom.TOA.down(TOA.java:80) > at org.jgroups.protocols.FlowControl.down(FlowControl.java:296) > at org.jgroups.protocols.RSVP.down(RSVP.java:102) > at org.jgroups.protocols.relay.RELAY2.down(RELAY2.java:380) > at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:908) > at org.jgroups.JChannel.down(JChannel.java:668) > at org.jgroups.JChannel.disconnect(JChannel.java:469) > - locked <0xef29e32> (a org.jgroups.JChannel) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.stop(JGroupsTransport.java:712) > at sun.reflect.GeneratedMethodAccessor148.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79) > at org.infinispan.commons.util.SecurityActions$$Lambda$154/1125443972.run(Unknown Source) > at org.infinispan.commons.util.SecurityActions.doPrivileged(SecurityActions.java:71) > at org.infinispan.commons.util.SecurityActions.invokeAccessibly(SecurityActions.java:76) > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:181) > at org.infinispan.factories.impl.BasicComponentRegistryImpl.performStop(BasicComponentRegistryImpl.java:601) > at org.infinispan.factories.impl.BasicComponentRegistryImpl.stopWrapper(BasicComponentRegistryImpl.java:590) > at org.infinispan.factories.impl.BasicComponentRegistryImpl.stop(BasicComponentRegistryImpl.java:461) > at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:441) > at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:376) > at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:775) > at org.infinispan.xsite.AbstractXSiteTest$$Lambda$4294/1094472832.accept(Unknown Source) > at java.util.ArrayList.forEach(ArrayList.java:1257) > at org.infinispan.xsite.AbstractXSiteTest.killSite(AbstractXSiteTest.java:89) > at org.infinispan.xsite.AbstractXSiteTest.killSites(AbstractXSiteTest.java:82) > at org.infinispan.xsite.AbstractXSiteTest.destroy(AbstractXSiteTest.java:76) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:124) > at org.testng.internal.MethodInvocationHelper.invokeMethodConsideringTimeout(MethodInvocationHelper.java:59) > at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:458) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:222) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:142) > at org.testng.internal.TestMethodWorker.invokeAfterClassMethods(TestMethodWorker.java:214) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:648) > at org.testng.TestRunner.run(TestRunner.java:505) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:455) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:40) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:489) > at org.testng.internal.thread.ThreadUtil$1.call(ThreadUtil.java:52) > 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) > Locked ownable synchronizers: > - <0x9411fa8> (a java.util.concurrent.ThreadPoolExecutor$Worker) > - <0x4fe21f2e> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > "NioServer.Selector [/127.0.0.1:7925]-3,CustomFailurePolicyTxTest-NodeC-12186" #205597 prio=0 tid=0x3231d nid=NA blocked > java.lang.Thread.State: BLOCKED > at sun.nio.ch.WindowsSelectorImpl.putEventOps(WindowsSelectorImpl.java:593) > - waiting to lock <0x6cc2bf11> (a java.lang.Object) > at sun.nio.ch.SocketChannelImpl.translateAndSetInterestOps(SocketChannelImpl.java:974) > at sun.nio.ch.SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:105) > at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:83) > at sun.nio.ch.SelectorImpl.register(SelectorImpl.java:134) > at java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:212) > - locked <0x7ae7c881> (a java.lang.Object) > - locked <0x6a684d8f> (a java.lang.Object) > at org.jgroups.blocks.cs.NioServer.handleAccept(NioServer.java:93) > at org.jgroups.blocks.cs.NioBaseServer$Acceptor.run(NioBaseServer.java:138) > at java.lang.Thread.run(Thread.java:748) > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-750) Re-wire PR Automation to install-upstream-pipeline-job

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-750?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-750: ------------------------------------------ Summary: Re-wire PR Automation to install-upstream-pipeline-job (was: Re-wire PR Automation to install-upstream-pipeline-job and deactivate Istio-and-Kiali-on-Openshift) > Re-wire PR Automation to install-upstream-pipeline-job > ------------------------------------------------------ > > Key: SWSQE-750 > URL: https://issues.jboss.org/browse/SWSQE-750 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2019