[JBoss JIRA] (WFLY-12914) Upgrade Galleon to 4.2.1.Final and the wildfly-galleon-plugins to 4.2.2.Final
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-12914?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-12914:
------------------------------------
Summary: Upgrade Galleon to 4.2.1.Final and the wildfly-galleon-plugins to 4.2.2.Final (was: Upgrade Galleon to 4.2.1.Final and the wildfly-galleon-plugins to 4.2.2.Final; clean out unneeded provisioning boilerplate)
> Upgrade Galleon to 4.2.1.Final and the wildfly-galleon-plugins to 4.2.2.Final
> -----------------------------------------------------------------------------
>
> Key: WFLY-12914
> URL: https://issues.redhat.com/browse/WFLY-12914
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> Upgrade Galleon to match the versions used in core.
> The current versions should allow trimming quite a bit of boilerplate from all the places where we provision servers:
> Alexey Loubyansky 5:07 PM
> I did a bit more work on this, fixed a couple of issues and just released Galleon 4.2.1.Final and WFGP 4.2.1.Final
> Alexey Loubyansky 5:07 PM
> also opened a PR to upgrade WildFly Core to these releases https://github.com/wildfly/wildfly-core/pull/4025
> 5:08 PM
> upgrading doesn't affect anything, except the bug fixes contained in those versions
> 5:10 PM
> however, for wildfly, i think we should use GAVs as feature-pack locations for feature-pack dependencies, in place of Galleon FPL
> 5:11 PM
> the benefit would be to avoid the universe resolver in maven builds
> 5:11 PM
> and also a simplified (mojo) provisioning config
> Brian Stansberry 5:14 PM
> good timing; I'm working on how to add a new f-p to wildfly (for microprofile stuff) so i should use best practices :)
> Alexey Loubyansky 5:16 PM
> by simplified provisioning config i mean that the selected block should be removed completely https://github.com/wildfly/wildfly/blob/master/build/pom.xml#L84-L97
> 5:16 PM
> the only reason it is there is to avoid resolution from the universe
> 5:17 PM
> with GAVs for dependencies, it won't be necessary anymore
> Brian Stansberry 5:17 PM
> what about <inheritConfigs>false</inheritConfigs> ?
> Alexey Loubyansky 5:18 PM
> that was there to workaround a bug which was fixed in 4.2.0.Final
> Brian Stansberry 5:18 PM
> how about
> 5:18 PM
> <included-packages>
> <name>docs.examples.configs</name>
> </included-packages>
> 5:19 PM
> assuming that's not in the top level f-p
> Alexey Loubyansky 5:19 PM
> that should definitely stay, it's not in the selected block
> 5:19 PM
> ah, then you can have that
> 5:20 PM
> then there would be a real reason to mention the transitive dependency
> 5:20 PM
> i.e. you want something from it
> Brian Stansberry 5:20 PM
> could it be declared in the top level block, even though the package is in the transitive dep?
> 5:20 PM
> i'm going off on tangents, but first i should have said...
> 5:21 PM
> Nice!
> Alexey Loubyansky 5:21 PM (EDITED)
> unless the package is installed by default, it has to be included explicitly using transitive element
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-12914) Upgrade Galleon to 4.2.1.Final and the wildfly-galleon-plugins to 4.2.2.Final
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-12914?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-12914:
------------------------------------
Description:
Upgrade Galleon to match the versions used in core.
was:
Upgrade Galleon to match the versions used in core.
The current versions should allow trimming quite a bit of boilerplate from all the places where we provision servers:
Alexey Loubyansky 5:07 PM
I did a bit more work on this, fixed a couple of issues and just released Galleon 4.2.1.Final and WFGP 4.2.1.Final
Alexey Loubyansky 5:07 PM
also opened a PR to upgrade WildFly Core to these releases https://github.com/wildfly/wildfly-core/pull/4025
5:08 PM
upgrading doesn't affect anything, except the bug fixes contained in those versions
5:10 PM
however, for wildfly, i think we should use GAVs as feature-pack locations for feature-pack dependencies, in place of Galleon FPL
5:11 PM
the benefit would be to avoid the universe resolver in maven builds
5:11 PM
and also a simplified (mojo) provisioning config
Brian Stansberry 5:14 PM
good timing; I'm working on how to add a new f-p to wildfly (for microprofile stuff) so i should use best practices :)
Alexey Loubyansky 5:16 PM
by simplified provisioning config i mean that the selected block should be removed completely https://github.com/wildfly/wildfly/blob/master/build/pom.xml#L84-L97
5:16 PM
the only reason it is there is to avoid resolution from the universe
5:17 PM
with GAVs for dependencies, it won't be necessary anymore
Brian Stansberry 5:17 PM
what about <inheritConfigs>false</inheritConfigs> ?
Alexey Loubyansky 5:18 PM
that was there to workaround a bug which was fixed in 4.2.0.Final
Brian Stansberry 5:18 PM
how about
5:18 PM
<included-packages>
<name>docs.examples.configs</name>
</included-packages>
5:19 PM
assuming that's not in the top level f-p
Alexey Loubyansky 5:19 PM
that should definitely stay, it's not in the selected block
5:19 PM
ah, then you can have that
5:20 PM
then there would be a real reason to mention the transitive dependency
5:20 PM
i.e. you want something from it
Brian Stansberry 5:20 PM
could it be declared in the top level block, even though the package is in the transitive dep?
5:20 PM
i'm going off on tangents, but first i should have said...
5:21 PM
Nice!
Alexey Loubyansky 5:21 PM (EDITED)
unless the package is installed by default, it has to be included explicitly using transitive element
> Upgrade Galleon to 4.2.1.Final and the wildfly-galleon-plugins to 4.2.2.Final
> -----------------------------------------------------------------------------
>
> Key: WFLY-12914
> URL: https://issues.redhat.com/browse/WFLY-12914
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> Upgrade Galleon to match the versions used in core.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-12915) Clean out unneeded provisioning boilerplate
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-12915?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-12915:
------------------------------------
Issue Type: Task (was: Component Upgrade)
> Clean out unneeded provisioning boilerplate
> -------------------------------------------
>
> Key: WFLY-12915
> URL: https://issues.redhat.com/browse/WFLY-12915
> Project: WildFly
> Issue Type: Task
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
>
> Upgrade Galleon to match the versions used in core.
> The current versions should allow trimming quite a bit of boilerplate from all the places where we provision servers:
> Alexey Loubyansky 5:07 PM
> I did a bit more work on this, fixed a couple of issues and just released Galleon 4.2.1.Final and WFGP 4.2.1.Final
> Alexey Loubyansky 5:07 PM
> also opened a PR to upgrade WildFly Core to these releases https://github.com/wildfly/wildfly-core/pull/4025
> 5:08 PM
> upgrading doesn't affect anything, except the bug fixes contained in those versions
> 5:10 PM
> however, for wildfly, i think we should use GAVs as feature-pack locations for feature-pack dependencies, in place of Galleon FPL
> 5:11 PM
> the benefit would be to avoid the universe resolver in maven builds
> 5:11 PM
> and also a simplified (mojo) provisioning config
> Brian Stansberry 5:14 PM
> good timing; I'm working on how to add a new f-p to wildfly (for microprofile stuff) so i should use best practices :)
> Alexey Loubyansky 5:16 PM
> by simplified provisioning config i mean that the selected block should be removed completely https://github.com/wildfly/wildfly/blob/master/build/pom.xml#L84-L97
> 5:16 PM
> the only reason it is there is to avoid resolution from the universe
> 5:17 PM
> with GAVs for dependencies, it won't be necessary anymore
> Brian Stansberry 5:17 PM
> what about <inheritConfigs>false</inheritConfigs> ?
> Alexey Loubyansky 5:18 PM
> that was there to workaround a bug which was fixed in 4.2.0.Final
> Brian Stansberry 5:18 PM
> how about
> 5:18 PM
> <included-packages>
> <name>docs.examples.configs</name>
> </included-packages>
> 5:19 PM
> assuming that's not in the top level f-p
> Alexey Loubyansky 5:19 PM
> that should definitely stay, it's not in the selected block
> 5:19 PM
> ah, then you can have that
> 5:20 PM
> then there would be a real reason to mention the transitive dependency
> 5:20 PM
> i.e. you want something from it
> Brian Stansberry 5:20 PM
> could it be declared in the top level block, even though the package is in the transitive dep?
> 5:20 PM
> i'm going off on tangents, but first i should have said...
> 5:21 PM
> Nice!
> Alexey Loubyansky 5:21 PM (EDITED)
> unless the package is installed by default, it has to be included explicitly using transitive element
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-12915) Clean out unneeded provisioning boilerplate
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12915:
---------------------------------------
Summary: Clean out unneeded provisioning boilerplate
Key: WFLY-12915
URL: https://issues.redhat.com/browse/WFLY-12915
Project: WildFly
Issue Type: Component Upgrade
Components: Build System
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Upgrade Galleon to match the versions used in core.
The current versions should allow trimming quite a bit of boilerplate from all the places where we provision servers:
Alexey Loubyansky 5:07 PM
I did a bit more work on this, fixed a couple of issues and just released Galleon 4.2.1.Final and WFGP 4.2.1.Final
Alexey Loubyansky 5:07 PM
also opened a PR to upgrade WildFly Core to these releases https://github.com/wildfly/wildfly-core/pull/4025
5:08 PM
upgrading doesn't affect anything, except the bug fixes contained in those versions
5:10 PM
however, for wildfly, i think we should use GAVs as feature-pack locations for feature-pack dependencies, in place of Galleon FPL
5:11 PM
the benefit would be to avoid the universe resolver in maven builds
5:11 PM
and also a simplified (mojo) provisioning config
Brian Stansberry 5:14 PM
good timing; I'm working on how to add a new f-p to wildfly (for microprofile stuff) so i should use best practices :)
Alexey Loubyansky 5:16 PM
by simplified provisioning config i mean that the selected block should be removed completely https://github.com/wildfly/wildfly/blob/master/build/pom.xml#L84-L97
5:16 PM
the only reason it is there is to avoid resolution from the universe
5:17 PM
with GAVs for dependencies, it won't be necessary anymore
Brian Stansberry 5:17 PM
what about <inheritConfigs>false</inheritConfigs> ?
Alexey Loubyansky 5:18 PM
that was there to workaround a bug which was fixed in 4.2.0.Final
Brian Stansberry 5:18 PM
how about
5:18 PM
<included-packages>
<name>docs.examples.configs</name>
</included-packages>
5:19 PM
assuming that's not in the top level f-p
Alexey Loubyansky 5:19 PM
that should definitely stay, it's not in the selected block
5:19 PM
ah, then you can have that
5:20 PM
then there would be a real reason to mention the transitive dependency
5:20 PM
i.e. you want something from it
Brian Stansberry 5:20 PM
could it be declared in the top level block, even though the package is in the transitive dep?
5:20 PM
i'm going off on tangents, but first i should have said...
5:21 PM
Nice!
Alexey Loubyansky 5:21 PM (EDITED)
unless the package is installed by default, it has to be included explicitly using transitive element
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-12915) Clean out unneeded provisioning boilerplate
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-12915?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-12915:
------------------------------------
Description:
The current Galleon versions should allow trimming quite a bit of boilerplate from all the places where we provision servers:
Alexey Loubyansky 5:07 PM
I did a bit more work on this, fixed a couple of issues and just released Galleon 4.2.1.Final and WFGP 4.2.1.Final
Alexey Loubyansky 5:07 PM
also opened a PR to upgrade WildFly Core to these releases https://github.com/wildfly/wildfly-core/pull/4025
5:08 PM
upgrading doesn't affect anything, except the bug fixes contained in those versions
5:10 PM
however, for wildfly, i think we should use GAVs as feature-pack locations for feature-pack dependencies, in place of Galleon FPL
5:11 PM
the benefit would be to avoid the universe resolver in maven builds
5:11 PM
and also a simplified (mojo) provisioning config
Brian Stansberry 5:14 PM
good timing; I'm working on how to add a new f-p to wildfly (for microprofile stuff) so i should use best practices :)
Alexey Loubyansky 5:16 PM
by simplified provisioning config i mean that the selected block should be removed completely https://github.com/wildfly/wildfly/blob/master/build/pom.xml#L84-L97
5:16 PM
the only reason it is there is to avoid resolution from the universe
5:17 PM
with GAVs for dependencies, it won't be necessary anymore
Brian Stansberry 5:17 PM
what about <inheritConfigs>false</inheritConfigs> ?
Alexey Loubyansky 5:18 PM
that was there to workaround a bug which was fixed in 4.2.0.Final
Brian Stansberry 5:18 PM
how about
5:18 PM
<included-packages>
<name>docs.examples.configs</name>
</included-packages>
5:19 PM
assuming that's not in the top level f-p
Alexey Loubyansky 5:19 PM
that should definitely stay, it's not in the selected block
5:19 PM
ah, then you can have that
5:20 PM
then there would be a real reason to mention the transitive dependency
5:20 PM
i.e. you want something from it
Brian Stansberry 5:20 PM
could it be declared in the top level block, even though the package is in the transitive dep?
5:20 PM
i'm going off on tangents, but first i should have said...
5:21 PM
Nice!
Alexey Loubyansky 5:21 PM (EDITED)
unless the package is installed by default, it has to be included explicitly using transitive element
was:
Upgrade Galleon to match the versions used in core.
The current versions should allow trimming quite a bit of boilerplate from all the places where we provision servers:
Alexey Loubyansky 5:07 PM
I did a bit more work on this, fixed a couple of issues and just released Galleon 4.2.1.Final and WFGP 4.2.1.Final
Alexey Loubyansky 5:07 PM
also opened a PR to upgrade WildFly Core to these releases https://github.com/wildfly/wildfly-core/pull/4025
5:08 PM
upgrading doesn't affect anything, except the bug fixes contained in those versions
5:10 PM
however, for wildfly, i think we should use GAVs as feature-pack locations for feature-pack dependencies, in place of Galleon FPL
5:11 PM
the benefit would be to avoid the universe resolver in maven builds
5:11 PM
and also a simplified (mojo) provisioning config
Brian Stansberry 5:14 PM
good timing; I'm working on how to add a new f-p to wildfly (for microprofile stuff) so i should use best practices :)
Alexey Loubyansky 5:16 PM
by simplified provisioning config i mean that the selected block should be removed completely https://github.com/wildfly/wildfly/blob/master/build/pom.xml#L84-L97
5:16 PM
the only reason it is there is to avoid resolution from the universe
5:17 PM
with GAVs for dependencies, it won't be necessary anymore
Brian Stansberry 5:17 PM
what about <inheritConfigs>false</inheritConfigs> ?
Alexey Loubyansky 5:18 PM
that was there to workaround a bug which was fixed in 4.2.0.Final
Brian Stansberry 5:18 PM
how about
5:18 PM
<included-packages>
<name>docs.examples.configs</name>
</included-packages>
5:19 PM
assuming that's not in the top level f-p
Alexey Loubyansky 5:19 PM
that should definitely stay, it's not in the selected block
5:19 PM
ah, then you can have that
5:20 PM
then there would be a real reason to mention the transitive dependency
5:20 PM
i.e. you want something from it
Brian Stansberry 5:20 PM
could it be declared in the top level block, even though the package is in the transitive dep?
5:20 PM
i'm going off on tangents, but first i should have said...
5:21 PM
Nice!
Alexey Loubyansky 5:21 PM (EDITED)
unless the package is installed by default, it has to be included explicitly using transitive element
> Clean out unneeded provisioning boilerplate
> -------------------------------------------
>
> Key: WFLY-12915
> URL: https://issues.redhat.com/browse/WFLY-12915
> Project: WildFly
> Issue Type: Task
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
>
> The current Galleon versions should allow trimming quite a bit of boilerplate from all the places where we provision servers:
> Alexey Loubyansky 5:07 PM
> I did a bit more work on this, fixed a couple of issues and just released Galleon 4.2.1.Final and WFGP 4.2.1.Final
> Alexey Loubyansky 5:07 PM
> also opened a PR to upgrade WildFly Core to these releases https://github.com/wildfly/wildfly-core/pull/4025
> 5:08 PM
> upgrading doesn't affect anything, except the bug fixes contained in those versions
> 5:10 PM
> however, for wildfly, i think we should use GAVs as feature-pack locations for feature-pack dependencies, in place of Galleon FPL
> 5:11 PM
> the benefit would be to avoid the universe resolver in maven builds
> 5:11 PM
> and also a simplified (mojo) provisioning config
> Brian Stansberry 5:14 PM
> good timing; I'm working on how to add a new f-p to wildfly (for microprofile stuff) so i should use best practices :)
> Alexey Loubyansky 5:16 PM
> by simplified provisioning config i mean that the selected block should be removed completely https://github.com/wildfly/wildfly/blob/master/build/pom.xml#L84-L97
> 5:16 PM
> the only reason it is there is to avoid resolution from the universe
> 5:17 PM
> with GAVs for dependencies, it won't be necessary anymore
> Brian Stansberry 5:17 PM
> what about <inheritConfigs>false</inheritConfigs> ?
> Alexey Loubyansky 5:18 PM
> that was there to workaround a bug which was fixed in 4.2.0.Final
> Brian Stansberry 5:18 PM
> how about
> 5:18 PM
> <included-packages>
> <name>docs.examples.configs</name>
> </included-packages>
> 5:19 PM
> assuming that's not in the top level f-p
> Alexey Loubyansky 5:19 PM
> that should definitely stay, it's not in the selected block
> 5:19 PM
> ah, then you can have that
> 5:20 PM
> then there would be a real reason to mention the transitive dependency
> 5:20 PM
> i.e. you want something from it
> Brian Stansberry 5:20 PM
> could it be declared in the top level block, even though the package is in the transitive dep?
> 5:20 PM
> i'm going off on tangents, but first i should have said...
> 5:21 PM
> Nice!
> Alexey Loubyansky 5:21 PM (EDITED)
> unless the package is installed by default, it has to be included explicitly using transitive element
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-12914) Upgrade Galleon to 4.2.1.Final and the wildfly-galleon-plugins to 4.2.2.Final; clean out unneeded provisioning boilerplate
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12914:
---------------------------------------
Summary: Upgrade Galleon to 4.2.1.Final and the wildfly-galleon-plugins to 4.2.2.Final; clean out unneeded provisioning boilerplate
Key: WFLY-12914
URL: https://issues.redhat.com/browse/WFLY-12914
Project: WildFly
Issue Type: Component Upgrade
Components: Build System
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Upgrade Galleon to match the versions used in core.
The current versions should allow trimming quite a bit of boilerplate from all the places where we provision servers:
Alexey Loubyansky 5:07 PM
I did a bit more work on this, fixed a couple of issues and just released Galleon 4.2.1.Final and WFGP 4.2.1.Final
Alexey Loubyansky 5:07 PM
also opened a PR to upgrade WildFly Core to these releases https://github.com/wildfly/wildfly-core/pull/4025
5:08 PM
upgrading doesn't affect anything, except the bug fixes contained in those versions
5:10 PM
however, for wildfly, i think we should use GAVs as feature-pack locations for feature-pack dependencies, in place of Galleon FPL
5:11 PM
the benefit would be to avoid the universe resolver in maven builds
5:11 PM
and also a simplified (mojo) provisioning config
Brian Stansberry 5:14 PM
good timing; I'm working on how to add a new f-p to wildfly (for microprofile stuff) so i should use best practices :)
Alexey Loubyansky 5:16 PM
by simplified provisioning config i mean that the selected block should be removed completely https://github.com/wildfly/wildfly/blob/master/build/pom.xml#L84-L97
5:16 PM
the only reason it is there is to avoid resolution from the universe
5:17 PM
with GAVs for dependencies, it won't be necessary anymore
Brian Stansberry 5:17 PM
what about <inheritConfigs>false</inheritConfigs> ?
Alexey Loubyansky 5:18 PM
that was there to workaround a bug which was fixed in 4.2.0.Final
Brian Stansberry 5:18 PM
how about
5:18 PM
<included-packages>
<name>docs.examples.configs</name>
</included-packages>
5:19 PM
assuming that's not in the top level f-p
Alexey Loubyansky 5:19 PM
that should definitely stay, it's not in the selected block
5:19 PM
ah, then you can have that
5:20 PM
then there would be a real reason to mention the transitive dependency
5:20 PM
i.e. you want something from it
Brian Stansberry 5:20 PM
could it be declared in the top level block, even though the package is in the transitive dep?
5:20 PM
i'm going off on tangents, but first i should have said...
5:21 PM
Nice!
Alexey Loubyansky 5:21 PM (EDITED)
unless the package is installed by default, it has to be included explicitly using transitive element
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (JGRP-2426) JChannel: remove stats
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2426?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2426:
--------------------------------
Consider using {{MsgStats}} in {{STATS}} if both prots maintain (more or less) the same values.
> JChannel: remove stats
> ----------------------
>
> Key: JGRP-2426
> URL: https://issues.redhat.com/browse/JGRP-2426
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Optional
> Fix For: 5.0
>
>
> Remove stats such as {{sent_msgs, received_msgs, sent_bytes, received_bytes}} from JChannel. It may be costly to maintain those stats (e.g. {{Message.getLength()}} in 5.0), and they're already maintained by the transport (or {{STATS}}).
> For ForkChannels, these stats would be gone, too, and would not be maintained for each fork channel separately...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (JGRP-2426) JChannel: remove stats
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/JGRP-2426?page=com.atlassian.jira.plugin... ]
Dan Berindei commented on JGRP-2426:
------------------------------------
Perhaps {{STATS}} could be added above {{FORK}} when separate stats for each fork channel are needed.
But {{STATS}} also needs to be changed to use {{LongAdder}}.
> JChannel: remove stats
> ----------------------
>
> Key: JGRP-2426
> URL: https://issues.redhat.com/browse/JGRP-2426
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Optional
> Fix For: 5.0
>
>
> Remove stats such as {{sent_msgs, received_msgs, sent_bytes, received_bytes}} from JChannel. It may be costly to maintain those stats (e.g. {{Message.getLength()}} in 5.0), and they're already maintained by the transport (or {{STATS}}).
> For ForkChannels, these stats would be gone, too, and would not be maintained for each fork channel separately...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (JGRP-2426) JChannel: remove stats
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2426?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2426:
---------------------------
Description:
Remove stats such as {{sent_msgs, received_msgs, sent_bytes, received_bytes}} from JChannel. It may be costly to maintain those stats (e.g. {{Message.getLength()}} in 5.0), and they're already maintained by the transport (or {{STATS}}).
For ForkChannels, these stats would be gone, too, and would not be maintained for each fork channel separately...
was:Remove stats such as {{sent_msgs, received_msgs, sent_bytes, received_bytes}} from JChannel. It may be costly to maintain those stats (e.g. {{Message.getLength()}} in 5.0), and they're already maintained by the transport (or {{STATS}}).
> JChannel: remove stats
> ----------------------
>
> Key: JGRP-2426
> URL: https://issues.redhat.com/browse/JGRP-2426
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Optional
> Fix For: 5.0
>
>
> Remove stats such as {{sent_msgs, received_msgs, sent_bytes, received_bytes}} from JChannel. It may be costly to maintain those stats (e.g. {{Message.getLength()}} in 5.0), and they're already maintained by the transport (or {{STATS}}).
> For ForkChannels, these stats would be gone, too, and would not be maintained for each fork channel separately...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (JGRP-2426) JChannel: remove stats
by Bela Ban (Jira)
Bela Ban created JGRP-2426:
------------------------------
Summary: JChannel: remove stats
Key: JGRP-2426
URL: https://issues.redhat.com/browse/JGRP-2426
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 5.0
Remove stats such as {{sent_msgs, received_msgs, sent_bytes, received_bytes}} from JChannel. It may be costly to maintain those stats (e.g. {{Message.getLength()}} in 5.0), and they're already maintained by the transport (or {{STATS}}).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months