October 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12233) Upgrade Hibernate ORM from 5.3.10 to 5.3.11

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12233?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-12233: ----------------------------------------- Hi [~smarlow] -- please don't Close issues that are Resolved as Done. It makes the release process harder as we need to do things with them during the release. > Upgrade Hibernate ORM from 5.3.10 to 5.3.11 > ------------------------------------------- > > Key: WFLY-12233 > URL: https://issues.jboss.org/browse/WFLY-12233 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Affects Versions: 17.0.0.Final > Reporter: Martin Stefanko > Assignee: Scott Marlow > Priority: Major > Labels: downstream_dependency > Fix For: 18.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-12233) Upgrade Hibernate ORM from 5.3.10 to 5.3.11

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12233?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved WFLY-12233. ------------------------------------- Resolution: Done > Upgrade Hibernate ORM from 5.3.10 to 5.3.11 > ------------------------------------------- > > Key: WFLY-12233 > URL: https://issues.jboss.org/browse/WFLY-12233 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Affects Versions: 17.0.0.Final > Reporter: Martin Stefanko > Assignee: Scott Marlow > Priority: Major > Labels: downstream_dependency > Fix For: 18.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-12233) Upgrade Hibernate ORM from 5.3.10 to 5.3.11

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12233?page=com.atlassian.jira.plugin... ] Brian Stansberry reopened WFLY-12233: ------------------------------------- > Upgrade Hibernate ORM from 5.3.10 to 5.3.11 > ------------------------------------------- > > Key: WFLY-12233 > URL: https://issues.jboss.org/browse/WFLY-12233 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Affects Versions: 17.0.0.Final > Reporter: Martin Stefanko > Assignee: Scott Marlow > Priority: Major > Labels: downstream_dependency > Fix For: 18.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-12613) Exclude IBM J9 JVM from Byteman-based test cases

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12613?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12613: ------------------------------------ Fix Version/s: 19.0.0.Beta1 (was: 18.0.0.Final) > Exclude IBM J9 JVM from Byteman-based test cases > ------------------------------------------------ > > Key: WFLY-12613 > URL: https://issues.jboss.org/browse/WFLY-12613 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 18.0.0.Final > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > Fix For: 19.0.0.Beta1 > > > The test case org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase uses Byteman to check a condition for validating whether the test passes or fails. The component arquillian-extension-byteman is used to allow the use of Byteman annotations within the Arquillian test case. > There is a problem with running Byteman-based test cases against the IBM J9 Java runtime: > {noformat} > [ERROR] org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase Time elapsed: 1.202 s <<< ERROR! > java.lang.RuntimeException: Could not install byteman agent > at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:98) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71) > at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23) > at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344) > at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417) > Caused by: com.sun.tools.attach.AgentInitializationException: ATTACH_ERR AgentInitializationException102 > at ibm.tools.attach.J9VirtualMachine.loadAgent(J9VirtualMachine.java:66) > at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:91) > ... 28 more > {noformat} > > {noformat} > [nrla@localhost wildfly-git-repo]$ java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build pxa6480sr2-20151023_01(SR2)) > IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20151019_272764 (JIT enabled, AOT enabled) > J9VM - R28_Java8_SR2_20151019_2144_B272764 > JIT - tr.r14.java_20151006_102517.04 > GC - R28_Java8_SR2_20151019_2144_B272764_CMPRSS > J9CL - 20151019_272764) > JCL - 20151022_01 based on Oracle jdk8u65-b17 > {noformat} > Until this JVM bug can be fixed, we need to exclude executions of this test against the IBM J9 JVM. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it

by Dennis Reed (Jira)

[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ] Dennis Reed updated JGRP-2387: ------------------------------ Description: If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change. This does not cause any functional issues in the cluster, but can cause repeated WARN logs in some cases. was:If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change. > Message from a non-member causes FD_ALL to continually suspect it > ----------------------------------------------------------------- > > Key: JGRP-2387 > URL: https://issues.jboss.org/browse/JGRP-2387 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Major > > If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change. > This does not cause any functional issues in the cluster, but can cause repeated WARN logs in some cases. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it

by Dennis Reed (Jira)

[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on JGRP-2387: ----------------------------------- Two potential solutions: - verify the node is a cluster member before adding an entry to timestamps. - add to timestamps, but then when sending a suspect event verify it's a member of the cluster. If not, remove from timestamps and ignore. (this one may be lower impact than checking on every message) > Message from a non-member causes FD_ALL to continually suspect it > ----------------------------------------------------------------- > > Key: JGRP-2387 > URL: https://issues.jboss.org/browse/JGRP-2387 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Major > > If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it

by Dennis Reed (Jira)

[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on JGRP-2387: ----------------------------------- This was first observed when a node leaving the cluster triggered it. It caused continuous WARN logs from FD_ALL suspecting the node (DEBUG in most other versions of JGroups), and WARN "no physical address" logs because the member had been removed from the address cache. > Message from a non-member causes FD_ALL to continually suspect it > ----------------------------------------------------------------- > > Key: JGRP-2387 > URL: https://issues.jboss.org/browse/JGRP-2387 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Major > > If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it

by Dennis Reed (Jira)

[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on JGRP-2387: ----------------------------------- The technical detail: FD_SOCK keeps track of the time the last message from each member was seen in the "timestamps" map. It periodically suspects any entries in this map whose timestamps are too old. When a new view is installed, any members that left are removed from the map, and an entry is added for each member if it doesn't already exist. When any FD_SOCK message is received from a member its entry in "timestamps" is updated. If msg_counts_as_heartbeat is on then the same is done for every message from that member. (this is off by default) The problem: When it updates the timestamp, no membership check is done first. So a message from a non-member triggers an entry added to the table, which is never removed until the next view is processed, and will continually send suspect events up the stack. This triggers VERIFY_SUSPECT to try to ping it, which it can't because it doesn't have the address (but can cause a "no physical address" log in some cases). VERIFY_SUSPECT will eventually send SUSPECT events up the stack, which are ignored by GMS because the node isn't part of the cluster. > Message from a non-member causes FD_ALL to continually suspect it > ----------------------------------------------------------------- > > Key: JGRP-2387 > URL: https://issues.jboss.org/browse/JGRP-2387 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Major > > If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4599) [DMN Designer] Decision Tables: Hit Policy select drop-down remains visible if popover closed

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-4599?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-4599: ----------------------------------- Attachment: DROOLS-4599-1.png > [DMN Designer] Decision Tables: Hit Policy select drop-down remains visible if popover closed > --------------------------------------------------------------------------------------------- > > Key: DROOLS-4599 > URL: https://issues.jboss.org/browse/DROOLS-4599 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.28.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: DROOLS-4599-1.png, DROOLS-4599-2.png > > > The _drop down_ component of the Hit Policy _select_ component remains visible if the popover is dismissed by clicking elsewhere (outside the popover). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4599) [DMN Designer] Decision Tables: Hit Policy select drop-down remains visible if popover closed

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-4599?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-4599: ----------------------------------- Attachment: DROOLS-4599-2.png > [DMN Designer] Decision Tables: Hit Policy select drop-down remains visible if popover closed > --------------------------------------------------------------------------------------------- > > Key: DROOLS-4599 > URL: https://issues.jboss.org/browse/DROOLS-4599 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.28.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: DROOLS-4599-1.png, DROOLS-4599-2.png > > > The _drop down_ component of the Hit Policy _select_ component remains visible if the popover is dismissed by clicking elsewhere (outside the popover). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2019