November 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4596) Write lock is acquired reading patching resource using include-runtime

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/WFCORE-4596?page=com.atlassian.jira.plugi... ] Yeray Borges updated WFCORE-4596: --------------------------------- Description: This is initially created as a bug but it needs first some investigation to discover if it is really necessary to acquire the write lock when the patching resource is read. If it is unnecessary, we should remove this need. The following operation is acquiring the write lock: {noformat} /host=slave/core-service=patching:read-resource(include-runtime=true) {noformat} It potentially will block if there is any other operation that has already acquired the lock. One consequence found due to this issue was HAL could block and hang if an HC is starting and the user clicks on 'Patching' menu entry. It was fixed in HAL, where an HC being restarted is no longer shown in the Patching menu. The main problem seems to be in PatchStreamResourceOperationStepHandler, which is the parent handler used for the handlers that manage patching operations. This parent handler is always acquiring the write lock. was: This is initially created as a bug but it needs first some investigation to discover if it is really necessary to acquire the write lock when the patching resource is read. If it is unnecessary, we should remove this need. The following operation is acquiring the write lock: {noformat} /host=slave/core-service=patching:read-resource(include-runtime=true) {noformat} It potentially will block if there is any other operation which has already acquired the lock. One consequence found due to this issue was HAL could block and hang if an HC is starting and the user clicks on 'Patching' menu entry. It was fixed in HAL, where HS being restarted are no longer shown in the Patching menu. The main problem seems to be in PatchStreamResourceOperationStepHandler, which is the parent handler used for the handlers that manage patching operations. This parent handler is always acquiring the write lock. > Write lock is acquired reading patching resource using include-runtime > ---------------------------------------------------------------------- > > Key: WFCORE-4596 > URL: https://issues.jboss.org/browse/WFCORE-4596 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Major > > This is initially created as a bug but it needs first some investigation to discover if it is really necessary to acquire the write lock when the patching resource is read. If it is unnecessary, we should remove this need. > The following operation is acquiring the write lock: > {noformat} > /host=slave/core-service=patching:read-resource(include-runtime=true) > {noformat} > It potentially will block if there is any other operation that has already acquired the lock. One consequence found due to this issue was HAL could block and hang if an HC is starting and the user clicks on 'Patching' menu entry. It was fixed in HAL, where an HC being restarted is no longer shown in the Patching menu. > The main problem seems to be in PatchStreamResourceOperationStepHandler, which is the parent handler used for the handlers that manage patching operations. This parent handler is always acquiring the write lock. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2399) Problem with loading resources from the bundle root (/) in OSGI environment

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2399?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2399: -------------------------------- I'm not an osgi person; if you want this fixed, please submit a pull request or post this to the mailing list, so some expert can chime in... > Problem with loading resources from the bundle root (/) in OSGI environment > ---------------------------------------------------------------------------- > > Key: JGRP-2399 > URL: https://issues.jboss.org/browse/JGRP-2399 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.19 > Environment: Reproducible both on linux(centos 7.3) and windows 10, my project is using org.eclipse.equinox 3.6.0.v20100503, oracle jdk 1.8.0.212 > Reporter: Orlin Stalyanov > Assignee: Bela Ban > Priority: Major > > {color:#0747A6}Util.java:108 > resource_bundle=ResourceBundle.getBundle("jg-messages",Locale.getDefault(),Util.class.getClassLoader());{color} > is crashing with: > ... > {color:#0747A6}Caused by: java.util.MissingResourceException: Can't find bundle for base name jg-messages, locale en_US > at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1581) > at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:1091) > at org.jgroups.util.Util.<clinit>(Util.java:108) > ... 162 more{color} > found some relevant info here : https://stackoverflow.com/questions/7564370/importing-resources-from-osgi... > seems like OSGI doesn't really like resources residing in the bundle root ... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2397) MPING: issue with MulticastSocket creation

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2397?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2397. ---------------------------- Resolution: Done > MPING: issue with MulticastSocket creation > ------------------------------------------ > > Key: JGRP-2397 > URL: https://issues.jboss.org/browse/JGRP-2397 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.8 > > > ------------------------------------------------------------------- > 1185 [ERROR] MPING: JGRP000200: failed sending discovery request > java.io.IOException: Can't assign requested address > at java.net.PlainDatagramSocketImpl.send(Native Method) ~[?:?] > at java.net.DatagramSocket.send(DatagramSocket.java:695) ~[?:?] > at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:293) [classes/:?] > at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:64) [classes/:?] > at org.jgroups.protocols.PING.findMembers(PING.java:32) [classes/:?] > at org.jgroups.protocols.Discovery.invokeFindMembers(Discovery.java:217) [classes/:?] > at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244) [classes/:?] > at org.jgroups.protocols.Discovery.down(Discovery.java:383) [classes/:?] > at org.jgroups.protocols.MERGE3.down(MERGE3.java:278) [classes/:?] > at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:235) [classes/:?] > at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:102) [classes/:?] > at org.jgroups.protocols.BARRIER.down(BARRIER.java:136) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:555) [classes/:?] > at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:595) [classes/:?] > at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:349) [classes/:?] > at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:72) [classes/:?] > at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41) [classes/:?] > at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1054) [classes/:?] > at org.jgroups.protocols.FlowControl.down(FlowControl.java:295) [classes/:?] > at org.jgroups.protocols.FlowControl.down(FlowControl.java:295) [classes/:?] > at org.jgroups.protocols.FRAG2.down(FRAG2.java:141) [classes/:?] > at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:207) [classes/:?] > at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:928) [classes/:?] > at org.jgroups.JChannel.down(JChannel.java:627) [classes/:?] > at org.jgroups.JChannel._connect(JChannel.java:855) [classes/:?] > at org.jgroups.JChannel.connect(JChannel.java:352) [classes/:?] > at org.jgroups.JChannel.connect(JChannel.java:343) [classes/:?] > at org.jgroups.demos.Draw.go(Draw.java:193) [classes/:?] > at org.jgroups.demos.Draw.main(Draw.java:156) [classes/:?] -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2397) MPING: issue with MulticastSocket creation

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2397?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2397: -------------------------------- Fixed by sending the multicast discovery request via separate McastSocket, *not* the receive mcast socket. > MPING: issue with MulticastSocket creation > ------------------------------------------ > > Key: JGRP-2397 > URL: https://issues.jboss.org/browse/JGRP-2397 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.8 > > > ------------------------------------------------------------------- > 1185 [ERROR] MPING: JGRP000200: failed sending discovery request > java.io.IOException: Can't assign requested address > at java.net.PlainDatagramSocketImpl.send(Native Method) ~[?:?] > at java.net.DatagramSocket.send(DatagramSocket.java:695) ~[?:?] > at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:293) [classes/:?] > at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:64) [classes/:?] > at org.jgroups.protocols.PING.findMembers(PING.java:32) [classes/:?] > at org.jgroups.protocols.Discovery.invokeFindMembers(Discovery.java:217) [classes/:?] > at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244) [classes/:?] > at org.jgroups.protocols.Discovery.down(Discovery.java:383) [classes/:?] > at org.jgroups.protocols.MERGE3.down(MERGE3.java:278) [classes/:?] > at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:235) [classes/:?] > at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:102) [classes/:?] > at org.jgroups.protocols.BARRIER.down(BARRIER.java:136) [classes/:?] > at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:555) [classes/:?] > at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:595) [classes/:?] > at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:349) [classes/:?] > at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:72) [classes/:?] > at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41) [classes/:?] > at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1054) [classes/:?] > at org.jgroups.protocols.FlowControl.down(FlowControl.java:295) [classes/:?] > at org.jgroups.protocols.FlowControl.down(FlowControl.java:295) [classes/:?] > at org.jgroups.protocols.FRAG2.down(FRAG2.java:141) [classes/:?] > at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:207) [classes/:?] > at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:928) [classes/:?] > at org.jgroups.JChannel.down(JChannel.java:627) [classes/:?] > at org.jgroups.JChannel._connect(JChannel.java:855) [classes/:?] > at org.jgroups.JChannel.connect(JChannel.java:352) [classes/:?] > at org.jgroups.JChannel.connect(JChannel.java:343) [classes/:?] > at org.jgroups.demos.Draw.go(Draw.java:193) [classes/:?] > at org.jgroups.demos.Draw.main(Draw.java:156) [classes/:?] -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12468) Rename BOMs artifactIds with javaee8-* to jakartaee8-*

by Eduardo Martins (Jira)

[ https://issues.jboss.org/browse/WFLY-12468?page=com.atlassian.jira.plugin... ] Eduardo Martins closed WFLY-12468. ---------------------------------- Resolution: Done > Rename BOMs artifactIds with javaee8-* to jakartaee8-* > ------------------------------------------------------ > > Key: WFLY-12468 > URL: https://issues.jboss.org/browse/WFLY-12468 > Project: WildFly > Issue Type: Sub-task > Components: BOM, Quickstarts > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Blocker > Fix For: 18.0.0.Final > > > The following WildFly BOM artifactIds should be renamed to not include javaee, replacing it with jakartaee8: > * wildfly-javaee8 > * wildfly-javaee8-with-tools > Reference to renamed BOMs in Quickstarts project should also be updated. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2399) Problem with loading resources from the bundle root (/) in OSGI environment

by Orlin Stalyanov (Jira)

Orlin Stalyanov created JGRP-2399: ------------------------------------- Summary: Problem with loading resources from the bundle root (/) in OSGI environment Key: JGRP-2399 URL: https://issues.jboss.org/browse/JGRP-2399 Project: JGroups Issue Type: Bug Affects Versions: 3.6.19 Environment: Reproducible both on linux(centos 7.3) and windows 10, my project is using org.eclipse.equinox 3.6.0.v20100503, oracle jdk 1.8.0.212 Reporter: Orlin Stalyanov Assignee: Bela Ban {color:#0747A6}Util.java:108 resource_bundle=ResourceBundle.getBundle("jg-messages",Locale.getDefault(),Util.class.getClassLoader());{color} is crashing with: ... {color:#0747A6}Caused by: java.util.MissingResourceException: Can't find bundle for base name jg-messages, locale en_US at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1581) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396) at java.util.ResourceBundle.getBundle(ResourceBundle.java:1091) at org.jgroups.util.Util.<clinit>(Util.java:108) ... 162 more{color} found some relevant info here : https://stackoverflow.com/questions/7564370/importing-resources-from-osgi... seems like OSGI doesn't really like resources residing in the bundle root ... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4295) Upgrade jboss-vfs to 3.2.15.Final

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFCORE-4295?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFCORE-4295: ----------------------------------- Component/s: Server > Upgrade jboss-vfs to 3.2.15.Final > --------------------------------- > > Key: WFCORE-4295 > URL: https://issues.jboss.org/browse/WFCORE-4295 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Reporter: Tomas Hofman > Assignee: Richard Opalka > Priority: Major > Fix For: 11.0.0.Beta3 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4295) Upgrade jboss-vfs to 3.2.15.Final

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFCORE-4295?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFCORE-4295: ----------------------------------- Fix Version/s: 11.0.0.Beta3 > Upgrade jboss-vfs to 3.2.15.Final > --------------------------------- > > Key: WFCORE-4295 > URL: https://issues.jboss.org/browse/WFCORE-4295 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Tomas Hofman > Assignee: Richard Opalka > Priority: Major > Fix For: 11.0.0.Beta3 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4295) Upgrade jboss-vfs to 3.2.15.Final

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFCORE-4295?page=com.atlassian.jira.plugi... ] Richard Opalka reassigned WFCORE-4295: -------------------------------------- Assignee: Richard Opalka > Upgrade jboss-vfs to 3.2.15.Final > --------------------------------- > > Key: WFCORE-4295 > URL: https://issues.jboss.org/browse/WFCORE-4295 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Tomas Hofman > Assignee: Richard Opalka > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2396) increasing networkdata, cpu and heap

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2396?page=com.atlassian.jira.plugin.... ] Bela Ban closed JGRP-2396. -------------------------- Resolution: Cannot Reproduce Closed. If the problem persists, I suggest post to the mailing list first, so we can see if a JIRA ticket needs to be created. Cheers, Bela > increasing networkdata, cpu and heap > ------------------------------------ > > Key: JGRP-2396 > URL: https://issues.jboss.org/browse/JGRP-2396 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.19 > Reporter: Rob van der Boom > Assignee: Bela Ban > Priority: Major > Attachments: Schermafbeelding 2019-11-08 om 15.43.04.png, Schermafbeelding 2019-11-08 om 15.44.52.png, Schermafbeelding 2019-11-08 om 16.00.48.png, jstack-production-pod0.dump, standalone-ha.xml > > > hey, > we have an keycloak (sso) setup, version 7.0.1 running in kubernetes - aws. > Its build on wildfly 17, infinispan 9.4 and jgroups 4.0.19. > We have 3 pods running in standalone-ha with cache setup on distribution (all 3 nodes - so equivalent to replication) > ISSUE: > We see a slowly growing of networkstatistics, heap and cpu, while the number of sessions in keycloak (cached) remain almost stable. > The cpu growth is caused by the TQbundler process, which explaines the networkdata growth. It looks like this is causing also a memory leakage.. > every 5 days we have to restart the pods and then every resets to a very low level including the heap. this while all sessions are still valid and cached. > The only issue i could find maybe related to this is: > https://issues.jboss.org/browse/JGRP-2382?jql=project%20%3D%20JGRP%20AND%... > Could this be the same issue and does it also cause increasing network and cpu (since that is why we have to restart, the heap has much space left !). > And if so how does this issue continue since for us its a major issue. > We als had this issue already in keycloak 5 (wildfly 15), thats why we upgraded to the latest available version. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 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 November 2019