[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:
--------------------------------
Attached unit test (removed in repo).
> 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
>
> Attachments: DuplicateMergeViewTest.java
>
>
> 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:
---------------------------
Attachment: DuplicateMergeViewTest.java
> 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
>
> Attachments: DuplicateMergeViewTest.java
>
>
> 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 commented on JGRP-2136:
--------------------------------
OK, I'll revert the code which prevents duplicate consecutive MergeViews; the application has to be able to handle this (also updated the manual on MergeView). Otherwise, edge merge cases like the one above would not get handled properly.
Note that regular consecutive views are not affected: they never have duplicate membership.
> 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] (DROOLS-1401) File Descriptor leak
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1401?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1401:
--------------------------------
Summary: File Descriptor leak (was: File Descriptor LEAK in JBPM)
> File Descriptor leak
> --------------------
>
> Key: DROOLS-1401
> URL: https://issues.jboss.org/browse/DROOLS-1401
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Ankit Jain
> Assignee: Mario Fusco
>
> we are using the JBPM 6.4 version and using Kie Deployment API lie-cie-6.4.0.jar for deploying the KJARs.
> API we are using is
> FluentKieModuleDeploymentHelper deplymenthelperObj = KieModuleDeploymentHelper.newFluentInstance()
> deplymenthelperObj .createKieJarAndDeployToMaven()
> In KieModuleDeploymentHelperImpl CLASS
> Method -- String convertFileToString(InputStream in)
> In this the stream is never closed... the File Descriptors starts leaking....
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (DROOLS-1400) Comparison of DRL changes should not consider comments during incremental compilation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1400?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1400:
----------------------------------------
Reproducer:
{code:java}
@Test
public void testKJarUpgradeWithDRLComment() throws Exception {
// DROOLS-1400
String drl_Rx_1 = "// Build ID# 001 \n"+
"package org.drools.compiler\n" +
"rule Rx when\n" +
" $m : Message( message == \"Hello World\" )\n" +
"then\n" +
"end\n";
String drl_Rx_2 = "// Build ID# 002 \n"+
"package org.drools.compiler\n" +
"rule Rx when\n" +
" $m : Message( message == \"Hello World\" )\n" +
"then\n" +
"end\n";
String drl_Rnew_2 = "// Build ID# 002 \n"+
"package org.drools.compiler\n" +
"rule Rnew when\n" +
" $s : String()\n" +
"then\n" +
"end\n";
KieServices ks = KieServices.Factory.get();
ReleaseId releaseId1 = ks.newReleaseId( "org.kie", "test-upgrade", "1.0.0" );
KieModule km = createAndDeployJar( ks, releaseId1, drl_Rx_1 );
KieContainer kc = ks.newKieContainer( km.getReleaseId() );
KieSession ksession = kc.newKieSession();
ksession.insert( new Message( "Hello World" ) );
assertEquals( 1, ksession.fireAllRules() );
ReleaseId releaseId2 = ks.newReleaseId( "org.kie", "test-upgrade", "1.1.0" );
km = createAndDeployJar( ks, releaseId2, drl_Rx_2, drl_Rnew_2 );
kc.updateToVersion( releaseId2 );
// rule Rx is UNchanged and should NOT fire again
// rule Rnew is new but there is no match
assertEquals( 0, ksession.fireAllRules() );
}
{code}
> Comparison of DRL changes should not consider comments during incremental compilation
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-1400
> URL: https://issues.jboss.org/browse/DROOLS-1400
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Beta5
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Minor
>
> Same as [DROOLS-1399] but concerning comments; in full below:
> During incremental compilation the equivalent DRL file contains only a modification +within a comment+. Currently, this triggers the incremental compilation to rebuild all the resources associated in that DRL file anyway. Consequently, a rule in that DRL file might be actually UNchanged; but following the explanation above, it will match and fire again, like it's a new/modified rule.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (DROOLS-1401) File Descriptor LEAK in JBPM
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1401?page=com.atlassian.jira.plugi... ]
Mario Fusco moved JBPM-5408 to DROOLS-1401:
-------------------------------------------
Project: Drools (was: jBPM)
Key: DROOLS-1401 (was: JBPM-5408)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: core engine
(was: KieServer)
Affects Version/s: (was: jBPM 6.4.0.Final)
> File Descriptor LEAK in JBPM
> ----------------------------
>
> Key: DROOLS-1401
> URL: https://issues.jboss.org/browse/DROOLS-1401
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Ankit Jain
> Assignee: Maciej Swiderski
> Priority: Blocker
>
> we are using the JBPM 6.4 version and using Kie Deployment API lie-cie-6.4.0.jar for deploying the KJARs.
> API we are using is
> FluentKieModuleDeploymentHelper deplymenthelperObj = KieModuleDeploymentHelper.newFluentInstance()
> deplymenthelperObj .createKieJarAndDeployToMaven()
> In KieModuleDeploymentHelperImpl CLASS
> Method -- String convertFileToString(InputStream in)
> In this the stream is never closed... the File Descriptors starts leaking....
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (DROOLS-1401) File Descriptor LEAK in JBPM
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1401?page=com.atlassian.jira.plugi... ]
Mario Fusco reassigned DROOLS-1401:
-----------------------------------
Assignee: Mario Fusco (was: Maciej Swiderski)
> File Descriptor LEAK in JBPM
> ----------------------------
>
> Key: DROOLS-1401
> URL: https://issues.jboss.org/browse/DROOLS-1401
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Ankit Jain
> Assignee: Mario Fusco
>
> we are using the JBPM 6.4 version and using Kie Deployment API lie-cie-6.4.0.jar for deploying the KJARs.
> API we are using is
> FluentKieModuleDeploymentHelper deplymenthelperObj = KieModuleDeploymentHelper.newFluentInstance()
> deplymenthelperObj .createKieJarAndDeployToMaven()
> In KieModuleDeploymentHelperImpl CLASS
> Method -- String convertFileToString(InputStream in)
> In this the stream is never closed... the File Descriptors starts leaking....
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (DROOLS-1401) File Descriptor LEAK in JBPM
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1401?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1401:
--------------------------------
Priority: Major (was: Blocker)
> File Descriptor LEAK in JBPM
> ----------------------------
>
> Key: DROOLS-1401
> URL: https://issues.jboss.org/browse/DROOLS-1401
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Ankit Jain
> Assignee: Maciej Swiderski
>
> we are using the JBPM 6.4 version and using Kie Deployment API lie-cie-6.4.0.jar for deploying the KJARs.
> API we are using is
> FluentKieModuleDeploymentHelper deplymenthelperObj = KieModuleDeploymentHelper.newFluentInstance()
> deplymenthelperObj .createKieJarAndDeployToMaven()
> In KieModuleDeploymentHelperImpl CLASS
> Method -- String convertFileToString(InputStream in)
> In this the stream is never closed... the File Descriptors starts leaking....
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (DROOLS-1400) Comparison of DRL changes should not consider comments during incremental compilation
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-1400:
--------------------------------------
Summary: Comparison of DRL changes should not consider comments during incremental compilation
Key: DROOLS-1400
URL: https://issues.jboss.org/browse/DROOLS-1400
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.0.0.Beta5
Reporter: Matteo Mortari
Assignee: Matteo Mortari
Priority: Minor
Same as [DROOLS-1399] but concerning comments; in full below:
During incremental compilation the equivalent DRL file contains only a modification +within a comment+. Currently, this triggers the incremental compilation to rebuild all the resources associated in that DRL file anyway. Consequently, a rule in that DRL file might be actually UNchanged; but following the explanation above, it will match and fire again, like it's a new/modified rule.
--
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:
--------------------------------
Doesn't work either, as the following use case breaks it:
{noformat}
A: {A,B}
B: {B}
{noformat}
The merge view would be \{A,B\} and if coord A wants to install this new view in the cluster, the duplicate check would throw an exception.
> 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