[JBoss JIRA] (WFLY-8713) ISPN000136: Error executing command PutKeyValueCommand, writing keys
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-8713?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-8713:
--------------------------------------
Component/s: Clustering
Assignee: Paul Ferraro (was: Jason Greene)
> ISPN000136: Error executing command PutKeyValueCommand, writing keys
> --------------------------------------------------------------------
>
> Key: WFLY-8713
> URL: https://issues.jboss.org/browse/WFLY-8713
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Environment: Linux
> Reporter: Divey Gupta
> Assignee: Paul Ferraro
> Priority: Major
>
> We have a cluster of 6 wildfly all running 10.0.0. There was a network blip for few minutes so the connectivity between the members of the cluster got affected.
> After that one of the members started throwing the following error on login.
> ERROR [InvocationContextInterceptor] (default task-51) ISPN000136: Error executing command PutKeyValueCommand, writing keys [SessionCreationMetaDataKey(k1XmyfLfE8KInACteyuTXQLCki9jq-HKL2-Ayo6G)]: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 27
> at org.infinispan.statetransfer.StateTransferLockImpl.reportErrorAfterWait(StateTransferLockImpl.java:159) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.statetransfer.StateTransferLockImpl.waitForTransactionData(StateTransferLockImpl.java:98) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.base.BaseStateTransferInterceptor.waitForTransactionData(BaseStateTransferInterceptor.java:97) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:366) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:281) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:107) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:43) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:43) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1672) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.cache.impl.CacheImpl.putIfAbsentInternal(CacheImpl.java:1163) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.cache.impl.CacheImpl.putIfAbsent(CacheImpl.java:1151) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.cache.impl.DecoratedCache.putIfAbsent(DecoratedCache.java:508) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.cache.impl.AbstractDelegatingCache.putIfAbsent(AbstractDelegatingCache.java:246) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:325) [rt.jar:1.8.0_72]
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.createValue(InfinispanSessionMetaDataFactory.java:53)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.createValue(InfinispanSessionMetaDataFactory.java:36)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.createValue(InfinispanSessionFactory.java:52)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.createValue(InfinispanSessionFactory.java:38)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.createSession(InfinispanSessionManager.java:257)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.createSession(DistributableSessionManager.java:110)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:787) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:802) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler$SecurityNotificationReceiver.handleNotification(CachedAuthenticatedSessionHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.AbstractSecurityContext.sendNoticiation(AbstractSecurityContext.java:131) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:88) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:80) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.FormAuthenticationMechanism.runFormAuth(FormAuthenticationMechanism.java:126) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.FormAuthenticationMechanism.authenticate(FormAuthenticationMechanism.java:96) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:263) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_72]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_72]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_72]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-3492) Create UX proposal to show/edit Test Scenario (Preview) global setting
by tao zhu (Jira)
[ https://issues.jboss.org/browse/DROOLS-3492?page=com.atlassian.jira.plugi... ]
tao zhu commented on DROOLS-3492:
---------------------------------
Hi [~danielezonca][~kkufova] Updated the icon list. https://redhat.invisionapp.com/share/UAPZ5CDKMNH
I have a small suggestion about “Test Tools” should be the selected tab in the default status when user first comes to this page. It could help user to edit the table information quickly.
> Create UX proposal to show/edit Test Scenario (Preview) global setting
> ----------------------------------------------------------------------
>
> Key: DROOLS-3492
> URL: https://issues.jboss.org/browse/DROOLS-3492
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: tao zhu
> Priority: Major
> Labels: ScenarioSimulation, UXD, UXTeam
> Attachments: 11unnamed.png, TestScenario_Cheatsheet.png, TestScenario_TestEditor.png, TestScenario_TestReport.png, TestScenario_whole.png, test-report-icon.png, 屏幕快照 2019-01-22 下午4.44.04.png, 屏幕快照 2019-01-23 下午4.08.30.png, 屏幕快照 2019-01-23 下午4.08.30.png
>
>
> As user I want to be able to see/edit editor global settings.
> For instance DMN file linked to the scenario or the Session name of a Rule scenario
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-10319) NameBinding annotations on resources are ignored in subresources
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-10319?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-10319:
------------------------------------
Component/s: REST
> NameBinding annotations on resources are ignored in subresources
> ----------------------------------------------------------------
>
> Key: WFLY-10319
> URL: https://issues.jboss.org/browse/WFLY-10319
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 12.0.0.Final
> Reporter: Javier Estevez Sanchez
> Assignee: Jason Greene
> Priority: Major
>
> The following JAX-RS resource exposes two resources via a GET operation: /demo and /demo/subresource. The first one via a sub-resource method, the latter via a sub-resource locator. Additionally, a response filter is binded to the JAX-RS resource class to modify the response. From the JAX-RS 2.0 spec, §6.5.2 Name Binding:
> {quote}
> Binding annotations that decorate resource classes apply to all resource methods defined in them.
> {quote}
> However, the binding annotation is not applying to the sub-resource locator method. This happens when the name binding annotation is on the resource class or on the sub-resource locator method. Annotating the sub-resource class or the method within works as expected, though.
> Below is the code needed to reproduce this issue:
> {code:java|title=The resource and subresource}
> @DemoNameBinding
> @Produces(MediaType.APPLICATION_JSON)
> @Path("/demo")
> public class DemoResource {
> @GET
> public String getDemoValue() {
> return "A value";
> }
> @Path("/subresource")
> public DemoSubResource getSubResource() {
> return new DemoSubResource();
> }
> public class DemoSubResource {
> @GET
> public String getDemoValue() {
> return "A value";
> }
> }
> }
> {code}
> {code:java|title=The filter}
> @Provider
> @DemoNameBinding
> public class SomeFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) {
> responseContext.setEntity("A filtered value");
> }
> }
> {code}
> {code:java|title=The binding}
> @NameBinding
> @Target({ElementType.TYPE, ElementType.METHOD})
> @Retention(RetentionPolicy.RUNTIME)
> public @interface DemoNameBinding {
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-10319) NameBinding annotations on resources are ignored in subresources
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-10319?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-10319:
---------------------------------------
Assignee: Alessio Soldano (was: Jason Greene)
> NameBinding annotations on resources are ignored in subresources
> ----------------------------------------------------------------
>
> Key: WFLY-10319
> URL: https://issues.jboss.org/browse/WFLY-10319
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 12.0.0.Final
> Reporter: Javier Estevez Sanchez
> Assignee: Alessio Soldano
> Priority: Major
>
> The following JAX-RS resource exposes two resources via a GET operation: /demo and /demo/subresource. The first one via a sub-resource method, the latter via a sub-resource locator. Additionally, a response filter is binded to the JAX-RS resource class to modify the response. From the JAX-RS 2.0 spec, §6.5.2 Name Binding:
> {quote}
> Binding annotations that decorate resource classes apply to all resource methods defined in them.
> {quote}
> However, the binding annotation is not applying to the sub-resource locator method. This happens when the name binding annotation is on the resource class or on the sub-resource locator method. Annotating the sub-resource class or the method within works as expected, though.
> Below is the code needed to reproduce this issue:
> {code:java|title=The resource and subresource}
> @DemoNameBinding
> @Produces(MediaType.APPLICATION_JSON)
> @Path("/demo")
> public class DemoResource {
> @GET
> public String getDemoValue() {
> return "A value";
> }
> @Path("/subresource")
> public DemoSubResource getSubResource() {
> return new DemoSubResource();
> }
> public class DemoSubResource {
> @GET
> public String getDemoValue() {
> return "A value";
> }
> }
> }
> {code}
> {code:java|title=The filter}
> @Provider
> @DemoNameBinding
> public class SomeFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) {
> responseContext.setEntity("A filtered value");
> }
> }
> {code}
> {code:java|title=The binding}
> @NameBinding
> @Target({ElementType.TYPE, ElementType.METHOD})
> @Retention(RetentionPolicy.RUNTIME)
> public @interface DemoNameBinding {
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFCORE-4292) Deployment order based on jboss-all.xml doesn't work properly
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4292?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-4292:
------------------------------------------
The WFCORE-4292 scenario sounds a lot like the WFCORE-4291 scenario (deployments in the same server calling each other during boot) and I suspect 4292 is not a bug, it's the same RFE as 4291.
> Deployment order based on jboss-all.xml doesn't work properly
> -------------------------------------------------------------
>
> Key: WFCORE-4292
> URL: https://issues.jboss.org/browse/WFCORE-4292
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Panos Mitronikas
> Priority: Major
>
> Our application consists of a core module (ear or war) and several component modules (wars) that register to the core upon deployment.
> The process is implemented with a REST service available in the core module and REST clients in each component that call a register method upon deployment and an unregister upon removal. This requires a deployment order for server restarts and it is implemented with jboss-all.xml files in each component war.
> The process was smooth on Wildfly 10 but on 12 restarts seem not to follow the deployment order, or for being exact it appears that the core REST service doesn't get initialized properly and clients just hang there waiting, resulting in a total crash of the server upon initialization (never goes up and crashes with some concurrency error after 5 minutes).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFCORE-4292) Deployment order based on jboss-all.xml doesn't work properly
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4292?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-10344 to WFCORE-4292:
-------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-4292 (was: WFLY-10344)
Affects Version/s: (was: 12.0.0.Final)
> Deployment order based on jboss-all.xml doesn't work properly
> -------------------------------------------------------------
>
> Key: WFCORE-4292
> URL: https://issues.jboss.org/browse/WFCORE-4292
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Panos Mitronikas
> Assignee: Jason Greene
> Priority: Major
>
> Our application consists of a core module (ear or war) and several component modules (wars) that register to the core upon deployment.
> The process is implemented with a REST service available in the core module and REST clients in each component that call a register method upon deployment and an unregister upon removal. This requires a deployment order for server restarts and it is implemented with jboss-all.xml files in each component war.
> The process was smooth on Wildfly 10 but on 12 restarts seem not to follow the deployment order, or for being exact it appears that the core REST service doesn't get initialized properly and clients just hang there waiting, resulting in a total crash of the server upon initialization (never goes up and crashes with some concurrency error after 5 minutes).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFCORE-4292) Deployment order based on jboss-all.xml doesn't work properly
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4292?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-4292:
----------------------------------------
Assignee: (was: Jason Greene)
> Deployment order based on jboss-all.xml doesn't work properly
> -------------------------------------------------------------
>
> Key: WFCORE-4292
> URL: https://issues.jboss.org/browse/WFCORE-4292
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Panos Mitronikas
> Priority: Major
>
> Our application consists of a core module (ear or war) and several component modules (wars) that register to the core upon deployment.
> The process is implemented with a REST service available in the core module and REST clients in each component that call a register method upon deployment and an unregister upon removal. This requires a deployment order for server restarts and it is implemented with jboss-all.xml files in each component war.
> The process was smooth on Wildfly 10 but on 12 restarts seem not to follow the deployment order, or for being exact it appears that the core REST service doesn't get initialized properly and clients just hang there waiting, resulting in a total crash of the server upon initialization (never goes up and crashes with some concurrency error after 5 minutes).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-10315) Restore legacy (not "graceful") startup mode
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-10315?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-10315:
------------------------------------
Component/s: Management
> Restore legacy (not "graceful") startup mode
> --------------------------------------------
>
> Key: WFLY-10315
> URL: https://issues.jboss.org/browse/WFLY-10315
> Project: WildFly
> Issue Type: Feature Request
> Components: Management
> Reporter: Vladimir Grabarchuk
> Assignee: Jason Greene
> Priority: Major
>
> Please allow a configurable legacy startup mode which was the default before WF11, when components can service HTTP requests as soon as they are deployed, not when the container deploys all components.
> The use case for this is the following: there is a configuration service component upon which other components depend for configuration data, requested and served via a HTTP request. With the new "graceful startup" this scenario no longer seems possible, as it results in read timeouts, mis-configured artifacts, and failed deployments altogether.
> If generally feasible, another value of the *--start-mode=legacy* seems appropriate to accommodate the original (legacy) behavior.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months