March 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9999) Upgrade mod_cluster to 1.3.9.Final

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9999?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9999: --------------------------------- Summary: Upgrade mod_cluster to 1.3.9.Final (was: Update mod_cluster to 1.3.9.Final) > Upgrade mod_cluster to 1.3.9.Final > ---------------------------------- > > Key: WFLY-9999 > URL: https://issues.jboss.org/browse/WFLY-9999 > Project: WildFly > Issue Type: Component Upgrade > Components: mod_cluster > Affects Versions: 12.0.0.Final > Reporter: Panagiotis Sotiropoulos > Assignee: Radoslav Husar > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10007) Module org.infinispan.cachestore.remote was dropped

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-10007?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-10007: ----------------------------------------- [~luck3y] [~pferraro] FYI. We can perhaps come up with something better or maybe this doesn't even work (Ken's testing on OpenShift shows it does at least somewhat), but I wanted to get at least an interim solution up. Same problem may apply to the cachestore.jbdc module for some other LP, but we haven't hit such a case. > Module org.infinispan.cachestore.remote was dropped > --------------------------------------------------- > > Key: WFLY-10007 > URL: https://issues.jboss.org/browse/WFLY-10007 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 12.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 13.0.0.Beta1 > > > The org.infinispan.cachestore.remote module was renamed to org.infinispan.persistence.remote as part of WFLY-8207 but the Keycloak adapters that integrate into WF depend on that module. So, proposal is to add an alias module. > The module was private but projects/products that layer on top of WF/EAP legitimately use private modules. Also, this isn't really a layer, it's an adapter to allow us to integrate with an external server, so we somewhat broke ourselves. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10007) Module org.infinispan.cachestore.remote was dropped

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-10007: --------------------------------------- Summary: Module org.infinispan.cachestore.remote was dropped Key: WFLY-10007 URL: https://issues.jboss.org/browse/WFLY-10007 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 12.0.0.Final Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 13.0.0.Beta1 The org.infinispan.cachestore.remote module was renamed to org.infinispan.persistence.remote as part of WFLY-8207 but the Keycloak adapters that integrate into WF depend on that module. So, proposal is to add an alias module. The module was private but projects/products that layer on top of WF/EAP legitimately use private modules. Also, this isn't really a layer, it's an adapter to allow us to integrate with an external server, so we somewhat broke ourselves. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10006) Upgrade Hibernate ORM from 5.1.10 to 5.1.13

by Gail Badner (JIRA)

Gail Badner created WFLY-10006: ---------------------------------- Summary: Upgrade Hibernate ORM from 5.1.10 to 5.1.13 Key: WFLY-10006 URL: https://issues.jboss.org/browse/WFLY-10006 Project: WildFly Issue Type: Component Upgrade Components: JPA / Hibernate Reporter: Gail Badner Assignee: Gail Badner -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-59) [QE] - SWS-234 - Add support to Istio objects

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/SWSQE-59?page=com.atlassian.jira.plugin.s... ] Hayk Hovsepyan reassigned SWSQE-59: ----------------------------------- Assignee: Hayk Hovsepyan (was: Michael Foley) > [QE] - SWS-234 - Add support to Istio objects > --------------------------------------------- > > Key: SWSQE-59 > URL: https://issues.jboss.org/browse/SWSQE-59 > Project: Swift Sunshine QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > > Take a look into subtasks of this story, they can be done before main story is done. > https://issues.jboss.org/browse/SWS-234 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1953) Elytron allow-resource-service-restart=true handling

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1953?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1953: ------------------------------------------ [~mchoma] Sorry for the delay; I've been traveling. Using "allow-resource-service-restart=true" is essentially a "custom service restart". The handler for the op sees that header and therefore is willing to stop/start a service. It's custom because each handler separately decides whether to have this behavior. There's no way to restart just one service and not affect others, i.e. have custom behavior for service start/stop itself. It's fundamental to MSC that a service is either up or it is down, and it can't be up unless all its dependencies are up. Therefore stopping service X means all dependencies must be stopped first. I don't see that changing. It's perfectly valid for a service to change its internal state without stopping/starting. That of course isn't always easy, or correct. I haven't dug into the details of this key-manager issue; I assume the folks looking into the issue have considered that. > Elytron allow-resource-service-restart=true handling > ---------------------------------------------------- > > Key: WFCORE-1953 > URL: https://issues.jboss.org/browse/WFCORE-1953 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha11 > Reporter: Martin Choma > > Elytron can not handle {{allow-resource-service-restart=true}} header properly on many places. > For example if I try to update http-authentication-factory with {{allow-resource-service-restart=true}} header, I get > {code} > [standalone@localhost:9990 /] /subsystem=elytron/http-authentication-factory=application-http-authentication:write-attribute(name=http-server-mechanism-factory, value=global){allow-resource-service-restart=true} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.UnsupportedOperationException", > "rolled-back" => true > } > {code} > And exception in server log > {code:title=server.log} > 11:22:20,312 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("write-attribute") failed - address: ([ > ("subsystem" => "elytron"), > ("http-authentication-factory" => "application-http-authentication") > ]): java.lang.UnsupportedOperationException > at org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:145) > at org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:126) > at org.jboss.as.controller.RestartParentWriteAttributeHandler.applyUpdateToRuntime(RestartParentWriteAttributeHandler.java:72) > at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Similar behaviour can be seen in: > * {{kerberos-security-factory}} > * {{filesystem-realm}} > * {{constant-principal-decoder}} > On the other hand I don't see this issue in {{security-domain}} > Possible solutions: > * restart services > ** possibility of reload big part of server anyway; either management part or application part > * live updates > ** if resource would accept runtime updates resource won't need to reload > ** most user friendly, most work > ** tracked as own issue JBEAP-6961 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-61) [QE] - SWS-12 - See deployments information

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created SWSQE-61: ----------------------------------- Summary: [QE] - SWS-12 - See deployments information Key: SWSQE-61 URL: https://issues.jboss.org/browse/SWSQE-61 Project: Swift Sunshine QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Michael Foley Pay attention into subtasks of user story: https://issues.jboss.org/browse/SWS-12 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-57) [QE] - SWS-170 - Embedded Jaeger UI

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/SWSQE-57?page=com.atlassian.jira.plugin.s... ] Hayk Hovsepyan updated SWSQE-57: -------------------------------- Team: Jupiter (was: Jupiter) Sprint: SWS QE Sprint 2 > [QE] - SWS-170 - Embedded Jaeger UI > ----------------------------------- > > Key: SWSQE-57 > URL: https://issues.jboss.org/browse/SWSQE-57 > Project: Swift Sunshine QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Michael Foley > > Look into Dev Task/Story https://issues.jboss.org/browse/SWS-170 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3680) WFLYJMX0037 occurs with RBAC enabled when disconnecting JConsole

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3680?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-10001 to WFCORE-3680: ------------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-3680 (was: WFLY-10001) Component/s: JMX Remoting Security (was: JMX) (was: Remoting) (was: Security) > WFLYJMX0037 occurs with RBAC enabled when disconnecting JConsole > ---------------------------------------------------------------- > > Key: WFCORE-3680 > URL: https://issues.jboss.org/browse/WFCORE-3680 > Project: WildFly Core > Issue Type: Bug > Components: JMX, Remoting, Security > Reporter: Bartosz Baranowski > Assignee: Brian Stansberry > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9982) Sometimes BootstrapImpl$ShutdownHook does not finish and holds server shutdown

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9982?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-9982: ---------------------------------------- This is the same thread dump pattern as WFCORE-3590, which is marked as resolved for WF Core 4.0.0.Beta2, i.e. it should be fixed in WF 12.0.0.Final. [~ropalka] FYI. [~mnovak], please confirm this was seen with 12.0.0.Final and not some previous build from late in the 12 dev cycle. Thanks! > Sometimes BootstrapImpl$ShutdownHook does not finish and holds server shutdown > ------------------------------------------------------------------------------ > > Key: WFLY-9982 > URL: https://issues.jboss.org/browse/WFLY-9982 > Project: WildFly > Issue Type: Bug > Components: MSC, Server > Affects Versions: 12.0.0.Final > Reporter: Miroslav Novak > Assignee: Jason Greene > Attachments: node-1-thread-dump-when-killed-shutdown-sequence.txt > > > There is intermittent failure where server does not stop and hangs during clean shutdown. > Investigation: > In attached thread dump there is shutdown of WF/EAP JVM thread waiting for finishing org.jboss.as.server.BootstrapImpl$ShutdownHook: > {code} > "Management Triggered Shutdown" #262 prio=5 os_prio=0 tid=0x00007f931c03b800 nid=0x3900 in Object.wait() [0x00007f9296423000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000cf059e98> (a org.jboss.as.server.BootstrapImpl$ShutdownHook) > at java.lang.Thread.join(Thread.java:1252) > - locked <0x00000000cf059e98> (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 <0x00000000cedfac08> (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.operations.ServerShutdownHandler$ShutdownAction$1.run(ServerShutdownHandler.java:184) > at java.lang.Thread.run(Thread.java:748) > {code} > which hangs in: > {code} > "Thread-3" #12 prio=5 os_prio=0 tid=0x00007f92d01dc800 nid=0x3902 waiting on condition [0x00007f9296221000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000fc2531d8> (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) > {code} > where ShutdownHook.shutdown(BootstrapImpl.java:276) is waiting for latch to count down however this does not happen. It seems like that not all services shut down. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 March 2018