[jira] [Commented] (OGNL-261) OgnlException with "source is null for getProperty" thrown when using compound expression
[
https://issues.apache.org/jira/browse/OGNL-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443611#comment-17443611
]
Pascal Davoust commented on OGNL-261:
-
Hi [~lukaszlenart] ,
Could you please confirm that the logic in {{ASTChain}} is correct and that the
exception must be thrown in this situation?
Of course, I can definitely provide a PR for this.
If we want to empower users to choose whether the stacktraces are suppressed or
not, what configuration mechanism would you recommend?
> OgnlException with "source is null for getProperty" thrown when using
> compound expression
> -
>
> Key: OGNL-261
> URL: https://issues.apache.org/jira/browse/OGNL-261
> Project: Commons OGNL
> Issue Type: Improvement
> Components: Core Runtime
>Reporter: Pascal Davoust
>Priority: Major
>
> Spin-off discussion from WW-5147 and related
> [https://github.com/apache/struts/pull/504] pull request.
> Whenever an OGNL expression compiles into an AST with compound node
> statements, the evaluation can result into a {{{}OgnlException("source is
> null for getProperty(null, "propertyName")"){}}}.
> This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext,
> Object)}} which uses the result of the current node as the source for the
> next node in the chain.
> If the result of the current node evaluation results into {{{}null{}}}, then
> the next node throws the exception.
> As mentioned in [https://github.com/apache/struts/pull/504], there is a
> question about whether this logic is by design or if there is something to
> investigate (I definitely lack background and OGNL knowledge to even guess).
> If this behavior is legitimate, it also turns out that this situation occurs
> a lot and the cost of building the exceptions with the stack traces is fairly
> noticeable: profiling the code while under load shows a significant amount of
> time spent building the stack traces.
> Depending on the outcome of the discussion above, would it make sense to
> envision to allow OGNL to throw these exceptions without the stack traces if
> configured so (which can be easily done from JDK 7 using the constructor
> taking the {{enableSuppression}} and {{writableStackTrace}} arguments - can
> also be achieved from older JDKs by overriding method {{fillInStackTrace()}}
> )?
> Note that a preliminary attempt showed that the cost of building these
> exceptions without the stack traces is virtually zero, making the exceptions
> totally painless and invisible (they appear no more while profiling).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (OGNL-261) OgnlException with "source is null for getProperty" thrown when using compound expression
[
https://issues.apache.org/jira/browse/OGNL-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443598#comment-17443598
]
Lukasz Lenart commented on OGNL-261:
Also you can post the same or open PR here [https://github.com/jkuhnert/ognl] -
thanks in advance!
> OgnlException with "source is null for getProperty" thrown when using
> compound expression
> -
>
> Key: OGNL-261
> URL: https://issues.apache.org/jira/browse/OGNL-261
> Project: Commons OGNL
> Issue Type: Improvement
> Components: Core Runtime
>Reporter: Pascal Davoust
>Priority: Major
>
> Spin-off discussion from WW-5147 and related
> [https://github.com/apache/struts/pull/504] pull request.
> Whenever an OGNL expression compiles into an AST with compound node
> statements, the evaluation can result into a {{{}OgnlException("source is
> null for getProperty(null, "propertyName")"){}}}.
> This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext,
> Object)}} which uses the result of the current node as the source for the
> next node in the chain.
> If the result of the current node evaluation results into {{{}null{}}}, then
> the next node throws the exception.
> As mentioned in [https://github.com/apache/struts/pull/504], there is a
> question about whether this logic is by design or if there is something to
> investigate (I definitely lack background and OGNL knowledge to even guess).
> If this behavior is legitimate, it also turns out that this situation occurs
> a lot and the cost of building the exceptions with the stack traces is fairly
> noticeable: profiling the code while under load shows a significant amount of
> time spent building the stack traces.
> Depending on the outcome of the discussion above, would it make sense to
> envision to allow OGNL to throw these exceptions without the stack traces if
> configured so (which can be easily done from JDK 7 using the constructor
> taking the {{enableSuppression}} and {{writableStackTrace}} arguments - can
> also be achieved from older JDKs by overriding method {{fillInStackTrace()}}
> )?
> Note that a preliminary attempt showed that the cost of building these
> exceptions without the stack traces is virtually zero, making the exceptions
> totally painless and invisible (they appear no more while profiling).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (OGNL-261) OgnlException with "source is null for getProperty" thrown when using compound expression
[
https://issues.apache.org/jira/browse/OGNL-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443590#comment-17443590
]
Lukasz Lenart commented on OGNL-261:
So the whole problem is to suppress the stack trace? I think when OGNL was
developed there were no way to do this or noone thought about the consequences.
If this is the whole change I opt for it!
[~davoustp] thanks a lot for your support!
> OgnlException with "source is null for getProperty" thrown when using
> compound expression
> -
>
> Key: OGNL-261
> URL: https://issues.apache.org/jira/browse/OGNL-261
> Project: Commons OGNL
> Issue Type: Improvement
> Components: Core Runtime
>Reporter: Pascal Davoust
>Priority: Major
>
> Spin-off discussion from WW-5147 and related
> [https://github.com/apache/struts/pull/504] pull request.
> Whenever an OGNL expression compiles into an AST with compound node
> statements, the evaluation can result into a {{{}OgnlException("source is
> null for getProperty(null, "propertyName")"){}}}.
> This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext,
> Object)}} which uses the result of the current node as the source for the
> next node in the chain.
> If the result of the current node evaluation results into {{{}null{}}}, then
> the next node throws the exception.
> As mentioned in [https://github.com/apache/struts/pull/504], there is a
> question about whether this logic is by design or if there is something to
> investigate (I definitely lack background and OGNL knowledge to even guess).
> If this behavior is legitimate, it also turns out that this situation occurs
> a lot and the cost of building the exceptions with the stack traces is fairly
> noticeable: profiling the code while under load shows a significant amount of
> time spent building the stack traces.
> Depending on the outcome of the discussion above, would it make sense to
> envision to allow OGNL to throw these exceptions without the stack traces if
> configured so (which can be easily done from JDK 7 using the constructor
> taking the {{enableSuppression}} and {{writableStackTrace}} arguments - can
> also be achieved from older JDKs by overriding method {{fillInStackTrace()}}
> )?
> Note that a preliminary attempt showed that the cost of building these
> exceptions without the stack traces is virtually zero, making the exceptions
> totally painless and invisible (they appear no more while profiling).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-dbcp] dependabot[bot] opened a new pull request #145: Bump spotbugs from 4.4.1 to 4.5.0
dependabot[bot] opened a new pull request #145: URL: https://github.com/apache/commons-dbcp/pull/145 Bumps [spotbugs](https://github.com/spotbugs/spotbugs) from 4.4.1 to 4.5.0. Release notes Sourced from https://github.com/spotbugs/spotbugs/releases;>spotbugs's releases. SpotBugs 4.5.0 CHANGELOG Changed Replace 分析 with 解析 in Japanese document (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1573;>#1573) https://github.com/KengoTODA;>@KengoTODA Add a section to document how to integrate find-sec-bugs into spotbugs-maven-plugin (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/540;>#540) https://github.com/luana-martins;>@luana-martins Bump gson from 2.8.8 to 2.8.9 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1784;>#1784) Changes related to dominators analysis in package edu.umd.cs.findbugs.classfile.engine.bcel (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1741;>#1741): https://github.com/gamesh411;>@gamesh411 DominatorsAnalysisFactory renamed to NonExceptionDominatorsAnalysisFactory (clarification) NonExceptionPostdominatorsAnalysisFactory renamed to NonExceptionPostDominatorsAnalysisFactory (spelling) NonImplicitExceptionDominatorsAnalysis introduced (API consistency) Added Rule DCN_NULLPOINTER_EXCEPTION covers catching NullPointerExceptions in accordance with SEI Cert rule https://wiki.sei.cmu.edu/confluence/display/java/ERR08-J.+Do+not+catch+NullPointerException+or+any+of+its+ancestors;>ERR08-J (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1740;>#1740) https://github.com/gamesh411;>@gamesh411 Multiple types of report can be generated in batch. Set multiple commandline options for report configuration like -html=report/spotbugs.html -xml:withMessages=report/spotbugs.xml. https://github.com/KengoTODA;>@KengoTODA New rule REFL_REFLECTION_INCREASES_ACCESSIBILITY_OF_CLASS to detect public methods instantiating a class they get in their parameter. This rule based on the SEI CERT rule SEC05-J. Do not use reflection to increase accessibility of classes, methods, or fields. (https://wiki.sei.cmu.edu/confluence/display/java/SEC05-J.+Do+not+use+reflection+to+increase+accessibility+of+classes%2C+methods%2C+or+fields;>#SEC05-J) https://github.com/baloghadamsoftware;>@baloghadamsoftware New detector FindOverridableMethodCall to detect invocation of overridable method in constructors (MC_OVERRIDABLE_METHOD_CALL_IN_CONSTRUCTOR) and clone() method (MC_OVERRIDABLE_METHOD_CALL_IN_CLONE), according to SEI CERT rules https://wiki.sei.cmu.edu/confluence/display/java/MET05-J.+Ensure+that+constructors+do+not+call+overridable+methods;>MET05-J. Ensure that constructors do not call overridable methods and https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88487921;>MET06-J. Do not invoke overridable methods in clone(). https://github.com/baloghadamsoftware;>@baloghadamsoftware https://spotbugs.readthedocs.io/pt_BR/latest/;>Translation of online manual to Brazilian Portuguese (PT-BR). https://github.com/luana-martins;>@luana-martins Fixed False negative about the rule ES_COMPARING_STRINGS_WITH_EQ (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1764;>#1764) https://github.com/KengoTODA;>@KengoTODA False negative about the rule IM_MULTIPLYING_RESULT_OF_IREM (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1498;>#1498)(https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1498;>spotbugs/spotbugs#1498) https://github.com/ecxia;>@ecxia Deprecated -output command line option is deprecated. Use command line options for report configuration like -xml=spotbugs.xml instead. CHECKSUM file checksum (sha256) spotbugs-4.5.0-javadoc.jar 6f11c4d1aa5ad3f77f8d63b7ded099547d2010ee725c6c1d4eb512735726ca69 spotbugs-4.5.0-sources.jar 4bf5daff85cf2e7fbc1b0950be87d7933f1bb80756cf9f55c534a63f07551eb9 spotbugs-4.5.0.tgz 327d5e36afa223737e871114e173c6f2d4543e22c6167bc7825001a752a3cf31 spotbugs-4.5.0.zip 988c43c5c36f3799fe9a0cf9714f95940a2d60764a9aa0af3e6ccc137106b97e spotbugs-annotations-4.5.0-javadoc.jar 76c580b054ce653658d747fcf8aa76d5934f119f2f988cec2e9feafb3f6b9bed spotbugs-annotations-4.5.0-sources.jar b338136e3e82d585348cde58a8fe3a678e16f51a35c31c1463e05fefef557aad spotbugs-annotations.jar 65199ea3fe5dc4d106e30ebf67a92c7c816da816563d75c8ea6da1f0ff662857 spotbugs-ant-4.5.0-javadoc.jar c12a84e031a3ec5a0fd405e1f696f8e32ddd4a43769eb8dd145b77383e0b5506 spotbugs-ant-4.5.0-sources.jar c74dec42c0ed0dd1ae02a7410d8e0f0dbbee23e8e7da4a21910863677fcdbc8e spotbugs-ant.jar b6e73b68e441c001dc42754c73b811625915ae9a759e1ed719df095b41f2979a spotbugs.jar
[GitHub] [commons-dbcp] dependabot[bot] closed pull request #141: Bump spotbugs from 4.4.1 to 4.4.2
dependabot[bot] closed pull request #141: URL: https://github.com/apache/commons-dbcp/pull/141 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbcp] dependabot[bot] commented on pull request #141: Bump spotbugs from 4.4.1 to 4.4.2
dependabot[bot] commented on pull request #141: URL: https://github.com/apache/commons-dbcp/pull/141#issuecomment-968532410 Superseded by #145. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (COMPRESS-589) 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while 1.20 not
[
https://issues.apache.org/jira/browse/COMPRESS-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Lee resolved COMPRESS-589.
Resolution: Not A Problem
> 1.21 throws a 'java.io.IOException: Truncated TAR archive' exception while
> 1.20 not
> ---
>
> Key: COMPRESS-589
> URL: https://issues.apache.org/jira/browse/COMPRESS-589
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.21
>Reporter: chen
>Priority: Major
>
> the bug happens when I use the TarArchiveInputStream to read bytes from the
> current tar archive entry.
> first of all, we ran into this issue on an *{color:#ff}Android
> device{color}*
> the trace shows as below
> {code:java}
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: java.io.IOException: Truncated
> TAR archive
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getActuallySkipped(TarArchiveInputStream.java:478)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.skipRecordPadding(TarArchiveInputStream.java:455)
> 08-27 14:39:18.657 10633 10963 W System.err: at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:367)
> {code}
> but when i downgrade to 1.20, the exception will not show again, so I think
> it is a bug in the new version
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-pool] coveralls commented on pull request #116: Check blockWhenExhausted in hasBorrowWaiters
coveralls commented on pull request #116: URL: https://github.com/apache/commons-pool/pull/116#issuecomment-968465121 [](https://coveralls.io/builds/44253594) Coverage decreased (-0.03%) to 84.995% when pulling **9809f6f7735ae242002ed50142c7389ebb655a06 on Cp-John:branch-refine-returnObject** into **90eab321ad32868dc80c42d7d08ac086d44146a0 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-pool] Cp-John opened a new pull request #116: Check blockWhenExhausted in hasBorrowWaiters
Cp-John opened a new pull request #116: URL: https://github.com/apache/commons-pool/pull/116 Hi, I am a user of Apache commons pool2. I found that the performance of `returnObject(K)` would be improved a lot if I do a pre-check `getBlockWhenExhausted()` in `hasBorrowWaiters()`. The flame graphs are shared in the following link for comparison. Thank you! https://drive.google.com/drive/folders/11NLW4nzGMxxPwO_xjUa_nnZGciMrkpfn?usp=sharing -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (POOL-393) BaseGenericObjectPool.jmxRegister may cost too much time
[
https://issues.apache.org/jira/browse/POOL-393?focusedWorklogId=681274=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-681274
]
ASF GitHub Bot logged work on POOL-393:
---
Author: ASF GitHub Bot
Created on: 14/Nov/21 21:31
Start Date: 14/Nov/21 21:31
Worklog Time Spent: 10m
Work Description: psteitz commented on pull request #115:
URL: https://github.com/apache/commons-pool/pull/115#issuecomment-968367279
Sorry to waffle on this, but lets hold on merging this. I like the current
naming behavior and if we change it, it might break tools that assume the
naming sequence has no gaps in it. Let me fix this
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 681274)
Time Spent: 50m (was: 40m)
> BaseGenericObjectPool.jmxRegister may cost too much time
>
>
> Key: POOL-393
> URL: https://issues.apache.org/jira/browse/POOL-393
> Project: Commons Pool
> Issue Type: Improvement
>Affects Versions: 2.4.2
>Reporter: Shichao Yuan
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
>
> When creating many pools, I find that it tasks too much time to register jmx.
> In the code, the ObjectName's postfix always starts with 1, so many
> InstanceAlreadyExistsExceptions may be thrown before registered successfully.
> Maybe a random number is a better choice, or a atomic long.
> {quote}private ObjectName jmxRegister(BaseObjectPoolConfig config,
> String jmxNameBase, String jmxNamePrefix) {
> ObjectName objectName = null;
> MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
> int i = 1;
> boolean registered = false;
> String base = config.getJmxNameBase();
> if (base == null)
> Unknown macro: \{ base = jmxNameBase; }
> while (!registered) {
> try {
> ObjectName objName;
> // Skip the numeric suffix for the first pool in case there is
> // only one so the names are cleaner.
> if (i == 1)
> Unknown macro: \{ objName = new ObjectName(base + jmxNamePrefix); }
> else
> Unknown macro: \{ objName = new ObjectName(base + jmxNamePrefix + i); }
> mbs.registerMBean(this, objName);
> objectName = objName;
> registered = true;
> } catch (MalformedObjectNameException e) {
> if (BaseObjectPoolConfig.DEFAULT_JMX_NAME_PREFIX.equals(
> jmxNamePrefix) && jmxNameBase.equals(base))
> Unknown macro: \{ // Shouldn't happen. Skip registration if it does.
> registered = true; }
> else
> Unknown macro: \{ // Must be an invalid name. Use the defaults instead.
> jmxNamePrefix = BaseObjectPoolConfig.DEFAULT_JMX_NAME_PREFIX; base =
> jmxNameBase; }
> } catch (InstanceAlreadyExistsException e)
> Unknown macro: \{ // Increment the index and try again i++; }
> catch (MBeanRegistrationException e)
> Unknown macro: \{ // Shouldn't happen. Skip registration if it does.
> registered = true; }
> catch (NotCompliantMBeanException e)
> }
> return objectName;
> }
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-pool] psteitz commented on pull request #115: POOL-393 slow pool creation due to JMX latency
psteitz commented on pull request #115: URL: https://github.com/apache/commons-pool/pull/115#issuecomment-968367279 Sorry to waffle on this, but lets hold on merging this. I like the current naming behavior and if we change it, it might break tools that assume the naming sequence has no gaps in it. Let me fix this -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (POOL-393) BaseGenericObjectPool.jmxRegister may cost too much time
[
https://issues.apache.org/jira/browse/POOL-393?focusedWorklogId=681275=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-681275
]
ASF GitHub Bot logged work on POOL-393:
---
Author: ASF GitHub Bot
Created on: 14/Nov/21 21:31
Start Date: 14/Nov/21 21:31
Worklog Time Spent: 10m
Work Description: psteitz closed pull request #115:
URL: https://github.com/apache/commons-pool/pull/115
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 681275)
Time Spent: 1h (was: 50m)
> BaseGenericObjectPool.jmxRegister may cost too much time
>
>
> Key: POOL-393
> URL: https://issues.apache.org/jira/browse/POOL-393
> Project: Commons Pool
> Issue Type: Improvement
>Affects Versions: 2.4.2
>Reporter: Shichao Yuan
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
>
> When creating many pools, I find that it tasks too much time to register jmx.
> In the code, the ObjectName's postfix always starts with 1, so many
> InstanceAlreadyExistsExceptions may be thrown before registered successfully.
> Maybe a random number is a better choice, or a atomic long.
> {quote}private ObjectName jmxRegister(BaseObjectPoolConfig config,
> String jmxNameBase, String jmxNamePrefix) {
> ObjectName objectName = null;
> MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
> int i = 1;
> boolean registered = false;
> String base = config.getJmxNameBase();
> if (base == null)
> Unknown macro: \{ base = jmxNameBase; }
> while (!registered) {
> try {
> ObjectName objName;
> // Skip the numeric suffix for the first pool in case there is
> // only one so the names are cleaner.
> if (i == 1)
> Unknown macro: \{ objName = new ObjectName(base + jmxNamePrefix); }
> else
> Unknown macro: \{ objName = new ObjectName(base + jmxNamePrefix + i); }
> mbs.registerMBean(this, objName);
> objectName = objName;
> registered = true;
> } catch (MalformedObjectNameException e) {
> if (BaseObjectPoolConfig.DEFAULT_JMX_NAME_PREFIX.equals(
> jmxNamePrefix) && jmxNameBase.equals(base))
> Unknown macro: \{ // Shouldn't happen. Skip registration if it does.
> registered = true; }
> else
> Unknown macro: \{ // Must be an invalid name. Use the defaults instead.
> jmxNamePrefix = BaseObjectPoolConfig.DEFAULT_JMX_NAME_PREFIX; base =
> jmxNameBase; }
> } catch (InstanceAlreadyExistsException e)
> Unknown macro: \{ // Increment the index and try again i++; }
> catch (MBeanRegistrationException e)
> Unknown macro: \{ // Shouldn't happen. Skip registration if it does.
> registered = true; }
> catch (NotCompliantMBeanException e)
> }
> return objectName;
> }
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-pool] psteitz closed pull request #115: POOL-393 slow pool creation due to JMX latency
psteitz closed pull request #115: URL: https://github.com/apache/commons-pool/pull/115 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (POOL-393) BaseGenericObjectPool.jmxRegister may cost too much time
[
https://issues.apache.org/jira/browse/POOL-393?focusedWorklogId=681268=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-681268
]
ASF GitHub Bot logged work on POOL-393:
---
Author: ASF GitHub Bot
Created on: 14/Nov/21 21:15
Start Date: 14/Nov/21 21:15
Worklog Time Spent: 10m
Work Description: psteitz commented on pull request #115:
URL: https://github.com/apache/commons-pool/pull/115#issuecomment-968364926
As noted in POOL-393 JIRA, this PR does not exactly preserve the sequence of
names assigned to pools. Current code reuses suffiixes when pools are
unregistered, the code in the PR does not.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 681268)
Time Spent: 40m (was: 0.5h)
> BaseGenericObjectPool.jmxRegister may cost too much time
>
>
> Key: POOL-393
> URL: https://issues.apache.org/jira/browse/POOL-393
> Project: Commons Pool
> Issue Type: Improvement
>Affects Versions: 2.4.2
>Reporter: Shichao Yuan
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
>
> When creating many pools, I find that it tasks too much time to register jmx.
> In the code, the ObjectName's postfix always starts with 1, so many
> InstanceAlreadyExistsExceptions may be thrown before registered successfully.
> Maybe a random number is a better choice, or a atomic long.
> {quote}private ObjectName jmxRegister(BaseObjectPoolConfig config,
> String jmxNameBase, String jmxNamePrefix) {
> ObjectName objectName = null;
> MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
> int i = 1;
> boolean registered = false;
> String base = config.getJmxNameBase();
> if (base == null)
> Unknown macro: \{ base = jmxNameBase; }
> while (!registered) {
> try {
> ObjectName objName;
> // Skip the numeric suffix for the first pool in case there is
> // only one so the names are cleaner.
> if (i == 1)
> Unknown macro: \{ objName = new ObjectName(base + jmxNamePrefix); }
> else
> Unknown macro: \{ objName = new ObjectName(base + jmxNamePrefix + i); }
> mbs.registerMBean(this, objName);
> objectName = objName;
> registered = true;
> } catch (MalformedObjectNameException e) {
> if (BaseObjectPoolConfig.DEFAULT_JMX_NAME_PREFIX.equals(
> jmxNamePrefix) && jmxNameBase.equals(base))
> Unknown macro: \{ // Shouldn't happen. Skip registration if it does.
> registered = true; }
> else
> Unknown macro: \{ // Must be an invalid name. Use the defaults instead.
> jmxNamePrefix = BaseObjectPoolConfig.DEFAULT_JMX_NAME_PREFIX; base =
> jmxNameBase; }
> } catch (InstanceAlreadyExistsException e)
> Unknown macro: \{ // Increment the index and try again i++; }
> catch (MBeanRegistrationException e)
> Unknown macro: \{ // Shouldn't happen. Skip registration if it does.
> registered = true; }
> catch (NotCompliantMBeanException e)
> }
> return objectName;
> }
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-pool] psteitz commented on pull request #115: POOL-393 slow pool creation due to JMX latency
psteitz commented on pull request #115: URL: https://github.com/apache/commons-pool/pull/115#issuecomment-968364926 As noted in POOL-393 JIRA, this PR does not exactly preserve the sequence of names assigned to pools. Current code reuses suffiixes when pools are unregistered, the code in the PR does not. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (STATISTICS-48) Remove isSupportConnected from the distribution interfaces
Alex Herbert created STATISTICS-48:
--
Summary: Remove isSupportConnected from the distribution interfaces
Key: STATISTICS-48
URL: https://issues.apache.org/jira/browse/STATISTICS-48
Project: Apache Commons Statistics
Issue Type: Improvement
Components: distribution
Affects Versions: 1.0
Reporter: Alex Herbert
Fix For: 1.0
Both the discrete and continuous distribution have a property in the interface:
{code:java}
/**
* Indicates whether the support is connected, i.e. whether
* all values between the lower and upper bound of the support
* are included in the support.
*
* @return whether the support is connected.
*/
boolean isSupportConnected();
{code}
This is only ever true for all distributions.
The functions dates back as far as Commons Math 2 with no apparent use.
There is no facility to determine what values within the support are not valid.
So
the property isSupportConnect alone cannot be used to determine if the
value you are interested in is part of the support. E.g. This would require
a isSupported(double x) method for continuous distributions.
I propose to remove this unused property from the distribution
interfaces prior to the initial 1.0 release to avoid this redundant
method.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (COMMONSRDF-80) Jena version upgrade
[ https://issues.apache.org/jira/browse/COMMONSRDF-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Soroka closed COMMONSRDF-80. - Resolution: Abandoned > Jena version upgrade > > > Key: COMMONSRDF-80 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-80 > Project: Apache Commons RDF > Issue Type: Task > Components: jena >Affects Versions: 0.5.0 >Reporter: Adam Soroka >Assignee: Adam Soroka >Priority: Major > Fix For: 0.6.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Commons RDF is currently using Jena 3.5.0, which is several versions behind > current (3.9.0). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (COMMONSRDF-80) Jena version upgrade
[ https://issues.apache.org/jira/browse/COMMONSRDF-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443393#comment-17443393 ] Adam Soroka commented on COMMONSRDF-80: --- Thank you [~mbrandizi] . > Jena version upgrade > > > Key: COMMONSRDF-80 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-80 > Project: Apache Commons RDF > Issue Type: Task > Components: jena >Affects Versions: 0.5.0 >Reporter: Adam Soroka >Assignee: Adam Soroka >Priority: Major > Fix For: 0.6.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Commons RDF is currently using Jena 3.5.0, which is several versions behind > current (3.9.0). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (POOL-393) BaseGenericObjectPool.jmxRegister may cost too much time
[
https://issues.apache.org/jira/browse/POOL-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443194#comment-17443194
]
Phil Steitz edited comment on POOL-393 at 11/14/21, 4:55 PM:
-
I verified that with the 2.11.1 code it can take 9+ seconds to register 1000
pools due to all of the exception processing. Changing to use an AtomicLong to
keep track of the last used suffix reduces it by at least 10x. Proposed fix is
in [https://github.com/apache/commons-pool/pull/115].
I should note that the PR changes behavior in some cases. Current code
"reuses" suffixes when pools are unregistered. After the PR, new pools always
get new suffixes.
was (Author: psteitz):
I verified that with the 2.11.1 code it can take 9+ seconds to register 1000
pools due to all of the exception processing. Changing to use an AtomicLong to
keep track of the last used suffix reduces it by at least 10x. Proposed fix is
in https://github.com/apache/commons-pool/pull/115.
> BaseGenericObjectPool.jmxRegister may cost too much time
>
>
> Key: POOL-393
> URL: https://issues.apache.org/jira/browse/POOL-393
> Project: Commons Pool
> Issue Type: Improvement
>Affects Versions: 2.4.2
>Reporter: Shichao Yuan
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
>
> When creating many pools, I find that it tasks too much time to register jmx.
> In the code, the ObjectName's postfix always starts with 1, so many
> InstanceAlreadyExistsExceptions may be thrown before registered successfully.
> Maybe a random number is a better choice, or a atomic long.
> {quote}private ObjectName jmxRegister(BaseObjectPoolConfig config,
> String jmxNameBase, String jmxNamePrefix) {
> ObjectName objectName = null;
> MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
> int i = 1;
> boolean registered = false;
> String base = config.getJmxNameBase();
> if (base == null)
> Unknown macro: \{ base = jmxNameBase; }
> while (!registered) {
> try {
> ObjectName objName;
> // Skip the numeric suffix for the first pool in case there is
> // only one so the names are cleaner.
> if (i == 1)
> Unknown macro: \{ objName = new ObjectName(base + jmxNamePrefix); }
> else
> Unknown macro: \{ objName = new ObjectName(base + jmxNamePrefix + i); }
> mbs.registerMBean(this, objName);
> objectName = objName;
> registered = true;
> } catch (MalformedObjectNameException e) {
> if (BaseObjectPoolConfig.DEFAULT_JMX_NAME_PREFIX.equals(
> jmxNamePrefix) && jmxNameBase.equals(base))
> Unknown macro: \{ // Shouldn't happen. Skip registration if it does.
> registered = true; }
> else
> Unknown macro: \{ // Must be an invalid name. Use the defaults instead.
> jmxNamePrefix = BaseObjectPoolConfig.DEFAULT_JMX_NAME_PREFIX; base =
> jmxNameBase; }
> } catch (InstanceAlreadyExistsException e)
> Unknown macro: \{ // Increment the index and try again i++; }
> catch (MBeanRegistrationException e)
> Unknown macro: \{ // Shouldn't happen. Skip registration if it does.
> registered = true; }
> catch (NotCompliantMBeanException e)
> }
> return objectName;
> }
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (OGNL-261) OgnlException with "source is null for getProperty" thrown when using compound expression
[
https://issues.apache.org/jira/browse/OGNL-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Davoust updated OGNL-261:
Description:
Spin-off discussion from WW-5147 and related
[https://github.com/apache/struts/pull/504] pull request.
Whenever an OGNL expression compiles into an AST with compound node statements,
the evaluation can result into a {{{}OgnlException("source is null for
getProperty(null, "propertyName")"){}}}.
This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext,
Object)}} which uses the result of the current node as the source for the next
node in the chain.
If the result of the current node evaluation results into {{{}null{}}}, then
the next node throws the exception.
As mentioned in [https://github.com/apache/struts/pull/504], there is a
question about whether this logic is by design or if there is something to
investigate (I definitely lack background and OGNL knowledge to even guess).
If this behavior is legitimate, it also turns out that this situation occurs a
lot and the cost of building the exceptions with the stack traces is fairly
noticeable: profiling the code while under load shows a significant amount of
time spent building the stack traces.
Depending on the outcome of the discussion above, would it make sense to
envision to allow OGNL to throw these exceptions without the stack traces if
configured so (which can be easily done from JDK 7 using the constructor taking
the {{enableSuppression}} and {{writableStackTrace}} arguments - can also be
achieved from older JDKs by overriding method {{fillInStackTrace()}} )?
Note that a preliminary attempt showed that the cost of building these
exceptions without the stack traces is virtually zero, making the exceptions
totally painless and invisible (they appear no more while profiling).
was:
Spin-off discussion from WW-5147 and related
[https://github.com/apache/struts/pull/504] pull request.
Whenever an OGNL expression compiles into an AST with compound node statements,
the evaluation can result into a {{{}OgnlException("source is null for
getProperty(null, "propertyName")"){}}}.
This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext,
Object)}} which uses the result of the current node as the source for the next
node in the chain.
If the result of the current node evaluation results into {{{}null{}}}, then
the next node throws the exception.
As mentioned in [https://github.com/apache/struts/pull/504], there is a
question about whether this logic is by design of if there is something to
investigate (I definitely lack background and OGNL knowledge to even guess).
If this behavior is legitimate, it also turns out that this situation occurs a
lot and the cost of building the exceptions with the stack traces is fairly
noticeable: profiling the code while under load shows a significant amount of
time spent building the stack traces.
Depending on the outcome of the discussion above, would it make sense to
envision to allow OGNL to throw these exceptions without the stack traces if
configured so (which can be easily done from JDK 7 using the constructor taking
the {{enableSuppression}} and {{writableStackTrace}} arguments - can also be
achieved from older JDKs by overriding method {{fillInStackTrace()}} )?
Note that a preliminary attempt showed that the cost of building these
exceptions without the stack traces is virtually zero, making the exceptions
totally painless and invisible (they appear no more while profiling).
> OgnlException with "source is null for getProperty" thrown when using
> compound expression
> -
>
> Key: OGNL-261
> URL: https://issues.apache.org/jira/browse/OGNL-261
> Project: Commons OGNL
> Issue Type: Improvement
> Components: Core Runtime
>Reporter: Pascal Davoust
>Priority: Major
>
> Spin-off discussion from WW-5147 and related
> [https://github.com/apache/struts/pull/504] pull request.
> Whenever an OGNL expression compiles into an AST with compound node
> statements, the evaluation can result into a {{{}OgnlException("source is
> null for getProperty(null, "propertyName")"){}}}.
> This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext,
> Object)}} which uses the result of the current node as the source for the
> next node in the chain.
> If the result of the current node evaluation results into {{{}null{}}}, then
> the next node throws the exception.
> As mentioned in [https://github.com/apache/struts/pull/504], there is a
> question about whether this logic is by design or if there is something to
> investigate (I definitely lack background and OGNL knowledge to even guess).
> If this behavior is legitimate, it also turns out that this
[jira] [Created] (OGNL-261) OgnlException with "source is null for getProperty" thrown when using compound expression
Pascal Davoust created OGNL-261:
---
Summary: OgnlException with "source is null for getProperty"
thrown when using compound expression
Key: OGNL-261
URL: https://issues.apache.org/jira/browse/OGNL-261
Project: Commons OGNL
Issue Type: Improvement
Components: Core Runtime
Reporter: Pascal Davoust
Spin-off discussion from WW-5147 and related
[https://github.com/apache/struts/pull/504] pull request.
Whenever an OGNL expression compiles into an AST with compound node statements,
the evaluation can result into a {{{}OgnlException("source is null for
getProperty(null, "propertyName")"){}}}.
This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext,
Object)}} which uses the result of the current node as the source for the next
node in the chain.
If the result of the current node evaluation results into {{{}null{}}}, then
the next node throws the exception.
As mentioned in [https://github.com/apache/struts/pull/504], there is a
question about whether this logic is by design of if there is something to
investigate (I definitely lack background and OGNL knowledge to even guess).
If this behavior is legitimate, it also turns out that this situation occurs a
lot and the cost of building the exceptions with the stack traces is fairly
noticeable: profiling the code while under load shows a significant amount of
time spent building the stack traces.
Depending on the outcome of the discussion above, would it make sense to
envision to allow OGNL to throw these exceptions without the stack traces if
configured so (which can be easily done from JDK 7 using the constructor taking
the {{enableSuppression}} and {{writableStackTrace}} arguments - can also be
achieved from older JDKs by overriding method {{fillInStackTrace()}} )?
Note that a preliminary attempt showed that the cost of building these
exceptions without the stack traces is virtually zero, making the exceptions
totally painless and invisible (they appear no more while profiling).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-lang] ejums commented on pull request #831: feat: list2tree method add
ejums commented on pull request #831: URL: https://github.com/apache/commons-lang/pull/831#issuecomment-968249898 > -1: No idea what this does as the doc is just one short sentence but it seems like some hyper specific collection processing method not generally useful. Feel free to elucidate. Also, instead of opening and closing PR after PR with the same code, please commit and optionally squash to the same PR. 1. This method is a general method for converting the flattened list of any object type into a tree list, supporting operations such as computing hierarchy and judging whether it is the top and last level (refer to the corresponding test case for details of calling) 2. As for the problem of multiple PR, it is because the jdoc format is incompatible and failed to pass the detection. I will pay attention to it later -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
