[JBoss JIRA] (WFCORE-1080) Remove compile time dep from cli module to process-controller
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1080?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-1080:
-----------------------------------
[~bstansberry] Oops, sorry about that, I should have realized.
> Remove compile time dep from cli module to process-controller
> -------------------------------------------------------------
>
> Key: WFCORE-1080
> URL: https://issues.jboss.org/browse/WFCORE-1080
> Project: WildFly Core
> Issue Type: Task
> Components: CLI
> Affects Versions: 2.0.0.CR8
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.CR9
>
>
> EmbedHostControllerHandler is importing CommandLineConstants from the process-controller module in order to pick up a couple string constants. I want to eliminate this link from the client side modules to the server side modules.
> Plus the same strings are directly included in the class elsewhere. ;)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1080) Remove compile time dep from cli module to process-controller
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1080?page=com.atlassian.jira.plugi... ]
Ken Wills edited comment on WFCORE-1080 at 10/27/15 6:17 PM:
-------------------------------------------------------------
[~bstansberry] Oops, sorry about that, I should have realized, that does explain the direct usage in a lot of cases vs the use of constants though :)
was (Author: luck3y):
[~bstansberry] Oops, sorry about that, I should have realized.
> Remove compile time dep from cli module to process-controller
> -------------------------------------------------------------
>
> Key: WFCORE-1080
> URL: https://issues.jboss.org/browse/WFCORE-1080
> Project: WildFly Core
> Issue Type: Task
> Components: CLI
> Affects Versions: 2.0.0.CR8
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.CR9
>
>
> EmbedHostControllerHandler is importing CommandLineConstants from the process-controller module in order to pick up a couple string constants. I want to eliminate this link from the client side modules to the server side modules.
> Plus the same strings are directly included in the class elsewhere. ;)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1080) Remove compile time dep from cli module to process-controller
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1080:
----------------------------------------
Summary: Remove compile time dep from cli module to process-controller
Key: WFCORE-1080
URL: https://issues.jboss.org/browse/WFCORE-1080
Project: WildFly Core
Issue Type: Task
Components: CLI
Affects Versions: 2.0.0.CR8
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 2.0.0.CR9
EmbedHostControllerHandler is importing CommandLineConstants from the process-controller module in order to pick up a couple string constants. I want to eliminate this link from the client side modules to the server side modules.
Plus the same strings are directly included in the class elsewhere. ;)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-938) Embedded host controller doesn't support --admin-mode=false option
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-938?page=com.atlassian.jira.plugin... ]
Ken Wills edited comment on WFCORE-938 at 10/27/15 5:11 PM:
------------------------------------------------------------
Embedded HC is forced into admin-only = true now, also see ReloadHandler.doHandleEmbedded for ensuring that this is preserved through reloads until we support this feature.
was (Author: luck3y):
Embedded HC is forced into admin-only = true now, also see ReloadHandler.buildRequestWithoutHeaders for ensuring that this is preserver through reloads.
> Embedded host controller doesn't support --admin-mode=false option
> ------------------------------------------------------------------
>
> Key: WFCORE-938
> URL: https://issues.jboss.org/browse/WFCORE-938
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: Ken Wills
>
> Embedded standalone instance supports two running modes depending on a value of admin-only option (true is default).
> * *true*
> ** only start services related to server administration
> ** do not start other services or accept end user requests.
> ** embedded instance will not be visible to remote management clients
> * *false*
> ** all services are started
> ** embedded instance is visible to remote management clients (e.g. EAP can be configured via admin console)
> Embedded host controller doesn't offer such a option and is started using --admin-only=true mode by default. Option to run embedded host controller instance with --admin-only=false should be available as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-938) Embedded host controller doesn't support --admin-mode=false option
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-938?page=com.atlassian.jira.plugin... ]
Ken Wills commented on WFCORE-938:
----------------------------------
Embedded HC is forced into admin-only = true now, also see ReloadHandler.buildRequestWithoutHeaders for ensuring that this is preserver through reloads.
> Embedded host controller doesn't support --admin-mode=false option
> ------------------------------------------------------------------
>
> Key: WFCORE-938
> URL: https://issues.jboss.org/browse/WFCORE-938
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: Ken Wills
>
> Embedded standalone instance supports two running modes depending on a value of admin-only option (true is default).
> * *true*
> ** only start services related to server administration
> ** do not start other services or accept end user requests.
> ** embedded instance will not be visible to remote management clients
> * *false*
> ** all services are started
> ** embedded instance is visible to remote management clients (e.g. EAP can be configured via admin console)
> Embedded host controller doesn't offer such a option and is started using --admin-only=true mode by default. Option to run embedded host controller instance with --admin-only=false should be available as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1079) Revert dependency on wildfly-common added to the protocol module
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1079:
----------------------------------------
Summary: Revert dependency on wildfly-common added to the protocol module
Key: WFCORE-1079
URL: https://issues.jboss.org/browse/WFCORE-1079
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Affects Versions: 2.0.0.CR8
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 2.0.0.CR9
https://github.com/wildfly/wildfly-core/commit/053d68a5 introduced a dependency of the 'protocol' module on wildfly-common. The 'protocol' module is a dep of 'controller-client' so this means wildfly-common now becomes a dep of anyone wanting to use ModelControllerClient.
I want to remove that dep, as the gains from bringing it in are really tiny; just a slightly more accurate initial sizing param for a couple of maps.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5011) OutdatedTopologyException: Cache not running on node <node_name>
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5011?page=com.atlassian.jira.plugin.... ]
Paul Ferraro resolved WFLY-5011.
--------------------------------
Fix Version/s: 10.0.0.CR3
Resolution: Done
Resolved by https://github.com/wildfly/wildfly/commit/25e62d6c854fb567aa743f3828ef34b...
> OutdatedTopologyException: Cache not running on node <node_name>
> ----------------------------------------------------------------
>
> Key: WFLY-5011
> URL: https://issues.jboss.org/browse/WFLY-5011
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Alpha6, 10.0.0.Beta1, 10.0.0.CR2
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 10.0.0.CR3
>
>
> Seen in our HTTP-based failover tests (no matter what failover type: jvmkill/shutdown/undeploy), with *distributed* cache used.
> Doe not occur when replicated cache is used.
> Setup: 4 node cluster, one node at time is shutdown, while standalone clients keep calling the application.
> After failing one node(failover type: jvmkill/shutdown/undeploy) - perf18 for example, perf19,20,21 log the following error message many times (seems like one error per each session)
> {code}
> [JBossINF] [0m[31m05:48:40,646 ERROR [io.undertow.request] (default task-110) UT005023: Exception handling request to /clusterbench/session: org.infinispan.statetransfer.OutdatedTopologyException: Cache not running on node perf18
> [JBossINF] at org.infinispan.interceptors.distribution.TxDistributionInterceptor.checkTxCommandResponses(TxDistributionInterceptor.java:274)
> [JBossINF] at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitLockControlCommand(TxDistributionInterceptor.java:186)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.acquireRemoteIfNeeded(PessimisticLockingInterceptor.java:238)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:66)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:70)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:346)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:318)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:364)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:349)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitDataReadCommand(CacheMgmtInterceptor.java:103)
> [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:91)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:430)
> [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:427)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:287)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:120)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:232)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:116)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:725)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:367)
> [JBossINF] at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:231)
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:281)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1074) Intermittent failure in DeploymentScannerUnitTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1074?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-1074 at 10/27/15 3:14 PM:
--------------------------------------------------------------------
Emmanuel and I were chatting, so this is a follow up to his last comment based on our chat.
1) If an app tries to deploy and deployment doesn't go well due to some service problems, but rollback-on-runtime-failure=false is set, that app is still "deployed" in the management sense. The 'enabled' attribute will be set to 'true' in the model, and MSC will have a bunch of services installed related to the app. It just won't be functioning properly. So, sending a "deployed" notification is valid.
2) The notifications really are only relevant for cases like WFCORE-860 where the end user is directly using CLI/console to tweak the state of a scanner controlled deployment. There the scanner needs notifications to be aware of user-initiated changes. But the scanner has logic to ignore notifications emitted as a result of its *own* activity. Perhaps there is a bug there, but the logic to ignore definitely exists.
was (Author: brian.stansberry):
Emanuel and I were chatting, so this is a follow up to his last comment based on our chat.
1) If an app tries to deploy and deployment doesn't go well due to some service problems, but rollback-on-runtime-failure=false is set, that app is still "deployed" in the management sense. The 'enabled' attribute will be set to 'true' in the model, and MSC will have a bunch of services installed related to the app. It just won't be functioning properly. So, sending a "deployed" notification is valid.
2) The notifications really are only relevant for cases like WFCORE-860 where the end user is directly using CLI/console to tweak the state of a scanner controlled deployment. There the scanner needs notifications to be aware of user-initiated changes. But the scanner has logic to ignore notifications emitted as a result of its *own* activity. Perhaps there is a bug there, but the logic to ignore definitely exists.
> Intermittent failure in DeploymentScannerUnitTestCase
> -----------------------------------------------------
>
> Key: WFCORE-1074
> URL: https://issues.jboss.org/browse/WFCORE-1074
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha1
>
>
> DeploymentScannerUnitTestCase occasionally fails, 4 times in the last six weeks or so per Team City records:
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WildFlyCore&...
> May not be relevant but the change log associated with the first failure shows WFCORE-903 / WFCORE-860 as part of the change set:
>
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=70465&tab=buil...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1074) Intermittent failure in DeploymentScannerUnitTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1074?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1074:
------------------------------------------
Emanuel and I were chatting, so this is a follow up to his last comment based on our chat.
1) If an app tries to deploy and deployment doesn't go well due to some service problems, but rollback-on-runtime-failure=false is set, that app is still "deployed" in the management sense. The 'enabled' attribute will be set to 'true' in the model, and MSC will have a bunch of services installed related to the app. It just won't be functioning properly. So, sending a "deployed" notification is valid.
2) The notifications really are only relevant for cases like WFCORE-860 where the end user is directly using CLI/console to tweak the state of a scanner controlled deployment. There the scanner needs notifications to be aware of user-initiated changes. But the scanner has logic to ignore notifications emitted as a result of its *own* activity. Perhaps there is a bug there, but the logic to ignore definitely exists.
> Intermittent failure in DeploymentScannerUnitTestCase
> -----------------------------------------------------
>
> Key: WFCORE-1074
> URL: https://issues.jboss.org/browse/WFCORE-1074
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha1
>
>
> DeploymentScannerUnitTestCase occasionally fails, 4 times in the last six weeks or so per Team City records:
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WildFlyCore&...
> May not be relevant but the change log associated with the first failure shows WFCORE-903 / WFCORE-860 as part of the change set:
>
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=70465&tab=buil...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months