[JBoss JIRA] (DROOLS-446) Literals may be ambiguously resolved as classes on case insensitive filesystems
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-446?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-446:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Literals may be ambiguously resolved as classes on case insensitive filesystems
> -------------------------------------------------------------------------------
>
> Key: DROOLS-446
> URL: https://issues.jboss.org/browse/DROOLS-446
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final
> Reporter: Davide Sottara
> Assignee: Mario Fusco
> Fix For: 6.1.0.CR1
>
>
> When a candidate class literal is analyzed, e.g. :
> {code}
> declare Foo
> f1 : Bar = new Bar()
> f2 : boolean = false
> end
> {code}
> "Bar" is tentatively resolved (twice) and its f.q.n. is substituted as needed.
> However, even "false" is tentatively resolved as well.
> On a case insensitive filesytems, the presence of a class named False will cause the literal to be resolved erroneously.
> The same will happen to "true" and "null"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (DROOLS-446) Literals may be ambiguously resolved as classes on case insensitive filesystems
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-446?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-446.
--------------------------------
Resolution: Done
> Literals may be ambiguously resolved as classes on case insensitive filesystems
> -------------------------------------------------------------------------------
>
> Key: DROOLS-446
> URL: https://issues.jboss.org/browse/DROOLS-446
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final
> Reporter: Davide Sottara
> Assignee: Mario Fusco
> Fix For: 6.1.0.CR1
>
>
> When a candidate class literal is analyzed, e.g. :
> {code}
> declare Foo
> f1 : Bar = new Bar()
> f2 : boolean = false
> end
> {code}
> "Bar" is tentatively resolved (twice) and its f.q.n. is substituted as needed.
> However, even "false" is tentatively resolved as well.
> On a case insensitive filesytems, the presence of a class named False will cause the literal to be resolved erroneously.
> The same will happen to "true" and "null"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2198) Remote Naming throws the same exception for different causes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2198:
-----------------------------------------------
Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1053426|https://bugzilla.redhat.com/show_bug.cgi?id=1053426] from ON_QA to VERIFIED
> Remote Naming throws the same exception for different causes
> ------------------------------------------------------------
>
> Key: WFLY-2198
> URL: https://issues.jboss.org/browse/WFLY-2198
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
>
> A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported.
> We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception.
> If all the the servers specified are not not running:
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
> at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
> If one of the servers is running, but the client's username/password are incorrect
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
> at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1805) OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1805?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1805:
-------------------------------------------
I'm putting together a PR which adds more TRACE logging to these merge tests while the merge is happening. Diagnosing merge problems would benefit from GMS, MERGE2 and PING/TCPPING trace logging, when these protocols are present in the stack.
> OverlappingMergeTest testMergeWithDifferentPartitions fails to create correct merged view
> -----------------------------------------------------------------------------------------
>
> Key: JGRP-1805
> URL: https://issues.jboss.org/browse/JGRP-1805
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> This test does the following:
> - creates four channels a,b,c,d
> - injects views A: {A,C,B}, B:{A,C,B}, C:{A,C,B} and D: {B,A,C,D}
> - injects a merge event in each of channels A,B,C,D representing these four views
> - checks that all channels have the final view of size 4
> The test fails intermittently on RHEL, with the same failure each time:
> {noformat}
> 181595 [DEBUG] GMS: - A: installing view [A|2] [A]
> [testng] 181596 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|2]
> [testng] 181866 [TRACE] GMS: - view [A|3] [] is empty: will not multicast it (last view)
> [testng]
> [testng] -------------------------------------------------------------------
> [testng] GMS: address=A, cluster=OverlappingMergeTest, physical address=10.16.94.42:27199
> [testng] -------------------------------------------------------------------
> [testng] 184954 [TRACE] GMS: - A: no initial members discovered: creating group as first member
> [testng] 184954 [DEBUG] GMS: - A: installing view [A|0] [A]
> [testng] 184955 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> [testng]
> [testng] -------------------------------------------------------------------
> [testng] GMS: address=B, cluster=OverlappingMergeTest, physical address=10.16.94.42:27200
> [testng] -------------------------------------------------------------------
> [testng] 184961 [TRACE] GMS: - B: initial_mbrs are A
> [testng] 184961 [DEBUG] GMS: - election results: {A=1}
> [testng] 184961 [DEBUG] GMS: - sending JOIN(B) to A
> [testng] 185013 [TRACE] GMS: - A: new members=[B], suspected=[], leaving=[], new view: [A|1] [A, B]
> [testng] 185014 [TRACE] GMS: - A: mcasting view [A|1] [A, B] (2 mbrs)
> [testng]
> [testng] 185025 [DEBUG] GMS: - A: installing view [A|1] [A, B]
> [testng] 185026 [TRACE] GMS: - A: received all 1 ACKs from members for view [A|1]
> [testng] 185055 [TRACE] GMS: - B: JOIN-RSP=[A|1] [A, B] [size=2]
> [testng]
> [testng]
> [testng] 185055 [DEBUG] GMS: - B: installing view [A|1] [A, B]
> [testng] 185057 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|1]
> [testng]
> [testng] -------------------------------------------------------------------
> [testng] GMS: address=C, cluster=OverlappingMergeTest, physical address=10.16.94.42:27201
> [testng] -------------------------------------------------------------------
> [testng] 185064 [TRACE] GMS: - C: initial_mbrs are B A
> [testng] 185064 [DEBUG] GMS: - election results: {A=2}
> [testng] 185064 [DEBUG] GMS: - sending JOIN(C) to A
> [testng] 185108 [TRACE] GMS: - A: new members=[C], suspected=[], leaving=[], new view: [A|2] [A, B, C]
> [testng] 185108 [TRACE] GMS: - A: mcasting view [A|2] [A, B, C] (3 mbrs)
> [testng]
> [testng] 185117 [DEBUG] GMS: - A: installing view [A|2] [A, B, C]
> [testng] 185118 [DEBUG] GMS: - B: installing view [A|2] [A, B, C]
> [testng] 185119 [TRACE] GMS: - A: received all 2 ACKs from members for view [A|2]
> [testng] 185148 [TRACE] GMS: - C: JOIN-RSP=[A|2] [A, B, C] [size=3]
> [testng]
> [testng]
> [testng] 185149 [DEBUG] GMS: - C: installing view [A|2] [A, B, C]
> [testng] 185151 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|2]
> [testng]
> [testng] -------------------------------------------------------------------
> [testng] GMS: address=D, cluster=OverlappingMergeTest, physical address=10.16.94.42:27202
> [testng] -------------------------------------------------------------------
> [testng] 185164 [TRACE] GMS: - D: initial_mbrs are B C A
> [testng] 185164 [DEBUG] GMS: - election results: {A=3}
> [testng] 185164 [DEBUG] GMS: - sending JOIN(D) to A
> [testng] 185203 [TRACE] GMS: - A: new members=[D], suspected=[], leaving=[], new view: [A|3] [A, B, C, D]
> [testng] 185203 [TRACE] GMS: - A: mcasting view [A|3] [A, B, C, D] (4 mbrs)
> [testng]
> [testng] 185210 [DEBUG] GMS: - A: installing view [A|3] [A, B, C, D]
> [testng] 185211 [DEBUG] GMS: - B: installing view [A|3] [A, B, C, D]
> [testng] 185211 [DEBUG] GMS: - C: installing view [A|3] [A, B, C, D]
> [testng] 185213 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|3]
> [testng] 185242 [TRACE] GMS: - D: JOIN-RSP=[A|3] [A, B, C, D] [size=4]
> [testng]
> [testng]
> [testng] 185242 [DEBUG] GMS: - D: installing view [A|3] [A, B, C, D]
> [testng] 185242 [TRACE] GMS: - A: received all ACKs (1) from joiners for view [A|3]
> [testng]
> [testng] ==== Injecting view [A|4] [A, C, B] into A, B and C ====
> [testng] 185243 [DEBUG] GMS: - A: installing view [A|4] [A, C, B]
> [testng] 185243 [DEBUG] GMS: - B: installing view [A|4] [A, C, B]
> [testng] 185244 [DEBUG] GMS: - C: installing view [A|4] [A, C, B]
> [testng]
> [testng] ==== Injecting view [B|4] [B, A, C, D] into D ====
> [testng]
> [testng] 185245 [DEBUG] GMS: - D: installing view [B|4] [B, A, C, D]
> [testng] A: [A|4] [A, C, B]
> [testng] B: [A|4] [A, C, B]
> [testng] C: [A|4] [A, C, B]
> [testng] D: [B|4] [B, A, C, D]
> [testng]
> [testng] ==== Injecting a merge event into A, B, C and D====
> [testng] 185251 [TRACE] GMS: - A: got merge response from A, merge_id=A::3, merge data is sender=A, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (0)], A: [4 (4)]
> [testng] 185253 [TRACE] GMS: - B: queue is suspended; request MERGE(4 views) is discarded
> [testng] 185255 [TRACE] GMS: - C: queue is suspended; request MERGE(4 views) is discarded
> [testng] 185255 [TRACE] GMS: - A: got merge response from B, merge_id=A::3, merge data is sender=B, view=[A|4] [A, C, B], digest=C: [0 (0)], B: [0 (1)], A: [4 (4)]
> [testng] 190286 [TRACE] GMS: - A: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
> [testng]
> [testng] 190286 [TRACE] GMS: - B: mcasting view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B] (3 mbrs)
> [testng]
> [testng] 190317 [DEBUG] GMS: - A: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
> [testng] 190318 [DEBUG] GMS: - B: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
> [testng] 190318 [DEBUG] GMS: - C: installing view MergeView::[A|5] [A, B, C], subgroups=[A|4] [A, C, B], [A|4] [A, C, B]
> [testng] 190320 [TRACE] GMS: - A: received all 3 ACKs from members for view [A|5]
> [testng] 190320 [TRACE] GMS: - B: received all 3 ACKs from members for view [A|5]
> [testng] A: [A|5] [A, B, C] (coord=true)
> [testng] B: [A|5] [A, B, C] (coord=false)
> [testng] C: [A|5] [A, B, C] (coord=false)
> [testng] D: [B|4] [B, A, C, D] (coord=false)
> [testng] 195277 [DEBUG] GMS: - D: sending LEAVE request to B
> [testng] FAIL: [1] org.jgroups.tests.OverlappingMergeTest.testMergeWithDifferentPartitions()
> {noformat}
> Whenever this test fails, I see that the queues are suspended on the initial merge attempt.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1722) Improve performance of ENCRYPT protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1722 at 3/5/14 7:35 AM:
--------------------------------------------------------
When a sync RPC is invoked, the following encrypt/decrypt phases are done:
# The request is sent and *encrypted* on the way down
# The request is received and *decrypted* on the way up, either as a single message or as part of a batch
# The response is sent and *encrypted* on the way down
# The response is received and *descrypted* on the way up, either as a single message or as part of a batch
That's a total of 2 encryptions and 2 decryptions for invoking a single sync RPC. I measure the avg cost of encryption and decryption and the total of 1 encrypt/decrypt is ca. 25 us, which means an RPC uses roughly 50us for encryption and decryption. That's a theoretical total of 20'000 max RPCs / sec, but of course this doesn't take the other protocols and processing of the request at the receipient and the response at the caller into account.
*Without* encryption, I get (on the same box) ca. 16'000 RPCs/node avg, *with* encryption I get ca. 8'500. I've come to the conclusion that this is the cost of encryption that has to be paid. If we could make encryption faster, e.g. by picking smaller key sizes, perhaps this could be improved, but parallelization (see above) didn't help.
Note that the numbers for UPerf are higher on cluster01-08 (8 nodes): ca. 21'000 sync RPCs/sec with encryption and 41'000 without.
was (Author: belaban):
When a sync RPC is invoked, the following encrypt/decrypt phases are done:
# The request is sent and *encrypted* on the way down
# The request is received and *decrypted* on the way up, either as a single message or as part of a batch
# The response is sent and *encrypted* on the way down
# The response is received and *descrypted* on the way up, either as a single message or as part of a batch
That's a total of 2 encryptions and 2 decryptions for invoking a single sync RPC. I measure the avg cost of encryption and decryption and the total of 1 encrypt/decrypt is ca. 25 us, which means an RPC uses roughly 50us for encryption and decryption. That's a theoretical total of 20'000 max RPCs / sec, but of course this doesn't take the other protocols and processing of the request at the receipient and the response at the caller into account.
*Without* encryption, I get (on the same box) ca. 16'000 RPCs/node avg, *with* encryption I get ca. 8'500. I've come to the conclusion that this is the cost of encryption that has to be paid. If we could make encryption faster, e.g. by picking smaller key sizes, perhaps this could be improved, but parallelization (see above) didn't help.
Note that the numbers for UPerf and higher on cluster01-08 (8 nodes): ca. 21'000 sync RPCs/sec with encryption and 41'000 without.
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
> Key: JGRP-1722
> URL: https://issues.jboss.org/browse/JGRP-1722
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.4
> Reporter: Martin Gencur
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads.
> It would be great if we could improve the performance of ENCRYPT protocol.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1722) Improve performance of ENCRYPT protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1722 at 3/5/14 7:35 AM:
--------------------------------------------------------
When a sync RPC is invoked, the following encrypt/decrypt phases are done:
# The request is sent and *encrypted* on the way down
# The request is received and *decrypted* on the way up, either as a single message or as part of a batch
# The response is sent and *encrypted* on the way down
# The response is received and *descrypted* on the way up, either as a single message or as part of a batch
That's a total of 2 encryptions and 2 decryptions for invoking a single sync RPC. I measure the avg cost of encryption and decryption and the total of 1 encrypt/decrypt is ca. 25 us, which means an RPC uses roughly 50us for encryption and decryption. That's a theoretical total of 20'000 max RPCs / sec, but of course this doesn't take the other protocols and processing of the request at the receipient and the response at the caller into account.
*Without* encryption, I get (on the same box) ca. 16'000 RPCs/node avg, *with* encryption I get ca. 8'500. I've come to the conclusion that this is the cost of encryption that has to be paid. If we could make encryption faster, e.g. by picking smaller key sizes, perhaps this could be improved, but parallelization (see above) didn't help.
Note that the numbers for UPerf and higher on cluster01-08 (8 nodes): ca. 21'000 sync RPCs/sec with encryption and 41'000 without.
was (Author: belaban):
When a sync RPC is invoked, the following encrypt/decrypt phases are done:
# The request is sent and *encrypted* on the way down
# The request is received and *decrypted* on the way up, either as a single message or as part of a batch
# The response is sent and *encrypted* on the way down
# The response is received and *descrypted* on the way up, either as a single message or as part of a batch
That's a total of 2 encryptions and 2 decryptions for invoking a single sync RPC. I measure the avg cost of encryption and decryption and the total of 1 encrypt/decrypt is ca. 25 us, which means an RPC uses roughly 50us for encryption and decryption. That's a theoretical total of 20'000 max RPCs / sec, but of course this doesn't take the other protocols and processing of the request at the receipient and the response at the caller into account.
*Without* encryption, I get (on the same box) ca. 16'000 RPCs/node avg, *with* encryption I get ca. 8'500. I've come to the conclusion that this is the cost of encryption that has to be paid. If we could make encryption faster, e.g. by picking smaller key sizes, perhaps this could be improved, but parallelization (see above) didn't help.
Note that the numbers for UPerf and higher on cluster01-08 (8 nodes): ca. 20'000 sync RPCs/sec with encryption and 38'000 without.
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
> Key: JGRP-1722
> URL: https://issues.jboss.org/browse/JGRP-1722
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.4
> Reporter: Martin Gencur
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads.
> It would be great if we could improve the performance of ENCRYPT protocol.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months