February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6655) When creating JMS bridge management API should pass bridge name to JMS broker

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-6655?page=com.atlassian.jira.plugin.... ] James Perkins closed WFLY-6655. ------------------------------- Resolution: Out of Date This appears to be out of date. Please reopen if I've misunderstood. > When creating JMS bridge management API should pass bridge name to JMS broker > ----------------------------------------------------------------------------- > > Key: WFLY-6655 > URL: https://issues.jboss.org/browse/WFLY-6655 > Project: WildFly > Issue Type: Bug > Components: JMS > Environment: JBoss EAP 7.0 > Reporter: Tom Ross > Assignee: Chen Maoqian > > In situations where there are multiple JMS bridges being created it woudl help if bridge name is logged in the server name. This helps with recognising which JMS bridge is having problems. > For this to work the JBoss messaging API layer has to pass bridge name to the JMS broker. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6670) Upgrade Infinispan to 8.2.3.Final

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-6670?page=com.atlassian.jira.plugin.... ] James Perkins closed WFLY-6670. ------------------------------- Resolution: Out of Date > Upgrade Infinispan to 8.2.3.Final > --------------------------------- > > Key: WFLY-6670 > URL: https://issues.jboss.org/browse/WFLY-6670 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Mathieu Lachance > Assignee: Paul Ferraro > > We are currently suffering from ISPN-4390. > Once Infinispan 8.2.3 will be released, it should be incorporated as soon as possible to get rid of the issue. > Thanks! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8258) Upgrade to IronJacamar 1.3.6

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-8258?page=com.atlassian.jira.plugin.... ] James Perkins closed WFLY-8258. ------------------------------- Resolution: Out of Date > Upgrade to IronJacamar 1.3.6 > ---------------------------- > > Key: WFLY-8258 > URL: https://issues.jboss.org/browse/WFLY-8258 > Project: WildFly > Issue Type: Component Upgrade > Components: JCA > Affects Versions: 10.1.0.Final > Reporter: Patrick Reinhart > Assignee: Stefano Maestri > Fix For: 10.x.x TBD > > > Statement.cancel() is not invoked until the statement is completed -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3616) SuspendStateReadHandler doesn't provide a value if the SuspendController is not installed

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3616: ---------------------------------------- Summary: SuspendStateReadHandler doesn't provide a value if the SuspendController is not installed Key: WFCORE-3616 URL: https://issues.jboss.org/browse/WFCORE-3616 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor The suspend-state attribute def says the attribute is required, but if the SuspendController service is not up it returns undefined. This can primarily happen if the value is read while the server is shutting down, e.g. https://ci.wildfly.org/viewLog.html?buildId=90460&buildTypeId=WildFlyCore... Since we have graceful startup implemented, I think SUSPENDED is a correct value if the suspend controller is not present. If we're booting and the suspend controller isn't installed yet, it's suspended. And once we get to the point in shutdown where the SC is gone, it's last state was SUSPENDED. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7728) Increased Memory footprint in recent builds

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-7728?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-7728: ------------------------------------- [~ctomc] What should the status of the JIRA be? It looks like several PR's have been merged. Is this something that is still being worked on? > Increased Memory footprint in recent builds > ------------------------------------------- > > Key: WFLY-7728 > URL: https://issues.jboss.org/browse/WFLY-7728 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 11.0.0.Alpha1 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Critical > > In our test scenario (see below) memory footprint has been increased between EAP 7.0.0.GA and current EAP 7.1.0.DR7 for more than 8% (~8MB) for Full profile and more than 9% (~6.5MB) for web profile. Could you please comment whether this is intended. > Test scenario: > # Start EAP instance. > # Measure its memory footprint - try to get the lowest possible footprint, that means force garbage collection a few times right before measuring. We enforce GC 10 times. > We see an increase both in heap size (~ 29 vs. 34 MB) and the metaspace size (~ 64 vs. 68 MB) - these numbers are for standalone-full profile. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3590) Hang in ServerStartFailureTestCase

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3590?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3590: ------------------------------------------ A possible other occurrence: https://ci.wildfly.org/viewLog.html?buildId=90452&buildTypeId=WildFlyCore... > Hang in ServerStartFailureTestCase > ---------------------------------- > > Key: WFCORE-3590 > URL: https://issues.jboss.org/browse/WFCORE-3590 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Server > Affects Versions: 4.0.0.Alpha9 > Reporter: Brian Stansberry > Assignee: Richard Opalka > Priority: Critical > Attachments: WFCORE-3590-threads.txt > > > Hang observed in https://ci.wildfly.org/viewLog.html?buildId=88611&buildTypeId=WildFlyCore... > I'll attach the thread dump. > [~dmlloyd] I assigned this to you mostly as a form of ping, as I want to talk to you about it and you are away today. > Interesting parts of the thread dump: > {code} > "Thread-2" #11 prio=5 os_prio=0 tid=0xe13f0400 nid=0x4c49 waiting on condition [0xde4ed000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xe5ea9de8> (a java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at org.jboss.as.server.BootstrapImpl$ShutdownHook.shutdown(BootstrapImpl.java:276) > at org.jboss.as.server.BootstrapImpl$ShutdownHook.run(BootstrapImpl.java:240) > "Controller Boot Thread" #25 prio=5 os_prio=0 tid=0xe0ca4c00 nid=0x4c35 waiting for monitor entry [0xdf3fe000] > java.lang.Thread.State: BLOCKED (on object monitor) > at java.lang.Shutdown.exit(Shutdown.java:212) > - waiting to lock <0xe31d5e18> (a java.lang.Class for java.lang.Shutdown) > at java.lang.Runtime.exit(Runtime.java:109) > at java.lang.System.exit(System.java:971) > at org.jboss.as.server.SystemExiter$DefaultExiter.exit(SystemExiter.java:117) > at org.jboss.as.server.SystemExiter.logAndExit(SystemExiter.java:98) > at org.jboss.as.server.ServerService.boot(ServerService.java:405) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:370) > at java.lang.Thread.run(Thread.java:748) > "MSC service thread 1-8" #20 prio=5 os_prio=0 tid=0x087b8c00 nid=0x4c2f in Object.wait() [0xe03ba000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0xe32a3f28> (a org.jboss.msc.service.ServiceRegistrationImpl) > at java.lang.Object.wait(Object.java:502) > at org.jboss.msc.service.Lockable.acquireWrite(Lockable.java:97) > at org.jboss.msc.service.ServiceControllerImpl$RemoveTask.execute(ServiceControllerImpl.java:1865) > - locked <0xe32a3f28> (a org.jboss.msc.service.ServiceRegistrationImpl) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1527) > at org.jboss.msc.service.ServiceControllerImpl.doExecute(ServiceControllerImpl.java:788) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1537) > at org.jboss.msc.service.ServiceControllerImpl.doExecute(ServiceControllerImpl.java:788) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1537) > at org.jboss.msc.service.ServiceControllerImpl.doExecute(ServiceControllerImpl.java:788) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1537) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374) > at java.lang.Thread.run(Thread.java:748) > "main" #1 prio=5 os_prio=0 tid=0xf6509000 nid=0x4c02 in Object.wait() [0xf6685000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0xe32b58e8> (a org.jboss.as.server.BootstrapImpl$ShutdownHook) > at java.lang.Thread.join(Thread.java:1252) > - locked <0xe32b58e8> (a org.jboss.as.server.BootstrapImpl$ShutdownHook) > at java.lang.Thread.join(Thread.java:1326) > at java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:106) > at java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:46) > at java.lang.Shutdown.runHooks(Shutdown.java:123) > at java.lang.Shutdown.sequence(Shutdown.java:167) > at java.lang.Shutdown.exit(Shutdown.java:212) > - locked <0xe31d5e18> (a java.lang.Class for java.lang.Shutdown) > at java.lang.Runtime.exit(Runtime.java:109) > at java.lang.System.exit(System.java:971) > at org.jboss.as.server.SystemExiter$DefaultExiter.exit(SystemExiter.java:117) > at org.jboss.as.server.SystemExiter.logAndExit(SystemExiter.java:98) > at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:183) > at java.lang.invoke.LambdaForm$DMH/7468253.invokeStatic_L_V(LambdaForm$DMH) > at java.lang.invoke.LambdaForm$MH/7742980.invokeExact_MT(LambdaForm$MH) > at org.jboss.modules.Module.runMainMethod(Module.java:348) > at org.jboss.modules.Module.run(Module.java:328) > at org.jboss.modules.Main.main(Main.java:557) > {code} > This is a domain server. The "main" thread has recognized that its ProcessController has closed its stdin, so it is shutting down via System.exit. > "Thread-2" is running BootstrapImpl.ShutdownHook, waiting on a latch for the MSC ServiceContainer to complete termination. So the SC not completing termination is the basic issue. > "Controller Boot Thread" is there because this termination occurred during boot. That caused some problem during boot (not surprising) so it is responding to that problem by trying to terminate the process, via System.exit. It's blocking waiting for "main" which has done the same. This thread should not be preventing MSC terminating though; it's not, for example called as part of a StartContext.asynchronous thing. IOW I don't think this thread is relevant to the problem. > "MSC service thread 1-8" is the most interesting one to me. An MSC thread is blocked but it's not clear to me why. An interesting frame in the stack is org.jboss.msc.service.ServiceControllerImpl.doExecute(ServiceControllerImpl.java:788). That shows that ServiceControllerImpl$RemoveTask was passed to the executor but a RejectedExecutionException was thrown, so the task is being run from the thread that attempted to pass it to the executor. Should the MSC executor be rejecting tasks before all service controllers are removed? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-12) Test IBM Istio Resilient as option to Service Mesh

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-12?page=com.atlassian.jira.plugin.s... ] Guilherme Baufaker Rêgo commented on SWSQE-12: ---------------------------------------------- It worked on minikube locally. > Test IBM Istio Resilient as option to Service Mesh > -------------------------------------------------- > > Key: SWSQE-12 > URL: https://issues.jboss.org/browse/SWSQE-12 > Project: Swift Sunshine QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > > https://github.com/IBM/resilient-java-microservices-with-istio -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-21) Openshift Source-2-Image Pipeline for Test Suites

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-21?page=com.atlassian.jira.plugin.s... ] Matt Mahoney commented on SWSQE-21: ----------------------------------- Correct in that the UI automation framework has yet to be determined. > Openshift Source-2-Image Pipeline for Test Suites > ------------------------------------------------- > > Key: SWSQE-21 > URL: https://issues.jboss.org/browse/SWSQE-21 > Project: Swift Sunshine QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: viet nguyen > > Configure an Openshift Source-to-Image pipline for QE test suites. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-21) Openshift Source-2-Image Pipeline for Test Suites

by viet nguyen (JIRA)

[ https://issues.jboss.org/browse/SWSQE-21?page=com.atlassian.jira.plugin.s... ] viet nguyen commented on SWSQE-21: ---------------------------------- True. But we still haven't settled on Python or Go for UI automation, no? The react-ui test is node.js so not a problem there. Either case I propose that we templatize our automation and run it in OpenShift > Openshift Source-2-Image Pipeline for Test Suites > ------------------------------------------------- > > Key: SWSQE-21 > URL: https://issues.jboss.org/browse/SWSQE-21 > Project: Swift Sunshine QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: viet nguyen > > Configure an Openshift Source-to-Image pipline for QE test suites. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9847) Create subsystem for configuring distributed discovery

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-9847: ---------------------------------- Summary: Create subsystem for configuring distributed discovery Key: WFLY-9847 URL: https://issues.jboss.org/browse/WFLY-9847 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 12.0.0.Beta1 Reporter: Paul Ferraro Assignee: Paul Ferraro Subsystem will expose 2 resources: # /subsystem=distributed-discovery/distributed-discovery-provider=* A CommandDispatcher-based DiscoveryProvider that references a local discovery provider. This resource will contain at least the following properties: * channel : a capability reference to a CommandDispatcherFactory * local-provider : a capability reference to a DiscoveryProvider # /subsystem=distributed-discovery/distributed-discovery-registry=* A ServiceProviderRegistry-based DiscoveryProvider and RegistryProvider. This resource will contain at least the following properties: * cache-container : a capability reference to a default ServiceProviderRegistry * cache : a capability reference to a ServiceProviderRegistry -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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 February 2018