[GitHub] [commons-pool] psteitz edited a comment on pull request #67: Implement AbandonedConfig for GenericKeyedObjectPool
psteitz edited a comment on pull request #67: URL: https://github.com/apache/commons-pool/pull/67#issuecomment-803663669 Sorry for taking so long to review this. Looks good to me. Thanks and nice work. I only have one comment. The iteration in the top loop in removeAbandoned is over poolMap.entrySet. This set may be modified during execution of the loop (due to adding / dropping keyed pools). I am not sure the behavior will be consistent / predictable in all cases. Could be I am wrong on this in which case this comment can be ignored. It might be better to take some kind of snapshot at the top of the loop. I don't think any additional sync is needed (beyond what you have using the victims' monitors), and if the loop behaves predictably (skipping removals, possibly missing adds), the current code is OK. Missing adds is not likely a problem since instances in new pools are not likely to have timed out and skipping removals similarly is no problem, since pools don't get dropped unless they are empty. I am just worried about strange things happening due to behavior being undefined. -- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-pool] psteitz commented on pull request #67: Implement AbandonedConfig for GenericKeyedObjectPool
psteitz commented on pull request #67: URL: https://github.com/apache/commons-pool/pull/67#issuecomment-803663669 Sorry for taking so long to review this. Looks good to me. Thanks and nice work. I only have one comment. The iteration in the top loop in removeAbandoned is over poolMap.entrySet. This set is may be modified during execution of the loop (due to adding / dropping keyed pools). I am not sure the behavior will be consistent / predictable in all cases. Could be I am wrong on this in which case this commend can be ignored. It might be better to take some kind of snapshot at the top of the loop. I don't think any additional sync is needed (beyond what you have using the victims' monitors), and if the loop behaves predictably (skipping removals, possibly missing adds), the current code is OK. Missing adds is not likely a problem since instances in new pools are not likely to have timed out and skipping removals similarly is no problem, since pools don't get dropped unless they are empty. I am just worried about strange things happening due to behavior being undefined. -- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (GEOMETRY-116) OSGi Headers Incorrect
Matt Juntunen created GEOMETRY-116:
--
Summary: OSGi Headers Incorrect
Key: GEOMETRY-116
URL: https://issues.apache.org/jira/browse/GEOMETRY-116
Project: Apache Commons Geometry
Issue Type: Bug
Reporter: Matt Juntunen
The OSGi headers are not correct and prevent export of several required
packages. For example, the commons-geometry-core module only exports the
{{o.a.c.geometry.core}} package and not any of the {{partitioning}},
{{partitioning.bsp}}, or {{precision}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-geometry] laeubi opened a new pull request #136: Fix OSGi Header + add method for direct transformation
laeubi opened a new pull request #136: URL: https://github.com/apache/commons-geometry/pull/136 As mentioned in the mailing list the OSGi headers currently do not work because of missing exports. It would also be good to have an "applyDirect" method to prevent massive object creation when transforming x/y arrays. -- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (COMPRESS-573) Configuration error in Remote Desktop with Apache guacamole
[ https://issues.apache.org/jira/browse/COMPRESS-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305663#comment-17305663 ] Stefan Bodewig commented on COMPRESS-573: - [~junaidmehmood] this issue tracker is about Apache Commons Compress, you seem to have selected the wrong project. Apart from that I agree with Michael your issue seems to be one that should use the project's user support resources, see https://guacamole.apache.org/support/ > Configuration error in Remote Desktop with Apache guacamole > --- > > Key: COMPRESS-573 > URL: https://issues.apache.org/jira/browse/COMPRESS-573 > Project: Commons Compress > Issue Type: Bug >Reporter: Junaid Mehmood >Priority: Critical > > I cant connect my virtual machine with Apache guacamole through remote > desktop. please help me in this regards. -- This message was sent by Atlassian Jira (v8.3.4#803005)
