7:56 a.m.
Hi everyone,
I would like to outline a brief JBoss MSC Plans for Year 2018.
Goals defined below address both:
* Cloud First Effort
- Reduce WildFly memory footprint
- Speed up WildFly boot time
* Potential Migration to MSC 2
MSC Library Goals:
* SHORT TERM GOALS (MSC 1.2.x, 1.3.x)
[1] simplify MSC state machine - deprecate useless MSC internal states
(e.g. REMOVED, WONT_START, WAITING, REMOVING, STOPPING maybe others)
[2] deprecate API exposing MSC internals
(e.g. replace ServiceListener with LifecycleListener)
[3] deprecate MSC Values, Injections & Injectors and provide alternative
API
(alternative API should have same minimalistic memory requirements
like MSC 2)
* LONG TERM GOALS (MSC 1.4.x)
[4] remove deprecated APIs and all deprecated stuff
WildFly MSC Integration Goals:
+ SHORT TERM GOALS (WildFly 12)
* replace ServiceListeners with LifecycleListeners (LifecycleListeners
don't expose MSC internals)
* eliminate MSC optional dependencies from WildFLy Core
* eliminate MSC Values, Injections & Injectors and migrate to
alternative API
* WildFly Management Layer should not expose MSC APIs as its public API
(complicates potential migration to MSC2 and breaks encapsulation)
+ LONG TERM GOALS (WildFly versions targeting next major EAP)
* eliminate MSC optional dependencies from WildFly (probably via
Capabilities)
(MSC Optional Dependencies have been fixed recently but there's still
performance issue
- in worst case scenario if service A has N optional dependencies
it may happen service A is restarted N times before it is stabilized
in UP state)
Feedback and comments more than welcome!
--
Rio
1:48 a.m.
Hi everyone,
I would like to outline a brief JBoss MSC Plans for Year 2018.
Goals defined below address both:
* Cloud First Effort
- Reduce WildFly memory footprint
- Speed up WildFly boot time
* Potential Migration to MSC 2
MSC Library Goals:
* SHORT TERM GOALS (MSC 1.2.x, 1.3.x)
[1] simplify MSC state machine - deprecate useless MSC internal states
(e.g. REMOVED, WONT_START, WAITING, REMOVING, STOPPING maybe others)
[2] deprecate API exposing MSC internals
(e.g. replace ServiceListener with LifecycleListener)
[3] deprecate MSC Values, Injections & Injectors and provide alternative API
(alternative API should have same minimalistic memory requirements like MSC
2)
* LONG TERM GOALS (MSC 1.4.x)
[4] remove deprecated APIs and all deprecated stuff
Could you map MSC 1.2.x, 1.3.x and 1.4.x to planned WF 12/13/14/15 releases ?
Especially interested in MSC 1.4.x due to removal of deprecated stuff.
Thank you.
Rostislav
WildFly MSC Integration Goals:
+ SHORT TERM GOALS (WildFly 12)
* replace ServiceListeners with LifecycleListeners (LifecycleListeners don't
expose MSC internals)
* eliminate MSC optional dependencies from WildFLy Core
* eliminate MSC Values, Injections & Injectors and migrate to alternative API
* WildFly Management Layer should not expose MSC APIs as its public API
(complicates potential migration to MSC2 and breaks encapsulation)
+ LONG TERM GOALS (WildFly versions targeting next major EAP)
* eliminate MSC optional dependencies from WildFly (probably via
Capabilities)
(MSC Optional Dependencies have been fixed recently but there's still
performance issue
- in worst case scenario if service A has N optional dependencies
it may happen service A is restarted N times before it is stabilized in UP
state)
Feedback and comments more than welcome!
--
Rio
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:26 a.m.
On Fri, Jan 5, 2018 at 8:48 AM, Rostislav Svoboda <rsvoboda(a)redhat.com>
wrote:
> Hi everyone,
>
> I would like to outline a brief JBoss MSC Plans for Year 2018.
>
> Goals defined below address both:
> * Cloud First Effort
> - Reduce WildFly memory footprint
> - Speed up WildFly boot time
> * Potential Migration to MSC 2
>
> MSC Library Goals:
> * SHORT TERM GOALS (MSC 1.2.x, 1.3.x)
> [1] simplify MSC state machine - deprecate useless MSC internal states
> (e.g. REMOVED, WONT_START, WAITING, REMOVING, STOPPING maybe others)
> [2] deprecate API exposing MSC internals
> (e.g. replace ServiceListener with LifecycleListener)
> [3] deprecate MSC Values, Injections & Injectors and provide alternative
API
> (alternative API should have same minimalistic memory requirements like
MSC
> 2)
> * LONG TERM GOALS (MSC 1.4.x)
> [4] remove deprecated APIs and all deprecated stuff
Could you map MSC 1.2.x, 1.3.x and 1.4.x to planned WF 12/13/14/15
releases ?
MSC 1.2.x will become a maintainance branch for EAP 7.1 stream.
According to our plans (David wants to bring in new ThreadPool
implementation)
MSC 1.3.x should make it to WildFly 12.
MSC 1.4.x should make it to WildFly that will be the baseline for next
major EAP version following EAP based on WildFly 12.
Especially interested in MSC 1.4.x due to removal of deprecated
stuff.
Thank you.
Rostislav
> WildFly MSC Integration Goals:
> + SHORT TERM GOALS (WildFly 12)
> * replace ServiceListeners with LifecycleListeners (LifecycleListeners
don't
> expose MSC internals)
> * eliminate MSC optional dependencies from WildFLy Core
> * eliminate MSC Values, Injections & Injectors and migrate to
alternative API
> * WildFly Management Layer should not expose MSC APIs as its public API
> (complicates potential migration to MSC2 and breaks encapsulation)
> + LONG TERM GOALS (WildFly versions targeting next major EAP)
> * eliminate MSC optional dependencies from WildFly (probably via
> Capabilities)
> (MSC Optional Dependencies have been fixed recently but there's still
> performance issue
> - in worst case scenario if service A has N optional dependencies
> it may happen service A is restarted N times before it is stabilized in
UP
> state)
>
> Feedback and comments more than welcome!
>
> --
> Rio
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Rio
1:31 p.m.
Thanks, Richard. Comments in-line.
On Thu, Jan 4, 2018 at 7:56 AM, Richard Opalka <ropalka(a)redhat.com> wrote:
Hi everyone,
I would like to outline a brief JBoss MSC Plans for Year 2018.
Goals defined below address both:
* Cloud First Effort
- Reduce WildFly memory footprint
Do you have a sense of how much we're talking about here, e.g. from a
standalone server using the standalone-full.xml config and no deployments?
- Speed up WildFly boot time
Same question here. A reload takes a couple hundred ms of which my guess is
MSC is a quite small part.
* Potential Migration to MSC 2
MSC Library Goals:
* SHORT TERM GOALS (MSC 1.2.x, 1.3.x)
[1] simplify MSC state machine - deprecate useless MSC internal states
(e.g. REMOVED, WONT_START, WAITING, REMOVING, STOPPING maybe others)
[2] deprecate API exposing MSC internals
(e.g. replace ServiceListener with LifecycleListener)
[3] deprecate MSC Values, Injections & Injectors and provide
alternative API
(alternative API should have same minimalistic memory requirements
like MSC 2)
* LONG TERM GOALS (MSC 1.4.x)
[4] remove deprecated APIs and all deprecated stuff
WildFly MSC Integration Goals:
+ SHORT TERM GOALS (WildFly 12)
* replace ServiceListeners with LifecycleListeners (LifecycleListeners
don't expose MSC internals)
* eliminate MSC optional dependencies from WildFLy Core
Sounds good. The basic issue there is the modeling of optional module
dependencies using MSC services, and IIRC you have an alternate approach in
mind. DomainModelControllerService also has one for some reason but I
figure that can be eliminated easily enough.
* eliminate MSC Values, Injections & Injectors and migrate to
alternative API
This sounds like a very large task for WF 12, for which only some weeks of
dev time remain.
* WildFly Management Layer should not expose MSC APIs as its
public API
(complicates potential migration to MSC2 and breaks encapsulation)
I can't see this happening in WildFly 12. Let's talk about it when we meet
up at the end of the month.
+ LONG TERM GOALS (WildFly versions targeting next major EAP)
* eliminate MSC optional dependencies from WildFly (probably via
Capabilities)
(MSC Optional Dependencies have been fixed recently but there's still
performance issue
- in worst case scenario if service A has N optional dependencies
it may happen service A is restarted N times before it is stabilized
in UP state)
Feedback and comments more than welcome!
--
Rio
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
8:19 a.m.
Hi All,
comments in-line:
On Fri, Jan 5, 2018 at 8:31 PM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
Thanks, Richard. Comments in-line.
On Thu, Jan 4, 2018 at 7:56 AM, Richard Opalka <ropalka(a)redhat.com> wrote:
> Hi everyone,
>
> I would like to outline a brief JBoss MSC Plans for Year 2018.
>
> Goals defined below address both:
> * Cloud First Effort
> - Reduce WildFly memory footprint
>
Do you have a sense of how much we're talking about here, e.g. from a
standalone server using the standalone-full.xml config and no deployments?
If we'd replace injections, values and injectors with new MSC2 like
dependencies than I think we would be still talking about just small memory
improvements.
But such change might have better impact on MSC performance (from
concurrency point of view).
Anyway main reason of doing it is to approach MSC1 to MSC2 as much as
possible.
Then potential switch from MSC1 to MSC2 in the future would be more
straightforward process.
> - Speed up WildFly boot time
>
Same question here. A reload takes a couple hundred ms of which my guess
is MSC is a quite small part.
The improvement here might be better comparing to memory improvements.
Simplified MSC state machine (and less MSC states) results in less context
switches.
I have a local prototype where we have been able to eliminate one third of
MSC states
(and I believe we could simplify MSC state machine even further in the
future).
I don't have numbers yet but this change should improve WildFly boot
process and deployments.
> * Potential Migration to MSC 2
>
> MSC Library Goals:
> * SHORT TERM GOALS (MSC 1.2.x, 1.3.x)
> [1] simplify MSC state machine - deprecate useless MSC internal states
> (e.g. REMOVED, WONT_START, WAITING, REMOVING, STOPPING maybe
> others)
> [2] deprecate API exposing MSC internals
> (e.g. replace ServiceListener with LifecycleListener)
> [3] deprecate MSC Values, Injections & Injectors and provide
> alternative API
> (alternative API should have same minimalistic memory requirements
> like MSC 2)
> * LONG TERM GOALS (MSC 1.4.x)
> [4] remove deprecated APIs and all deprecated stuff
>
> WildFly MSC Integration Goals:
> + SHORT TERM GOALS (WildFly 12)
> * replace ServiceListeners with LifecycleListeners (LifecycleListeners
> don't expose MSC internals)
> * eliminate MSC optional dependencies from WildFLy Core
>
Sounds good. The basic issue there is the modeling of optional module
dependencies using MSC services, and IIRC you have an alternate approach in
mind.
I didn't give it much thinking yet, but at the moment there are two
alternatives I am aware of:
1) Let JBoss Modules do handling of optional dependencies on its own and
don't map optional modules to MSC optional dependencies
- the idea is present in this commit:
https://github.com/ropalka/wildfly-core/commit/c65841c1892f02e14a14101cca...
(and all WildFly-Core and WildFly testsuites are passing with this
commit)
2) Workaround MSC optional dependencies for optional modules somehow
- that's my next TODO task
DomainModelControllerService also has one for some reason but I figure that
can be eliminated easily enough.
This I hope should be easy to workaround via capabilities (i.e. install
REQUIRED dependency iff some capability is present).
> * eliminate MSC Values, Injections & Injectors and migrate to
> alternative API
>
This sounds like a very large task for WF 12, for which only some weeks of
dev time remain.
This sounds more complex than it is. But of course there can be use cases
that might complicate this task.
> * WildFly Management Layer should not expose MSC APIs as its public API
> (complicates potential migration to MSC2 and breaks encapsulation)
>
I can't see this happening in WildFly 12. Let's talk about it when we meet
up at the end of the month.
We definitely need to talk about it and come to a conclusion.
+ LONG TERM GOALS (WildFly versions targeting next major EAP)
> * eliminate MSC optional dependencies from WildFly (probably via
> Capabilities)
> (MSC Optional Dependencies have been fixed recently but there's
> still performance issue
> - in worst case scenario if service A has N optional dependencies
> it may happen service A is restarted N times before it is stabilized
> in UP state)
>
> Feedback and comments more than welcome!
>
> --
> Rio
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
Thanks for asking.
--
Rio
12:31 a.m.
On 04.01.2018 14:56, Richard Opalka wrote:
Hi everyone,
I would like to outline a brief JBoss MSC Plans for Year 2018.
Goals defined below address both:
* Cloud First Effort
- Reduce WildFly memory footprint
I would like to throw something in here, are there any plans to no
longer reference the JAR manifest? We use quite a few JARs that have
large manifests and because JBoss modules strongly references the
java.util.jar.Manifest instance that actually becomes noticeable.
Our JAR manifests are so large because they contain large OSGi headers.
We don't run OSGi, the JARs are simply OSGi capable.
Cheers
Philippe
12:38 a.m.
JBoss Modules is not the same as JBoss MSC, but your idea is a good
one. I've opened https://issues.jboss.org/browse/MODULES-325 to track
it.
On Mon, Jan 29, 2018 at 7:31 AM, Philippe Marschall <kustos(a)gmx.net> wrote:
On 04.01.2018 14:56, Richard Opalka wrote:
> Hi everyone,
>
> I would like to outline a brief JBoss MSC Plans for Year 2018.
>
> Goals defined below address both:
> * Cloud First Effort
> - Reduce WildFly memory footprint
I would like to throw something in here, are there any plans to no
longer reference the JAR manifest? We use quite a few JARs that have
large manifests and because JBoss modules strongly references the
java.util.jar.Manifest instance that actually becomes noticeable.
Our JAR manifests are so large because they contain large OSGi headers.
We don't run OSGi, the JARs are simply OSGi capable.
Cheers
Philippe
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
- DML
2527
days inactive
2552
days old
6 comments
5 participants
participants (5)
-
Brian Stansberry -
David Lloyd -
Philippe Marschall -
Richard Opalka -
Rostislav Svoboda