[JBoss JIRA] (WFLY-7548) Servletcontext.getServerInfo() returns WildFly 2.2.0.Final - 1.4.0.Final instead of 10.1.0.Final
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-7548?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet reassigned WFLY-7548:
---------------------------------------
Assignee: ehsavoie Hugonnet (was: Stuart Douglas)
> Servletcontext.getServerInfo() returns WildFly 2.2.0.Final - 1.4.0.Final instead of 10.1.0.Final
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-7548
> URL: https://issues.jboss.org/browse/WFLY-7548
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0.Final
> Reporter: Kálmán Szalai
> Assignee: ehsavoie Hugonnet
> Priority: Minor
>
> Servletcontext.getServerInfo() returns WildFly 2.2.0.Final - 1.4.0.Final instead of 10.1.0.Final. I saw WildFly 2.2.0.Final is the Wildfly Core version.
> Additionally the admin interfacde shows:
> Product name: WildFly Full
> Product version: 10.1.0.Final
> Profile: COMMUNITY
> HAL version: 2.8.27.Final
> Core version: 2.8.27.Final
> Wildfly 8 is produced Wildfly 8 version sting on getServerInfo() call.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JGRP-2136) Merge installs the same view
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2136?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2136:
--------------------------------
NB: I checked with the Infinispan devs and they do ignore duplicate views, so this is not an issue with them. However, this needs to be fixed anyway...
> Merge installs the same view
> ----------------------------
>
> Key: JGRP-2136
> URL: https://issues.jboss.org/browse/JGRP-2136
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.12, 4.0
>
>
> The cluster is A,B with AUTH and ASYM_ENCRYPT. When a rogue member C (whith an incorrect auth_value in AUTH) attempts to join, it will be rejected by AUTH. However, while the subsequent merge attempts also fail (as designed), this leads to spurious MergeView installations in A and B, e.g.:
> {noformat}
> ** View=[belasmac-17416|1] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|2] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|1] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|3] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|2] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|4] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|3] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|5] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|4] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|6] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|5] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|7] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|6] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|8] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|7] (2) [belasmac-17416, belasmac-56188]
> {noformat}
> This neither corrupts security of the system (the rogue member cannot merge-join) nor correctness, but we need to prevent the spurious views. Systems like Infinispan might start a rebalance on a view, regardless of whether they are the same as before or not.
> SOLUTION: the merge leader needs to see if the MergeView it is about to send out is the same as the current view, and simply drop it if that's the case.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JGRP-2136) Merge installs the same view
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2136?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2136:
---------------------------
Description:
The cluster is A,B with AUTH and ASYM_ENCRYPT. When a rogue member C (whith an incorrect auth_value in AUTH) attempts to join, it will be rejected by AUTH. However, while the subsequent merge attempts also fail (as designed), this leads to spurious MergeView installations in A and B, e.g.:
{noformat}
** View=[belasmac-17416|1] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|2] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|1] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|3] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|2] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|4] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|3] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|5] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|4] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|6] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|5] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|7] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|6] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|8] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|7] (2) [belasmac-17416, belasmac-56188]
{noformat}
This neither corrupts security of the system (the rogue member cannot merge-join) nor correctness, but we need to prevent the spurious views. Systems like Infinispan might start a rebalance on a view, regardless of whether they are the same as before or not.
SOLUTION: the merge leader needs to see if the MergeView it is about to send out is the same as the current view, and simply drop it if that's the case.
was:
The cluster is A,B with AUTH and ASYM_ENCRYPT. When a rogue member C (whith an incorrect auth_value in AUTH) attempts to join, it will be rejected by AUTH. However, while the subsequent merge attempts also fail (as designed), this leads to spurious MergeView installations in A and B, e.g.:
{noformat}
** View=[belasmac-17416|1] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|2] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|1] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|3] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|2] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|4] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|3] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|5] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|4] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|6] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|5] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|7] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|6] (2) [belasmac-17416, belasmac-56188]
** MergeView::[belasmac-17416|8] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|7] (2) [belasmac-17416, belasmac-56188]
{noformat}
This neither corrupts security of the system (the rogue member cannot merge-join) not correctness, but we need to prevent the spurious views. Systems like Infinispan might start a rebalance on a view, regardless of whether they are the same as before or not.
SOLUTION: the merge leader needs to see if the MergeView it is about to send out is the same as the current view, and simply drop it if that's the case.
> Merge installs the same view
> ----------------------------
>
> Key: JGRP-2136
> URL: https://issues.jboss.org/browse/JGRP-2136
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.12, 4.0
>
>
> The cluster is A,B with AUTH and ASYM_ENCRYPT. When a rogue member C (whith an incorrect auth_value in AUTH) attempts to join, it will be rejected by AUTH. However, while the subsequent merge attempts also fail (as designed), this leads to spurious MergeView installations in A and B, e.g.:
> {noformat}
> ** View=[belasmac-17416|1] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|2] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|1] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|3] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|2] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|4] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|3] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|5] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|4] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|6] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|5] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|7] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|6] (2) [belasmac-17416, belasmac-56188]
> ** MergeView::[belasmac-17416|8] (2) [belasmac-17416, belasmac-56188], 1 subgroups: [belasmac-17416|7] (2) [belasmac-17416, belasmac-56188]
> {noformat}
> This neither corrupts security of the system (the rogue member cannot merge-join) nor correctness, but we need to prevent the spurious views. Systems like Infinispan might start a rebalance on a view, regardless of whether they are the same as before or not.
> SOLUTION: the merge leader needs to see if the MergeView it is about to send out is the same as the current view, and simply drop it if that's the case.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JGRP-2150) More efficient message adding and draining
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2150:
---------------------------
Description:
In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
This requires synchronization around (1) determining the thread which will remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
was:
In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
This requires synchronization around (1) determining the thread will be remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
> More efficient message adding and draining
> ------------------------------------------
>
> Key: JGRP-2150
> URL: https://issues.jboss.org/browse/JGRP-2150
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR1
> Fix For: 4.0
>
>
> In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
> This requires synchronization around (1) determining the thread which will remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
> Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JGRP-2150) More efficient message adding and draining
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2150:
---------------------------
Description:
In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
This requires synchronization around (1) determining the thread will be remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
was:
In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where aone or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
This requires synchronization around (1) determining the thread will be remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
> More efficient message adding and draining
> ------------------------------------------
>
> Key: JGRP-2150
> URL: https://issues.jboss.org/browse/JGRP-2150
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR1
> Fix For: 4.0
>
>
> In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
> This requires synchronization around (1) determining the thread will be remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
> Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JGRP-2117) TP: messages to self are not batched
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2117?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2117.
----------------------------
Resolution: Done
> TP: messages to self are not batched
> ------------------------------------
>
> Key: JGRP-2117
> URL: https://issues.jboss.org/browse/JGRP-2117
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR1
> Fix For: 4.0
>
>
> If A sends 100 multicast messages (or unicast messages to self), the messages to self are not batched but looped back individually, each using a separate thread from the thread pool.
> So in the above case, A will receive its own 100 messages using 100 threads from the pool.
> It would be more efficient to batch the 100 messages into a batch and then loop the batch back, taking up 1 thread instead of 100!
> To do this, looping back has to be done _after_ the bundler, when the bundler is sending the message batch.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (DROOLS-901) Align spring version with the eap fuse layer spring version
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-901?page=com.atlassian.jira.plugin... ]
Petr Široký resolved DROOLS-901.
--------------------------------
Fix Version/s: 6.5.0.Final
Resolution: Done
I am closing this since we upgraded the Spring the the latest available 4.x version few months back. We will keep updating the 4.x version and since there is no Spring 5.x, this is the version we will stay on for quite some time.
> Align spring version with the eap fuse layer spring version
> -----------------------------------------------------------
>
> Key: DROOLS-901
> URL: https://issues.jboss.org/browse/DROOLS-901
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.3.0.Final
> Reporter: David virgil naranjo
> Assignee: Petr Široký
> Fix For: 6.5.0.Final
>
>
> Right now on drools it is used spring 3, while on the eap fuse layer it is used the version 4.1.6.RELEASE.
> It wouldb e good to have the same version, because in that case some of the fuse-bxms-integ quickstarts could be deployed on eap.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months