[jira] [Updated] (JCS-170) [JCache] cache name can make JMX registration fail
[ https://issues.apache.org/jira/browse/JCS-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-170: --- Summary: [JCache] cache name can make JMX registration fail (was: cache name can make JMX registration fail) > [JCache] cache name can make JMX registration fail > -- > > Key: JCS-170 > URL: https://issues.apache.org/jira/browse/JCS-170 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCS-170) cache name can make JMX registration fail
[ https://issues.apache.org/jira/browse/JCS-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-170. Resolution: Fixed > cache name can make JMX registration fail > - > > Key: JCS-170 > URL: https://issues.apache.org/jira/browse/JCS-170 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCS-170) cache name can make JMX registration fail
Romain Manni-Bucau created JCS-170: -- Summary: cache name can make JMX registration fail Key: JCS-170 URL: https://issues.apache.org/jira/browse/JCS-170 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang issue #224: [LANG-1306] Add nullToEmpty method in StringUtils
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/224 [](https://coveralls.io/builds/9478410) Coverage increased (+0.0004%) to 94.363% when pulling **cee84c01f986415dd2873d3623f67080d6470c09 on arbasha:master** into **021e4dfb501a8e6e5810a4f0efe1267810d62d64 on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1306) Add nullToEmpty method in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15789455#comment-15789455
]
ASF GitHub Bot commented on LANG-1306:
--
Github user coveralls commented on the issue:
https://github.com/apache/commons-lang/pull/224
[](https://coveralls.io/builds/9478410)
Coverage increased (+0.0004%) to 94.363% when pulling
**cee84c01f986415dd2873d3623f67080d6470c09 on arbasha:master** into
**021e4dfb501a8e6e5810a4f0efe1267810d62d64 on apache:master**.
> Add nullToEmpty method in StringUtils
> -
>
> Key: LANG-1306
> URL: https://issues.apache.org/jira/browse/LANG-1306
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Arshad Basha
>Priority: Minor
> Fix For: 3.6
>
>
> The nullToEmpty method will convert null reference to empty string, for non
> null str it will return the str as it is (i.e. without striping or removing
> space)
> This method doesn't strips white-space nor removes control characters from
> the start and end of the input string like StringUtils.stripToEmpty and
> StringUtils.trimToEmpty methods.
> This method will allow us to replace common code patterns like the following
> from client side code:
> 1) if(str == null) { str = ""; }
> 2) return str == null ? "" : str;
> Examples:
> assertEquals("", StringUtils.nullToEmpty(null));
> assertEquals("", StringUtils.nullToEmpty(""));
> assertEquals("abc", StringUtils.nullToEmpty("abc"));
> assertEquals(" abc", StringUtils.nullToEmpty(" abc"));
> assertEquals("abc ", StringUtils.nullToEmpty("abc "));
> assertEquals("abc\t", StringUtils.nullToEmpty("abc\t"));
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1306) Add nullToEmpty method in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15789451#comment-15789451
]
ASF GitHub Bot commented on LANG-1306:
--
GitHub user arbasha opened a pull request:
https://github.com/apache/commons-lang/pull/224
[LANG-1306] Add nullToEmpty method in StringUtils
[Jira Link](https://issues.apache.org/jira/browse/LANG-1306)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/arbasha/commons-lang master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-lang/pull/224.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #224
commit cee84c01f986415dd2873d3623f67080d6470c09
Author: Basha
Date: 2016-12-31T12:12:00Z
Added method nullToEmpty in StringUtils.
> Add nullToEmpty method in StringUtils
> -
>
> Key: LANG-1306
> URL: https://issues.apache.org/jira/browse/LANG-1306
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Arshad Basha
>Priority: Minor
> Fix For: 3.6
>
>
> The nullToEmpty method will convert null reference to empty string, for non
> null str it will return the str as it is (i.e. without striping or removing
> space)
> This method doesn't strips white-space nor removes control characters from
> the start and end of the input string like StringUtils.stripToEmpty and
> StringUtils.trimToEmpty methods.
> This method will allow us to replace common code patterns like the following
> from client side code:
> 1) if(str == null) { str = ""; }
> 2) return str == null ? "" : str;
> Examples:
> assertEquals("", StringUtils.nullToEmpty(null));
> assertEquals("", StringUtils.nullToEmpty(""));
> assertEquals("abc", StringUtils.nullToEmpty("abc"));
> assertEquals(" abc", StringUtils.nullToEmpty(" abc"));
> assertEquals("abc ", StringUtils.nullToEmpty("abc "));
> assertEquals("abc\t", StringUtils.nullToEmpty("abc\t"));
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] commons-lang pull request #224: [LANG-1306] Add nullToEmpty method in String...
GitHub user arbasha opened a pull request: https://github.com/apache/commons-lang/pull/224 [LANG-1306] Add nullToEmpty method in StringUtils [Jira Link](https://issues.apache.org/jira/browse/LANG-1306) You can merge this pull request into a Git repository by running: $ git pull https://github.com/arbasha/commons-lang master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/224.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #224 commit cee84c01f986415dd2873d3623f67080d6470c09 Author: Basha Date: 2016-12-31T12:12:00Z Added method nullToEmpty in StringUtils. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (LANG-1306) Add nullToEmpty method in StringUtils
Arshad Basha created LANG-1306:
--
Summary: Add nullToEmpty method in StringUtils
Key: LANG-1306
URL: https://issues.apache.org/jira/browse/LANG-1306
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Arshad Basha
Priority: Minor
Fix For: 3.6
The nullToEmpty method will convert null reference to empty string, for non
null str it will return the str as it is (i.e. without striping or removing
space)
This method doesn't strips white-space nor removes control characters from the
start and end of the input string like StringUtils.stripToEmpty and
StringUtils.trimToEmpty methods.
This method will allow us to replace common code patterns like the following
from client side code:
1) if(str == null) { str = ""; }
2) return str == null ? "" : str;
Examples:
assertEquals("", StringUtils.nullToEmpty(null));
assertEquals("", StringUtils.nullToEmpty(""));
assertEquals("abc", StringUtils.nullToEmpty("abc"));
assertEquals(" abc", StringUtils.nullToEmpty(" abc"));
assertEquals("abc ", StringUtils.nullToEmpty("abc "));
assertEquals("abc\t", StringUtils.nullToEmpty("abc\t"));
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (BCEL-267) Race conditions on static fields in BranchHandle and InstructionHandle
[
https://issues.apache.org/jira/browse/BCEL-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15789243#comment-15789243
]
Stephan Herrmann edited comment on BCEL-267 at 12/31/16 9:39 AM:
-
I finally found the time to create a test case that effectively triggers the
problem (see attached
[^BCEL267--Race-conditions-on-static-fields-in-BranchH.patch]).
The core issue is: two threads with no shared data create an instruction list
each, and add lots of instructions to their respective list. After some random
- but not very big - number of iterations, one of the instruction lists will be
corrupt, having a next or prev pointer pointing into the other list, which can
surface with one of 3 possible symptoms:
- NullPointerException in {{InstructionList.getInstructionHandles(..)}}
- instruction list does not contain the expected instructions
- instruction list has corrupt link structure: {{ih.getNext().getPrev() != ih}}
Re-run the test (_without the changes in InstructionHandle and BranchHandle_
:)) several times to see all three symptoms (it may even randomly succeed, but
that should be rare).
While running other tests I observed a ClassCastException in
org.apache.bcel.PLSETestCase.testB262() even on unmodified sources.
Given that the entire business of the bogusly shared {{ih_list}} and
{{bh_list}} is performance optimization I took a quick look at the output of
{{PerformanceTest}} but difference looked like normal white noise, i.e.: no
indication at a performance regression due to the fix.
was (Author: sherrmann):
I finally found the time to create a test case that effectively triggers the
problem (see attached
[^BCEL267--Race-conditions-on-static-fields-in-BranchH.patch]).
The core issue is: two threads with no shared data create an instruction list
each, and add lots of instructions to their respective list. After some random
- but not very big - number of iterations, one of the instruction lists will be
corrupt, having a next or prev pointer pointing into the other list, which can
surface with one of 3 possible symptoms:
- NullPointerException in {{InstructionList.getInstructionHandles(..)}}
- instruction list does not contain the expected instructions
- instruction list has corrupt link structure: {{ih.getNext().getPrev() != ih}}
Re-run the test several times to see all three symptoms (it may even randomly
succeed, but that should be rare).
While running other tests I observed a ClassCastException in
org.apache.bcel.PLSETestCase.testB262() even on unmodified sources.
Given that the entire business of the bogusly shared {{ih_list}} and
{{bh_list}} is performance optimization I took a quick look at the output of
{{PerformanceTest}} but difference looked like normal white noise, i.e.: no
indication at a performance regression due to the fix.
> Race conditions on static fields in BranchHandle and InstructionHandle
> --
>
> Key: BCEL-267
> URL: https://issues.apache.org/jira/browse/BCEL-267
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 5.2
>Reporter: Stephan Herrmann
> Attachments:
> BCEL267--Race-conditions-on-static-fields-in-BranchH.patch
>
>
> I have observed race conditions causing NullPointerException like this
> {code}java.lang.NullPointerException
> at
> org.apache.bcel.generic.InstructionList.getInstructionHandles(InstructionList.java:1021)
> at
> org.apache.bcel.generic.InstructionList.findHandle(InstructionList.java:141)
> at org.apache.bcel.generic.MethodGen.(MethodGen.java:194)
> {code}
> In the debugger I could verify that concurrent access to the fields
> {{BranchHandle.bh_list}} or {{InstructionHandle.ih_list}} can cause
> corruption of those lists.
> I succeeded to make the exception less frequent by adding synchronized
> blocks, but still the exception could be observed. I concluded that for safe
> protection the fields would need to be made volatile, which in the end might
> actually defeat their original purpose of optimization.
> I have since then run with a patched version of BCEL, where those static
> fields were simply removed and new Handles were created on every request.
> This variant finally was free of the race condition.
> Seeing activity towards a 6.0 release, I'd appreciate if this change could be
> incorporated.
> The original bug tracking my experiments can be found in Eclipse bugzilla:
> https://bugs.eclipse.org/344350
> The modified classes (based on 5.2) can be found here:
> -
> http://git.eclipse.org/c/objectteams/org.eclipse.objectteams.git/tree/plugins/org.eclipse.objectteams.otre/bcelpatchsrc/org/apache/bcel/generic
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (BCEL-267) Race conditions on static fields in BranchHandle and InstructionHandle
[
https://issues.apache.org/jira/browse/BCEL-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15789243#comment-15789243
]
Stephan Herrmann edited comment on BCEL-267 at 12/31/16 9:37 AM:
-
I finally found the time to create a test case that effectively triggers the
problem (see attached
[^BCEL267--Race-conditions-on-static-fields-in-BranchH.patch]).
The core issue is: two threads with no shared data create an instruction list
each, and add lots of instructions to their respective list. After some random
- but not very big - number of iterations, one of the instruction lists will be
corrupt, having a next or prev pointer pointing into the other list, which can
surface with one of 3 possible symptoms:
- NullPointerException in {{InstructionList.getInstructionHandles(..)}}
- instruction list does not contain the expected instructions
- instruction list has corrupt link structure: {{ih.getNext().getPrev() != ih}}
Re-run the test several times to see all three symptoms (it may even randomly
succeed, but that should be rare).
While running other tests I observed a ClassCastException in
org.apache.bcel.PLSETestCase.testB262() even on unmodified sources.
Given that the entire business of the bogusly shared {{ih_list}} and
{{bh_list}} is performance optimization I took a quick look at the output of
{{PerformanceTest}} but difference looked like normal white noise, i.e.: no
indication at a performance regression due to the fix.
was (Author: sherrmann):
I finally found the time to create a test case that effectively triggers the
problem (see attached patch).
The core issue is: two threads with no shared data create an instruction list
each, and add lots of instructions to their respective list. After some random
- but not very big - number of iterations, one of the instruction lists will be
corrupt, having a next or prev pointer pointing into the other list, which can
surface with one of 3 possible symptoms:
- NullPointerException in {{InstructionList.getInstructionHandles(..)}}
- instruction list does not contain the expected instructions
- instruction list has corrupt link structure: {{ih.getNext().getPrev() != ih}}
Re-run the test several times to see all three symptoms (it may even randomly
succeed, but that should be rare).
While running other tests I observed a ClassCastException in
org.apache.bcel.PLSETestCase.testB262() even on unmodified sources.
Given that the entire business of the bogusly shared {{ih_list}} and
{{bh_list}} is performance optimization I took a quick look at the output of
{{PerformanceTest}} but difference looked like normal white noise, i.e.: no
indication at a performance regression due to the fix.
> Race conditions on static fields in BranchHandle and InstructionHandle
> --
>
> Key: BCEL-267
> URL: https://issues.apache.org/jira/browse/BCEL-267
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 5.2
>Reporter: Stephan Herrmann
> Attachments:
> BCEL267--Race-conditions-on-static-fields-in-BranchH.patch
>
>
> I have observed race conditions causing NullPointerException like this
> {code}java.lang.NullPointerException
> at
> org.apache.bcel.generic.InstructionList.getInstructionHandles(InstructionList.java:1021)
> at
> org.apache.bcel.generic.InstructionList.findHandle(InstructionList.java:141)
> at org.apache.bcel.generic.MethodGen.(MethodGen.java:194)
> {code}
> In the debugger I could verify that concurrent access to the fields
> {{BranchHandle.bh_list}} or {{InstructionHandle.ih_list}} can cause
> corruption of those lists.
> I succeeded to make the exception less frequent by adding synchronized
> blocks, but still the exception could be observed. I concluded that for safe
> protection the fields would need to be made volatile, which in the end might
> actually defeat their original purpose of optimization.
> I have since then run with a patched version of BCEL, where those static
> fields were simply removed and new Handles were created on every request.
> This variant finally was free of the race condition.
> Seeing activity towards a 6.0 release, I'd appreciate if this change could be
> incorporated.
> The original bug tracking my experiments can be found in Eclipse bugzilla:
> https://bugs.eclipse.org/344350
> The modified classes (based on 5.2) can be found here:
> -
> http://git.eclipse.org/c/objectteams/org.eclipse.objectteams.git/tree/plugins/org.eclipse.objectteams.otre/bcelpatchsrc/org/apache/bcel/generic
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BCEL-267) Race conditions on static fields in BranchHandle and InstructionHandle
[
https://issues.apache.org/jira/browse/BCEL-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Herrmann updated BCEL-267:
--
Attachment: BCEL267--Race-conditions-on-static-fields-in-BranchH.patch
I finally found the time to create a test case that effectively triggers the
problem (see attached patch).
The core issue is: two threads with no shared data create an instruction list
each, and add lots of instructions to their respective list. After some random
- but not very big - number of iterations, one of the instruction lists will be
corrupt, having a next or prev pointer pointing into the other list, which can
surface with one of 3 possible symptoms:
- NullPointerException in {{InstructionList.getInstructionHandles(..)}}
- instruction list does not contain the expected instructions
- instruction list has corrupt link structure: {{ih.getNext().getPrev() != ih}}
Re-run the test several times to see all three symptoms (it may even randomly
succeed, but that should be rare).
While running other tests I observed a ClassCastException in
org.apache.bcel.PLSETestCase.testB262() even on unmodified sources.
Given that the entire business of the bogusly shared {{ih_list}} and
{{bh_list}} is performance optimization I took a quick look at the output of
{{PerformanceTest}} but difference looked like normal white noise, i.e.: no
indication at a performance regression due to the fix.
> Race conditions on static fields in BranchHandle and InstructionHandle
> --
>
> Key: BCEL-267
> URL: https://issues.apache.org/jira/browse/BCEL-267
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 5.2
>Reporter: Stephan Herrmann
> Attachments:
> BCEL267--Race-conditions-on-static-fields-in-BranchH.patch
>
>
> I have observed race conditions causing NullPointerException like this
> {code}java.lang.NullPointerException
> at
> org.apache.bcel.generic.InstructionList.getInstructionHandles(InstructionList.java:1021)
> at
> org.apache.bcel.generic.InstructionList.findHandle(InstructionList.java:141)
> at org.apache.bcel.generic.MethodGen.(MethodGen.java:194)
> {code}
> In the debugger I could verify that concurrent access to the fields
> {{BranchHandle.bh_list}} or {{InstructionHandle.ih_list}} can cause
> corruption of those lists.
> I succeeded to make the exception less frequent by adding synchronized
> blocks, but still the exception could be observed. I concluded that for safe
> protection the fields would need to be made volatile, which in the end might
> actually defeat their original purpose of optimization.
> I have since then run with a patched version of BCEL, where those static
> fields were simply removed and new Handles were created on every request.
> This variant finally was free of the race condition.
> Seeing activity towards a 6.0 release, I'd appreciate if this change could be
> incorporated.
> The original bug tracking my experiments can be found in Eclipse bugzilla:
> https://bugs.eclipse.org/344350
> The modified classes (based on 5.2) can be found here:
> -
> http://git.eclipse.org/c/objectteams/org.eclipse.objectteams.git/tree/plugins/org.eclipse.objectteams.otre/bcelpatchsrc/org/apache/bcel/generic
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
