[jira] [Commented] (MATH-1441) SimpleRegression#getSlopeConfidenceInterval recalculates t distribution on every call
[
https://issues.apache.org/jira/browse/MATH-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341976#comment-16341976
]
Max Aller commented on MATH-1441:
-
I concur that constructing the TDistribution object isn't the bottleneck here –
it's the `inverseCumulativeProbability` calculation immediately after that's
expensive. So...an effective caching solution will also need to encompass that
calculation. Though generating 1M+ TDistribution objects, as in my test case,
doesn't help.
Benchmark-wise, after dropping the executions from 3M to 1M for my sanity's
sake, the execution performance improved from 9.873s to 9.600s with caching – a
modest ~3% improvement. So I agree rolling back was the right call.
The right approach, IMO, is for there to be some subsystem/class for lazily
calculating and storing these quasi-constants like these, and use those
throughout the codebase as it made sense. I might be interested in contributing
something like that if you're interested – what's the minimum JVM version
you're targeting in Commons Math 4.0? I've also subscribed to the Commons
Developer ML.
I'm also attaching a picture of my VisualVM's Sampler with my little benchmark
running, at the end.
Oh, and lastly, thanks for looking at the issue and taking a stab at the
solution! Always nice, and sometimes a pleasant surprise, to work with people
who care about their open-source software.
---
!visualvm screenshot.png!
> SimpleRegression#getSlopeConfidenceInterval recalculates t distribution on
> every call
> -
>
> Key: MATH-1441
> URL: https://issues.apache.org/jira/browse/MATH-1441
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.6.1
> Environment: Java 8, Linux x64.
>Reporter: Max Aller
>Priority: Minor
> Labels: performance
> Attachments: visualvm screenshot.png
>
>
> SimpleRegression#getSlopeConfidenceInterval, when called a lot (on the other
> of 100k or 1M times), is surprisingly slow - 3M calls, on my 3rd gen i7
> machine, takes *75 seconds*. This is primarily because recalculating the
> inverse cumulative probability, and reconstructing the TDistribution object
> itself, is somewhat expensive, entailing a lot of `log` and `sqrt` and
> iteration and all that stuff.
> The confidence interval is based on two values - *n* and *alpha*. I'd posit
> that alpha will _usually_ be one of a very small set of values, and n, well,
> at least in my case, I'm always calling this method with the same number of
> data points - a moving window of time-series data. But I recognize n might be
> all over the place for some users.
> In any event, I strongly believe some level of caching would greatly benefit
> the users of Commons Math. I've forked my own version of
> getSlopeConfidenceInterval that uses caching. Here's a test case
> demonstrating that:
> {code:java}
> class SlowRegressionsTest {
> @Test
> void slow() {
> SimpleRegression simpleRegression = new SimpleRegression();
> simpleRegression.addData(0.0, 0.0);
> simpleRegression.addData(1.0, 1.0);
> simpleRegression.addData(2.0, 2.0);
> long start = System.currentTimeMillis();
> for (int i = 0; i < 3_000_000; i++) {
> simpleRegression.getSlopeConfidenceInterval();
> }
> long duration = System.currentTimeMillis() - start;
> System.out.printf("`slow` took %dms%n", duration);
> }
> @Test
> void fast() {
> SimpleRegression simpleRegression = new SimpleRegression();
> simpleRegression.addData(0.0, 0.0);
> simpleRegression.addData(1.0, 1.0);
> simpleRegression.addData(2.0, 2.0);
> long start = System.currentTimeMillis();
> for (int i = 0; i < 3_000_000; i++) {
>
> SimpleRegressionUtilsKt.fastGetSlopeConfidenceInterval(simpleRegression);
> }
> long duration = System.currentTimeMillis() - start;
> System.out.printf("`fast` took %dms%n", duration);
> }
> }{code}
> which prints out
> {noformat}
> `fast` took 159ms
> `slow` took 75304ms{noformat}
> Nearly 500x faster - 53ns/call. My particular solution is written in Kotlin
> for Java 8, so not of direct relevance to you, but here it is:
> {code:java}
> package math
> import org.apache.commons.math3.distribution.TDistribution
> import org.apache.commons.math3.exception.OutOfRangeException
> import org.apache.commons.math3.exception.util.LocalizedFormats
> import org.apache.commons.math3.stat.regression.SimpleRegression
> import java.util.concurrent.ConcurrentHashMap
> @JvmOverloads
> fun SimpleRegression.fastGetSlopeConfidenceInterval(alpha: Double = 0.05):
> Double {
> if (n < 3) {
> return Double.NaN
> }
> if (alpha
[jira] [Updated] (MATH-1441) SimpleRegression#getSlopeConfidenceInterval recalculates t distribution on every call
[
https://issues.apache.org/jira/browse/MATH-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Aller updated MATH-1441:
Attachment: visualvm screenshot.png
> SimpleRegression#getSlopeConfidenceInterval recalculates t distribution on
> every call
> -
>
> Key: MATH-1441
> URL: https://issues.apache.org/jira/browse/MATH-1441
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.6.1
> Environment: Java 8, Linux x64.
>Reporter: Max Aller
>Priority: Minor
> Labels: performance
> Attachments: visualvm screenshot.png
>
>
> SimpleRegression#getSlopeConfidenceInterval, when called a lot (on the other
> of 100k or 1M times), is surprisingly slow - 3M calls, on my 3rd gen i7
> machine, takes *75 seconds*. This is primarily because recalculating the
> inverse cumulative probability, and reconstructing the TDistribution object
> itself, is somewhat expensive, entailing a lot of `log` and `sqrt` and
> iteration and all that stuff.
> The confidence interval is based on two values - *n* and *alpha*. I'd posit
> that alpha will _usually_ be one of a very small set of values, and n, well,
> at least in my case, I'm always calling this method with the same number of
> data points - a moving window of time-series data. But I recognize n might be
> all over the place for some users.
> In any event, I strongly believe some level of caching would greatly benefit
> the users of Commons Math. I've forked my own version of
> getSlopeConfidenceInterval that uses caching. Here's a test case
> demonstrating that:
> {code:java}
> class SlowRegressionsTest {
> @Test
> void slow() {
> SimpleRegression simpleRegression = new SimpleRegression();
> simpleRegression.addData(0.0, 0.0);
> simpleRegression.addData(1.0, 1.0);
> simpleRegression.addData(2.0, 2.0);
> long start = System.currentTimeMillis();
> for (int i = 0; i < 3_000_000; i++) {
> simpleRegression.getSlopeConfidenceInterval();
> }
> long duration = System.currentTimeMillis() - start;
> System.out.printf("`slow` took %dms%n", duration);
> }
> @Test
> void fast() {
> SimpleRegression simpleRegression = new SimpleRegression();
> simpleRegression.addData(0.0, 0.0);
> simpleRegression.addData(1.0, 1.0);
> simpleRegression.addData(2.0, 2.0);
> long start = System.currentTimeMillis();
> for (int i = 0; i < 3_000_000; i++) {
>
> SimpleRegressionUtilsKt.fastGetSlopeConfidenceInterval(simpleRegression);
> }
> long duration = System.currentTimeMillis() - start;
> System.out.printf("`fast` took %dms%n", duration);
> }
> }{code}
> which prints out
> {noformat}
> `fast` took 159ms
> `slow` took 75304ms{noformat}
> Nearly 500x faster - 53ns/call. My particular solution is written in Kotlin
> for Java 8, so not of direct relevance to you, but here it is:
> {code:java}
> package math
> import org.apache.commons.math3.distribution.TDistribution
> import org.apache.commons.math3.exception.OutOfRangeException
> import org.apache.commons.math3.exception.util.LocalizedFormats
> import org.apache.commons.math3.stat.regression.SimpleRegression
> import java.util.concurrent.ConcurrentHashMap
> @JvmOverloads
> fun SimpleRegression.fastGetSlopeConfidenceInterval(alpha: Double = 0.05):
> Double {
> if (n < 3) {
> return Double.NaN
> }
> if (alpha >= 1 || alpha <= 0) {
> throw OutOfRangeException(
> LocalizedFormats.SIGNIFICANCE_LEVEL,
> alpha, 0, 1
> )
> }
> // No advertised NotStrictlyPositiveException here - will return NaN above
> // PATCH: use cached inverse cumulative probability
> return slopeStdErr * getInverseCumulativeProbability(n, alpha)
> }
> private val cache = ConcurrentHashMap()
> private data class Key(val n: Long, val alpha: Double)
> private fun getInverseCumulativeProbability(n: Long, alpha: Double): Double =
> cache.getOrPut(Key(n, alpha)) {
> TDistribution((n - 2).toDouble()).inverseCumulativeProbability(1.0 -
> alpha / 2.0)
> }
> {code}
> Limitations: 1. Kotlin, 2. ConcurrentHashMap is unbounded here.
> I don't know how/if Commons Math does caching elsewhere, but it'd sure be
> handy here, I believe. What are your thoughts?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341887#comment-16341887
]
Matthew McGillis commented on NET-650:
--
If InetSocketAddress acts as I have indicated then if someone wants to add the
feature of using a local mapping over a remote mapping they can easily add it
simply by passing the connect the locally mapped name.
InetSocketAddress simply passes IP's through as does the proxy so its easy to
do on top of a InetSocketAddress base.
However without InetSocketAddress we have no way to get a remote name properly
resolved.
So I think this could be very close it would be interesting to see if just
making this InetSocketAddress change in the Common-Net socket code passes all
existing tests. If it does then it fixes this bug at no cost to any existing
functionality.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341858#comment-16341858
]
Matthew McGillis commented on NET-650:
--
> Yes, of course, but AFAICT that is buried deep (in the native code ?)
All that happens on the command line is system properties are set. Any code can
get a system property value.
Agree this needs more work.
I think if you substitute InetSocketAddress in the correct place all your
existing regression tests will still pass. Plus it will now support the command
line. How things behave in edge cases is worth testing but my guess is that
InetSocketAddress probably does what I have suggested. Which is to use the
remote name mapping. I think it would be a fairly unusual situation that a
local DNS infrastructure knows about a proxy remote infrastructure. But I could
see that as a nice configurable feature.
This also leaves investigation/testing in how the previous ticket
implementation of proxy support interacts with all of this.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341849#comment-16341849
]
Sebb commented on NET-650:
--
bq. Maybe if it doesn't exist remotely then look locally.
You only find out if the remote has the definition once you connect to it, so a
fall back would require retrying the connection.
bq. some code does [k]now about the proxy
Yes, of course, but AFAICT that is buried deep (in the native code ?)
Like I wrote, this needs more work and probably some additional options before
it can be implemented.
However you do have a simple work-round which you can use until a proper
solution is developed.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (NUMBERS-52) Incomplete beta function I(x, a, b) is inaccurate for large values of a and/or b
[
https://issues.apache.org/jira/browse/NUMBERS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated NUMBERS-52:
--
Description:
This was first reported in MATH-718. The result of the current implementation
of the incomplete beta function I(x, a, b) is inaccurate when a and/or b are
large-ish.
I've skimmed through [slatec|http://www.netlib.org/slatec/fnlib/betai.f], GSL,
[Boost|http://www.boost.org/doc/libs/1_38_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/sf_beta/ibeta_function.html]
as well as NR. At first sight, neither uses the same method to compute this
function. I think [TOMS-708|http://www.netlib.org/toms/708] is probably the
best option.
_Issue moved from MATH project on January 27, 2018 (concerned implementation
was moved to module {{commons-numbers-gamma}} of "Commons Numbers")._
was:
This was first reported in MATH-718. The result of the current implementation
of the incomplete beta function I(x, a, b) is inaccurate when a and/or b are
large-ish.
I've skimmed through [slatec|http://www.netlib.org/slatec/fnlib/betai.f], GSL,
[Boost|http://www.boost.org/doc/libs/1_38_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/sf_beta/ibeta_function.html]
as well as NR. At first sight, neither uses the same method to compute this
function. I think [TOMS-708|http://www.netlib.org/toms/708] is probably the
best option.
> Incomplete beta function I(x, a, b) is inaccurate for large values of a
> and/or b
>
>
> Key: NUMBERS-52
> URL: https://issues.apache.org/jira/browse/NUMBERS-52
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Sébastien Brisard
>Priority: Major
> Labels: special-functions
>
> This was first reported in MATH-718. The result of the current implementation
> of the incomplete beta function I(x, a, b) is inaccurate when a and/or b are
> large-ish.
> I've skimmed through [slatec|http://www.netlib.org/slatec/fnlib/betai.f],
> GSL,
> [Boost|http://www.boost.org/doc/libs/1_38_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/sf_beta/ibeta_function.html]
> as well as NR. At first sight, neither uses the same method to compute this
> function. I think [TOMS-708|http://www.netlib.org/toms/708] is probably the
> best option.
> _Issue moved from MATH project on January 27, 2018 (concerned implementation
> was moved to module {{commons-numbers-gamma}} of "Commons Numbers")._
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341839#comment-16341839
]
Matthew McGillis commented on NET-650:
--
> If the remote does not have a mapping, you have to use/remember the IP
> address.
It would be nice to be able to define the IP as a local mapping.
I'm not sure that gets very confusing in a number of contexts. I might like it
in some cases but not sure I would want it on default. Have you actually tested
that a name existing in both places but different ends up always using the
local one? To my thinking I want the remote name mapping first. Maybe if it
doesn't exist remotely then look locally.
I haven't looked at the actual InetSocketAddress code but some code does now
about the proxy and InetSocketAddress may also know this or it may not if you
have looked at the code and nothing about the proxy is in it OK but the proxy
as I have outlined it is easly knowable simply by checking the property
setting. Also keep in mind where this ticket came from which was adding support
for something in common-net to know about a proxy so you could specifically
configure it in the code. I'm sort of wondering if that has been done
consistently with property settings what happens if they overlap.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Moved] (NUMBERS-52) Incomplete beta function I(x, a, b) is inaccurate for large values of a and/or b
[ https://issues.apache.org/jira/browse/NUMBERS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles moved MATH-738 to NUMBERS-52: Fix Version/s: (was: 4.0) Affects Version/s: (was: 3.0) Workflow: jira (was: classic default workflow) Key: NUMBERS-52 (was: MATH-738) Project: Commons Numbers (was: Commons Math) > Incomplete beta function I(x, a, b) is inaccurate for large values of a > and/or b > > > Key: NUMBERS-52 > URL: https://issues.apache.org/jira/browse/NUMBERS-52 > Project: Commons Numbers > Issue Type: Bug >Reporter: Sébastien Brisard >Priority: Major > Labels: special-functions > > This was first reported in MATH-718. The result of the current implementation > of the incomplete beta function I(x, a, b) is inaccurate when a and/or b are > large-ish. > I've skimmed through [slatec|http://www.netlib.org/slatec/fnlib/betai.f], > GSL, > [Boost|http://www.boost.org/doc/libs/1_38_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/sf_beta/ibeta_function.html] > as well as NR. At first sight, neither uses the same method to compute this > function. I think [TOMS-708|http://www.netlib.org/toms/708] is probably the > best option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341826#comment-16341826
]
Sebb commented on NET-650:
--
If the remote does not have a mapping, you have to use/remember the IP address.
It would be nice to be able to define the IP as a local mapping.
The NET code does not know that you defined the proxy on the command line.
I don't think there is a way to find it out.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341812#comment-16341812
]
Matthew McGillis edited comment on NET-650 at 1/26/18 11:56 PM:
> There may be no remote mapping, so you might want to add your own local
> definition.
I would want to know that the remote does not know how to resolve the name.
> Also the code may not know that a proxy is being used.
But I do because I told it I wanted it to use the proxy. If I don't want to use
the proxy I won't specify it.
> As it stands, the constructor new InetSocketAddress(host, port) will use the
> local definition if there is one.
To force the use of the remote mapping, one would need to use
InetSocketAddress. InetSocketAddress(host,port)
Not following the above you sure you wrote it correctly.
was (Author: msm):
> There may be no remote mapping, so you might want to add your own local
> definition.
I would want to know that the remote does not know how to resolve the name.
> Also the code may not know that a proxy is being used.
But I do and because I told it I wanted it to use the proxy. If I don't want to
use the proxy I won't specify it.
> As it stands, the constructor new InetSocketAddress(host, port) will use the
> local definition if there is one.
To force the use of the remote mapping, one would need to use
InetSocketAddress. InetSocketAddress(host,port)
Not following the above you sure you wrote it correctly.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341812#comment-16341812
]
Matthew McGillis edited comment on NET-650 at 1/26/18 11:55 PM:
> There may be no remote mapping, so you might want to add your own local
> definition.
I would want to know that the remote does not know how to resolve the name.
> Also the code may not know that a proxy is being used.
But I do and because I told it I wanted it to use the proxy. If I don't want to
use the proxy I won't specify it.
> As it stands, the constructor new InetSocketAddress(host, port) will use the
> local definition if there is one.
To force the use of the remote mapping, one would need to use
InetSocketAddress. InetSocketAddress(host,port)
Not following the above you sure you wrote it correctly.
was (Author: msm):
> There may be no remote mapping, so you might want to add your own local
> definition.
I would want to know that the remote does not know haw to resolve the name.
> Also the code may not know that a proxy is being used.
But I do and because I told it I wanted it to use the proxy. If I don't want to
use the proxy I won't specify it.
> As it stands, the constructor new InetSocketAddress(host, port) will use the
> local definition if there is one.
To force the use of the remote mapping, one would need to use
InetSocketAddress. InetSocketAddress(host,port)
Not following the above you sure you wrote it correctly.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341812#comment-16341812
]
Matthew McGillis commented on NET-650:
--
> There may be no remote mapping, so you might want to add your own local
> definition.
I would want to know that the remote does not know haw to resolve the name.
> Also the code may not know that a proxy is being used.
But I do and because I told it I wanted it to use the proxy. If I don't want to
use the proxy I won't specify it.
> As it stands, the constructor new InetSocketAddress(host, port) will use the
> local definition if there is one.
To force the use of the remote mapping, one would need to use
InetSocketAddress. InetSocketAddress(host,port)
Not following the above you sure you wrote it correctly.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341799#comment-16341799
]
Sebb edited comment on NET-650 at 1/26/18 11:55 PM:
bq. if you have directed something to use a proxy then you want the remote
mapping of the name and not the local one.
Not necessarily.
There may be no remote mapping, so you might want to add your own local
definition.
Also the code may not know that a proxy is being used.
As it stands, the constructor new InetSocketAddress(host, port) will use the
local definition if there is one.
To force the use of the remote mapping, one would need to use
InetSocketAddress.createUnresolved(host,port)
was (Author: s...@apache.org):
bq. if you have directed something to use a proxy then you want the remote
mapping of the name and not the local one.
Not necessarily.
There may be no remote mapping, so you might want to add your own local
definition.
Also the code may not know that a proxy is being used.
As it stands, the constructor new InetSocketAddress(host, port) will use the
local definition if there is one.
To force the use of the remote mapping, one would need to use
InetSocketAddress. InetSocketAddress(host,port)
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341808#comment-16341808
]
Sebb commented on NET-650:
--
OK great, thanks for testing.
Now just need to work out how to implement this without changing existing
behaviour for the non-proxy case.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341803#comment-16341803
]
Matthew McGillis commented on NET-650:
--
Your latest changes work as expected for both host name and IP of proxy.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1441) SimpleRegression#getSlopeConfidenceInterval recalculates t distribution on every call
[
https://issues.apache.org/jira/browse/MATH-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341802#comment-16341802
]
Gilles commented on MATH-1441:
--
I reverted the change in commit 60bcdd450d6950da981d70b8b08379bdd744c82d
because I couldn't notice any performance improvement.
Please post the result of your benchmark on the current code ("master" branch).
Thanks.
> SimpleRegression#getSlopeConfidenceInterval recalculates t distribution on
> every call
> -
>
> Key: MATH-1441
> URL: https://issues.apache.org/jira/browse/MATH-1441
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.6.1
> Environment: Java 8, Linux x64.
>Reporter: Max Aller
>Priority: Minor
> Labels: performance
>
> SimpleRegression#getSlopeConfidenceInterval, when called a lot (on the other
> of 100k or 1M times), is surprisingly slow - 3M calls, on my 3rd gen i7
> machine, takes *75 seconds*. This is primarily because recalculating the
> inverse cumulative probability, and reconstructing the TDistribution object
> itself, is somewhat expensive, entailing a lot of `log` and `sqrt` and
> iteration and all that stuff.
> The confidence interval is based on two values - *n* and *alpha*. I'd posit
> that alpha will _usually_ be one of a very small set of values, and n, well,
> at least in my case, I'm always calling this method with the same number of
> data points - a moving window of time-series data. But I recognize n might be
> all over the place for some users.
> In any event, I strongly believe some level of caching would greatly benefit
> the users of Commons Math. I've forked my own version of
> getSlopeConfidenceInterval that uses caching. Here's a test case
> demonstrating that:
> {code:java}
> class SlowRegressionsTest {
> @Test
> void slow() {
> SimpleRegression simpleRegression = new SimpleRegression();
> simpleRegression.addData(0.0, 0.0);
> simpleRegression.addData(1.0, 1.0);
> simpleRegression.addData(2.0, 2.0);
> long start = System.currentTimeMillis();
> for (int i = 0; i < 3_000_000; i++) {
> simpleRegression.getSlopeConfidenceInterval();
> }
> long duration = System.currentTimeMillis() - start;
> System.out.printf("`slow` took %dms%n", duration);
> }
> @Test
> void fast() {
> SimpleRegression simpleRegression = new SimpleRegression();
> simpleRegression.addData(0.0, 0.0);
> simpleRegression.addData(1.0, 1.0);
> simpleRegression.addData(2.0, 2.0);
> long start = System.currentTimeMillis();
> for (int i = 0; i < 3_000_000; i++) {
>
> SimpleRegressionUtilsKt.fastGetSlopeConfidenceInterval(simpleRegression);
> }
> long duration = System.currentTimeMillis() - start;
> System.out.printf("`fast` took %dms%n", duration);
> }
> }{code}
> which prints out
> {noformat}
> `fast` took 159ms
> `slow` took 75304ms{noformat}
> Nearly 500x faster - 53ns/call. My particular solution is written in Kotlin
> for Java 8, so not of direct relevance to you, but here it is:
> {code:java}
> package math
> import org.apache.commons.math3.distribution.TDistribution
> import org.apache.commons.math3.exception.OutOfRangeException
> import org.apache.commons.math3.exception.util.LocalizedFormats
> import org.apache.commons.math3.stat.regression.SimpleRegression
> import java.util.concurrent.ConcurrentHashMap
> @JvmOverloads
> fun SimpleRegression.fastGetSlopeConfidenceInterval(alpha: Double = 0.05):
> Double {
> if (n < 3) {
> return Double.NaN
> }
> if (alpha >= 1 || alpha <= 0) {
> throw OutOfRangeException(
> LocalizedFormats.SIGNIFICANCE_LEVEL,
> alpha, 0, 1
> )
> }
> // No advertised NotStrictlyPositiveException here - will return NaN above
> // PATCH: use cached inverse cumulative probability
> return slopeStdErr * getInverseCumulativeProbability(n, alpha)
> }
> private val cache = ConcurrentHashMap()
> private data class Key(val n: Long, val alpha: Double)
> private fun getInverseCumulativeProbability(n: Long, alpha: Double): Double =
> cache.getOrPut(Key(n, alpha)) {
> TDistribution((n - 2).toDouble()).inverseCumulativeProbability(1.0 -
> alpha / 2.0)
> }
> {code}
> Limitations: 1. Kotlin, 2. ConcurrentHashMap is unbounded here.
> I don't know how/if Commons Math does caching elsewhere, but it'd sure be
> handy here, I believe. What are your thoughts?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341799#comment-16341799
]
Sebb commented on NET-650:
--
bq. if you have directed something to use a proxy then you want the remote
mapping of the name and not the local one.
Not necessarily.
There may be no remote mapping, so you might want to add your own local
definition.
Also the code may not know that a proxy is being used.
As it stands, the constructor new InetSocketAddress(host, port) will use the
local definition if there is one.
To force the use of the remote mapping, one would need to use
InetSocketAddress. InetSocketAddress(host,port)
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341796#comment-16341796
]
Sebb commented on NET-650:
--
I forget I changed my code slightly to debug the NPE.
It should be
{code}
_hostname_ = host; // after this line
_socket_ = _socketFactory_.createSocket(); // ++ add this line ++
_socket_.connect(new InetSocketAddress(host, port), connectTimeout); // before
this line
{code}
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341784#comment-16341784
]
Matthew McGillis commented on NET-650:
--
I get this with those lines:
{code}
$ javac -cp .:./commons-net-3.6.jar imapproxy2.java
imapproxy2.java:17: error: cannot find symbol
_socket_.connect(endpoint, connectTimeout); // before this
^
symbol: variable endpoint
location: class MyClient
1 error
{code}
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341777#comment-16341777
]
Matthew McGillis commented on NET-650:
--
> This brings up something else: it's possible that the hostname has different
> values on the local and far side of the proxy, so I think any fix would need
> to take that into account.
Not sure what your thinking but if you have directed something to use a proxy
then you want the remote mapping of the name and not the local one.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341770#comment-16341770
]
Sebb commented on NET-650:
--
Thanks for the info.
I left a bit out:
{code}
_socket_ = _socketFactory_.createSocket(); // add this line
_socket_.connect(endpoint, connectTimeout); // before this
{code}
That should fix the NPE.
AFAICT the difference between InetSocketAddress and InetAddress is that the
former allows the IP address to be unresolved.
In which case the Socket is passed the hostname instead of an IP address.
This brings up something else: it's possible that the hostname has different
values on the local and far side of the proxy, so I think any fix would need to
take that into account.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341732#comment-16341732
]
Matthew McGillis edited comment on NET-650 at 1/26/18 10:49 PM:
InetSocketAddress should work regardless of proxy or not. So you should be able
to test that you have found a working InetSocketAddress solution simply by
connecting to anything you would normally.
{code}
$ java -cp .:./commons-net-3.6.jar socketproxy imap.comcast.net
* OK IMAP4 ready
{code}
Then once you are using InetSocketAddress locally fine it should continue to
work for when -DsocksProxyHost and -DsocksProxyPort are specified.
was (Author: msm):
InetSocketAddress should work regardless of proxy or not. So you should be able
to test that you have found a working InetSocketAddress solution simply by
connecting to anything you would normally.
{code}
$ java -cp .:./commons-net-3.6.jar socketproximap.comcast.net
* OK IMAP4 ready
{code}
Then once you are using InetSocketAddress locally fine it should continue to
work for when -DsocksProxyHost and -DsocksProxyPort are specified.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341732#comment-16341732
]
Matthew McGillis commented on NET-650:
--
InetSocketAddress should work regardless of proxy or not. So you should be able
to test that you have found a working InetSocketAddress solution simply by
connecting to anything you would normally.
{code}
$ java -cp .:./commons-net-3.6.jar socketproximap.comcast.net
* OK IMAP4 ready
{code}
Then once you are using InetSocketAddress locally fine it should continue to
work for when -DsocksProxyHost and -DsocksProxyPort are specified.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341717#comment-16341717
]
Matthew McGillis commented on NET-650:
--
This is what I get when using your imapproxy2 code with a hostname:
connect error: java.lang.NullPointerException
connect error: java.lang.NullPointerException
I also get the same thing when I use an IP address.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341706#comment-16341706
]
Matthew McGillis commented on NET-650:
--
This would be an outline of a test case you might want to setup up or figure
out how to build in to a regression test:
1. Consider two hosts A and B
2. Setup the host file on A so it only knows host B as say: test.domain.com
3. Setup the host file on B so it only knows it self as say: proxy.domain.com
4. Confirm ping proxy.domain.com from A fails on host lookup
5. From A ssh to B creating a socks proxy
{code:java}
$ ssh -D localhost:16000 test.domain.com
{code}
6. now run the socketproxy.java on A
{code:java}
$ java -DsocksProxyHost=localhost -DsocksProxyPort=16000 socketproxy
proxy.domain.com
{code}
As socketproxy is currently written you would need something listening on the
imap port of host B so it returns something when connected to so you can see
that the above works. But you can replace the port number in socketproxy to
anything that will respond. In the above since ssh is on B to support the socks
proxy you could use the ssh port which when you connect should return something
like:
$ nc localhost 22
SSH-2.0-OpenSSH_7.6
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341698#comment-16341698
]
Sebb commented on NET-650:
--
OK, sorry, I had confused InetAddress with InetSocketAddress.
Does the imapproxy2.java code work? (it compiles for me)
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-650:
-
Attachment: imapproxy2.java
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, imapproxy2.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341640#comment-16341640
]
Matthew McGillis commented on NET-650:
--
See the API for the socket connect
http://commons.apache.org/proper/commons-net/apidocs/org/apache/commons/net/SocketClient.html#connect
it doesn't support what you suggest.
{code}
$ javac -cp ./commons-net-3.6.jar imapproxy.java
imapproxy.java:44: error: no suitable method found for
connect(InetSocketAddress)
ic.connect(rip);
^
method SocketClient.connect(InetAddress) is not applicable
(argument mismatch; InetSocketAddress cannot be converted to InetAddress)
method SocketClient.connect(String) is not applicable
(argument mismatch; InetSocketAddress cannot be converted to String)
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get
full output
{code}
Even if it did I would consider that a work around and not a fix for the
underlying issue.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341581#comment-16341581 ] ASF GitHub Bot commented on LANG-1373: -- Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/311 Perfect. So maybe it is not enforcing the 4 spaces? Haven't looked at the xml settings we have in lang in a while. So if you fixed the 2/4 spaces, we won't have any other nit-picks like this, and be able to focus on the feature. Especially since you added good docs, unit cases, and even a practical use case :-) > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Priority: Major > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/311 Perfect. So maybe it is not enforcing the 4 spaces? Haven't looked at the xml settings we have in lang in a while. So if you fixed the 2/4 spaces, we won't have any other nit-picks like this, and be able to focus on the feature. Especially since you added good docs, unit cases, and even a practical use case :-) ---
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341539#comment-16341539 ] ASF GitHub Bot commented on LANG-1373: -- Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 The reports actually look good for my stuff, except the coverage stuff, if I am reading this correctly > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Priority: Major > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...
Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 The reports actually look good for my stuff, except the coverage stuff, if I am reading this correctly ---
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341532#comment-16341532
]
Sebb commented on NET-650:
--
I don't have any way of testing this.
However if you say that socketproxy.java works, this suggests that
InetSocketAddress must be getting the host info over the proxy.
In which case it should be possible to apply the same fix to imapprox.java
i.e. replace
{code:java}
ic.connect(iserver,Integer.parseInt(iport));
{code}
with
{code:java}
ic.connect(InetSocketAddress(iserver, Integer.parseInt(iport)));
{code}
Does that work for you?
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
>Priority: Major
> Attachments: imapproxy.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341529#comment-16341529 ] ASF GitHub Bot commented on LANG-1373: -- Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 OK, I wasn't looking in target, I have the reports. smh. > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Priority: Major > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...
Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 OK, I wasn't looking in target, I have the reports. smh. ---
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341522#comment-16341522 ] ASF GitHub Bot commented on LANG-1373: -- Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 maybe i didn't run clean, i'll try again > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Priority: Major > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...
Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 maybe i didn't run clean, i'll try again ---
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341517#comment-16341517 ] ASF GitHub Bot commented on LANG-1373: -- Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 Do I have to do something to get my stuff added to the reports in the local site? I see my tests run in the cli, but they are not in the reports, or the java doc etc > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Priority: Major > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...
Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 Do I have to do something to get my stuff added to the reports in the local site? I see my tests run in the cli, but they are not in the reports, or the java doc etc ---
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341512#comment-16341512 ] ASF GitHub Bot commented on LANG-1373: -- Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 Thanks, I did try to follow that, I use travis so the different java builds worked. I used the local checkstyle xml, and through I had caught everything. > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Priority: Major > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...
Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 Thanks, I did try to follow that, I use travis so the different java builds worked. I used the local checkstyle xml, and through I had caught everything. ---
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341502#comment-16341502 ] ASF GitHub Bot commented on LANG-1373: -- Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/311 Oh, good point. There's the [CONTRIBUTING.md](https://github.com/apache/commons-lang/blob/master/CONTRIBUTING.md). There are several links in that doc too, apologize for not having a shorter version. The tabs/spaces is mentioned at the first link under *Additional Resources*, but there are heaps of other useful information in there. Hopefully not too different from other ASF projects, so you can probably filter through 90% or more of the contents in those files, and just recognize one of two differences in the way [lang]/Commons expects patches and pull requests. Ta > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Priority: Major > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/311 Oh, good point. There's the [CONTRIBUTING.md](https://github.com/apache/commons-lang/blob/master/CONTRIBUTING.md). There are several links in that doc too, apologize for not having a shorter version. The tabs/spaces is mentioned at the first link under *Additional Resources*, but there are heaps of other useful information in there. Hopefully not too different from other ASF projects, so you can probably filter through 90% or more of the contents in those files, and just recognize one of two differences in the way [lang]/Commons expects patches and pull requests. Ta ---
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341497#comment-16341497 ] ASF GitHub Bot commented on LANG-1373: -- Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 You bet, thanks. If there is any guide that I should be following let me know. > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Priority: Major > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...
Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 You bet, thanks. If there is any guide that I should be following let me know. ---
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341491#comment-16341491 ] ASF GitHub Bot commented on LANG-1373: -- Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/311 Ah, and might be a good idea to run `mvn clean site`, then have a look at the reports output. Some pull requests are delayed merging due to the introduction of findbugs/checkstyle/etc issues. Quickly running it and fixing any reported issues might make it easy and faster to get it merged :) > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Priority: Major > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/311 Ah, and might be a good idea to run `mvn clean site`, then have a look at the reports output. Some pull requests are delayed merging due to the introduction of findbugs/checkstyle/etc issues. Quickly running it and fixing any reported issues might make it easy and faster to get it merged :) ---
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341490#comment-16341490 ] ASF GitHub Bot commented on LANG-1373: -- Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/311 Ack :-) haven't had time to review it as we have a short summer around here, so have added a note to have a look at StopWatch (which I'm not familiar with) and at this variation. Said that, had a very brief peek at the code from the browser without using the IDE. The code looks great! Only small minor things I could see were a duplicated white line (which doesn't matter tbh) and the the formatting. If I recall correctly, [lang] uses 4 spaces instead of 2? Though I could be wrong. Thanks for being so patient. I intend to review it as soon as I get some spare time (IOW once the weather gets back to our normal 10-17C cloudy days with with windy rains). But happy if anyone beats me to it. Cheers Bruno > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Priority: Major > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/311 Ack :-) haven't had time to review it as we have a short summer around here, so have added a note to have a look at StopWatch (which I'm not familiar with) and at this variation. Said that, had a very brief peek at the code from the browser without using the IDE. The code looks great! Only small minor things I could see were a duplicated white line (which doesn't matter tbh) and the the formatting. If I recall correctly, [lang] uses 4 spaces instead of 2? Though I could be wrong. Thanks for being so patient. I intend to review it as soon as I get some spare time (IOW once the weather gets back to our normal 10-17C cloudy days with with windy rains). But happy if anyone beats me to it. Cheers Bruno ---
[jira] [Commented] (MATH-1441) SimpleRegression#getSlopeConfidenceInterval recalculates t distribution on every call
[
https://issues.apache.org/jira/browse/MATH-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341280#comment-16341280
]
Gilles commented on MATH-1441:
--
Could please check the solution included in commit
1f07a0bf70049cb0a2f6b52ea7c261da5adb1abb in "master" branch?
> SimpleRegression#getSlopeConfidenceInterval recalculates t distribution on
> every call
> -
>
> Key: MATH-1441
> URL: https://issues.apache.org/jira/browse/MATH-1441
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.6.1
> Environment: Java 8, Linux x64.
>Reporter: Max Aller
>Priority: Minor
> Labels: performance
>
> SimpleRegression#getSlopeConfidenceInterval, when called a lot (on the other
> of 100k or 1M times), is surprisingly slow - 3M calls, on my 3rd gen i7
> machine, takes *75 seconds*. This is primarily because recalculating the
> inverse cumulative probability, and reconstructing the TDistribution object
> itself, is somewhat expensive, entailing a lot of `log` and `sqrt` and
> iteration and all that stuff.
> The confidence interval is based on two values - *n* and *alpha*. I'd posit
> that alpha will _usually_ be one of a very small set of values, and n, well,
> at least in my case, I'm always calling this method with the same number of
> data points - a moving window of time-series data. But I recognize n might be
> all over the place for some users.
> In any event, I strongly believe some level of caching would greatly benefit
> the users of Commons Math. I've forked my own version of
> getSlopeConfidenceInterval that uses caching. Here's a test case
> demonstrating that:
> {code:java}
> class SlowRegressionsTest {
> @Test
> void slow() {
> SimpleRegression simpleRegression = new SimpleRegression();
> simpleRegression.addData(0.0, 0.0);
> simpleRegression.addData(1.0, 1.0);
> simpleRegression.addData(2.0, 2.0);
> long start = System.currentTimeMillis();
> for (int i = 0; i < 3_000_000; i++) {
> simpleRegression.getSlopeConfidenceInterval();
> }
> long duration = System.currentTimeMillis() - start;
> System.out.printf("`slow` took %dms%n", duration);
> }
> @Test
> void fast() {
> SimpleRegression simpleRegression = new SimpleRegression();
> simpleRegression.addData(0.0, 0.0);
> simpleRegression.addData(1.0, 1.0);
> simpleRegression.addData(2.0, 2.0);
> long start = System.currentTimeMillis();
> for (int i = 0; i < 3_000_000; i++) {
>
> SimpleRegressionUtilsKt.fastGetSlopeConfidenceInterval(simpleRegression);
> }
> long duration = System.currentTimeMillis() - start;
> System.out.printf("`fast` took %dms%n", duration);
> }
> }{code}
> which prints out
> {noformat}
> `fast` took 159ms
> `slow` took 75304ms{noformat}
> Nearly 500x faster - 53ns/call. My particular solution is written in Kotlin
> for Java 8, so not of direct relevance to you, but here it is:
> {code:java}
> package math
> import org.apache.commons.math3.distribution.TDistribution
> import org.apache.commons.math3.exception.OutOfRangeException
> import org.apache.commons.math3.exception.util.LocalizedFormats
> import org.apache.commons.math3.stat.regression.SimpleRegression
> import java.util.concurrent.ConcurrentHashMap
> @JvmOverloads
> fun SimpleRegression.fastGetSlopeConfidenceInterval(alpha: Double = 0.05):
> Double {
> if (n < 3) {
> return Double.NaN
> }
> if (alpha >= 1 || alpha <= 0) {
> throw OutOfRangeException(
> LocalizedFormats.SIGNIFICANCE_LEVEL,
> alpha, 0, 1
> )
> }
> // No advertised NotStrictlyPositiveException here - will return NaN above
> // PATCH: use cached inverse cumulative probability
> return slopeStdErr * getInverseCumulativeProbability(n, alpha)
> }
> private val cache = ConcurrentHashMap()
> private data class Key(val n: Long, val alpha: Double)
> private fun getInverseCumulativeProbability(n: Long, alpha: Double): Double =
> cache.getOrPut(Key(n, alpha)) {
> TDistribution((n - 2).toDouble()).inverseCumulativeProbability(1.0 -
> alpha / 2.0)
> }
> {code}
> Limitations: 1. Kotlin, 2. ConcurrentHashMap is unbounded here.
> I don't know how/if Commons Math does caching elsewhere, but it'd sure be
> handy here, I believe. What are your thoughts?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
[ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341104#comment-16341104 ] ASF GitHub Bot commented on LANG-1373: -- Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 bump > Stopwatch based capability for nested, named, timings in a call stack > - > > Key: LANG-1373 > URL: https://issues.apache.org/jira/browse/LANG-1373 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Otto Fowler >Priority: Major > > While working on adding some timing functionality to a Metron feature, I came > across the > Stopwatch class, but found that it didn’t suite my needs. > What I wanted to do was to create a timing from a top level function in our > Stellar dsl, and have have a group of related timings, such that the end > result was the overall time of the call, and nested timings of other calls > executed during the dsl execution of that function. These timings would all > be named, and have a path for identification and include timing the language > compiler/execution as well as the function execution itself. It would be > helpful if they were tagged in some way as well, such that the consumer could > filter during visitation. > So I have written StackWatch to provide this functionality, and submitted it > in a Metron PR. > From the PR description: > StackWatch > A set of utility classes under the new package stellar.common.timing have > been added. These provide the StackWatch functionality. > StackWatch provides an abstraction over the Apache Commons StopWatch class > that allows callers to create multiple named and possibly nested timing > operations. > <…> > This class may be more generally useful to this and other projects, but I am > not sure where it would live since we wouldn’t want it in common. > StackWatch uses a combination of Deque and a custom Tree implementation to > create, start and end timing operations. > A Visitor pattern is also implemented to allow for retrieving the results > after the completion of the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #311: LANG-1373 Stopwatch based capability for nested, na...
Github user ottobackwards commented on the issue: https://github.com/apache/commons-lang/pull/311 bump ---
[jira] [Commented] (NUMBERS-48) Unreachable statements in Complex.abs()
[
https://issues.apache.org/jira/browse/NUMBERS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341085#comment-16341085
]
Eric Barnhill commented on NUMBERS-48:
--
Ah right. I just forked commons-statistics so my head was in the wrong place.
> Unreachable statements in Complex.abs()
> ---
>
> Key: NUMBERS-48
> URL: https://issues.apache.org/jira/browse/NUMBERS-48
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: David Nickerson
>Priority: Minor
> Labels: easyfix, newbie, patch
> Fix For: 1.0
>
> Attachments: complex_abs.patch
>
>
> This return statement in Complex.abs() is unreachable:
> {code:java}
> if (FastMath.abs(real) < FastMath.abs(imaginary)) {
> if (imaginary == 0.0) {
> return FastMath.abs(real);
> }
> {code}
> If imaginary == 0, then there's no way that the preceding condition would be
> true. There are two similar inner 'if' statements that were accidentally
> switched. Returned values are still correct, but performance suffers.
> The attached patch switches these back. Note that we're still protected from
> dividing by zero.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1370) Increase efficiency of EnumeratedDistribution#probability
[
https://issues.apache.org/jira/browse/MATH-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341076#comment-16341076
]
Gilles commented on MATH-1370:
--
An issue that got lost in the long-standing discussions about the future of
"Commons Math".
I seem to have redone the same changes that were proposed here while porting
some of the functionality to "Commons RNG" (cf. RNG-47)! :(
Those modifications should still be applied to class {{EnumeratedDistribution}}
(but the branch is badly out-of-date after implementing changes proposed in
STATISTICS-2.
> Increase efficiency of EnumeratedDistribution#probability
> -
>
> Key: MATH-1370
> URL: https://issues.apache.org/jira/browse/MATH-1370
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Ryan Gaffney
>Priority: Minor
> Labels: patch, performance
> Fix For: 4.0
>
> Attachments: enum-distribution-perf-patch,
> enum-distribution-perf-patch.2
>
>
> There are lots of other low hanging fruit in the distribution package but
> unfortunately this is the only one I got to that day.
> In the EnumeratedDistribution case, the probability() method is currently
> O(N) where N denotes number of random variables, even though the random
> variables are fixed / known. This change makes probability() O(1). The
> unlikely worst case scenario now consumes slightly more than 2x the memory,
> but I do not think this would be an issue in the vast majority of cases.
> Original PR (incorrectly against master)
> [here|https://github.com/apache/commons-math/pull/34].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1437) Add/extend unit tests for o.a.c.m.geometry.partitioning and related packages
[ https://issues.apache.org/jira/browse/MATH-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16340976#comment-16340976 ] Gilles commented on MATH-1437: -- Merged in "master": commit 54fa0a855e549ae2a9f8445d71cbd01e8377e353 I noticed that you added a class for generating output with a specific file format. Perhaps this would be useful outside unit tests too (?). It's great that you help with this code! Do you have more in store? It would be interesting to post on the "dev" ML about what you do with the library. > Add/extend unit tests for o.a.c.m.geometry.partitioning and related packages > > > Key: MATH-1437 > URL: https://issues.apache.org/jira/browse/MATH-1437 > Project: Commons Math > Issue Type: Test >Affects Versions: 4.X >Reporter: Matt Juntunen >Priority: Major > Fix For: 4.X > > > Additional unit tests should be added for the following packages: > * o.a.c.m.geometry.partitioning > * o.a.c.m.geometry.euclidean.oned > * o.a.c.m.geometry.euclidean.twod > * o.a.c.m.geometry.euclidean.threed > The current tests provide adequate code coverage but don't seem to thoroughly > exercise the code base and check edge cases. > > Pull request: https://github.com/apache/commons-math/pull/77 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (RNG-45) Example code (sampling)
[
https://issues.apache.org/jira/browse/RNG-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved RNG-45.
---
Resolution: Done
> Example code (sampling)
> ---
>
> Key: RNG-45
> URL: https://issues.apache.org/jira/browse/RNG-45
> Project: Commons RNG
> Issue Type: Wish
>Reporter: Gilles
>Priority: Trivial
> Labels: doc, example, usage
> Fix For: 1.1
>
> Attachments: ProbabilityDensityApproximation.java
>
>
> I've added a few figures to the userguide (see commit
> 5de2d1af79fabca56b5fa8fca159938fa023ae6a).
> The Java code that generates the data is a fairly trivial example of usage of
> the samplers provided in module {{commons-rng-sampling}}.
> It is attached to this page.
> Do you think it's worth adding it to the repository (in
> {{commons-rng-examples}})?
> If so, should I also add the script that generated the plots (it calls the
> "gnuplot" software)?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-45) Example code (sampling)
[
https://issues.apache.org/jira/browse/RNG-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16340954#comment-16340954
]
Gilles commented on RNG-45:
---
Not adding the "gnuplot" script.
> Example code (sampling)
> ---
>
> Key: RNG-45
> URL: https://issues.apache.org/jira/browse/RNG-45
> Project: Commons RNG
> Issue Type: Wish
>Reporter: Gilles
>Priority: Trivial
> Labels: doc, example, usage
> Fix For: 1.1
>
> Attachments: ProbabilityDensityApproximation.java
>
>
> I've added a few figures to the userguide (see commit
> 5de2d1af79fabca56b5fa8fca159938fa023ae6a).
> The Java code that generates the data is a fairly trivial example of usage of
> the samplers provided in module {{commons-rng-sampling}}.
> It is attached to this page.
> Do you think it's worth adding it to the repository (in
> {{commons-rng-examples}})?
> If so, should I also add the script that generated the plots (it calls the
> "gnuplot" software)?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (RNG-47) Migrate "EnumeratedDistribution" from "Commons Math"
[
https://issues.apache.org/jira/browse/RNG-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved RNG-47.
---
Resolution: Fixed
> Migrate "EnumeratedDistribution" from "Commons Math"
>
>
> Key: RNG-47
> URL: https://issues.apache.org/jira/browse/RNG-47
> Project: Commons RNG
> Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
> Labels: api
> Fix For: 1.1
>
> Attachments: DiscreteProbabilityCollectionSampler.java
>
>
> The main feature of class {{EnumeratedDistribution}} in package
> {{org.apache.commons.math4.distribution}} is to allow sampling from a finite
> set of elements with user-assigned probabilities.
> This functionality seems a good fit for package
> {{org.apache.commons.rng.sampling}} (with a tentative class name of
> [DiscreteProbabilityCollectionSampler|https://en.wikipedia.org/wiki/Probability_distribution#Discrete_probability_distribution]).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (RNG-46) Benign incompatibility (?)
[
https://issues.apache.org/jira/browse/RNG-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved RNG-46.
---
Resolution: Information Provided
No PMC member considers this report a blocker for the upcoming v1.1.
> Benign incompatibility (?)
> --
>
> Key: RNG-46
> URL: https://issues.apache.org/jira/browse/RNG-46
> Project: Commons RNG
> Issue Type: Sub-task
>Reporter: Gilles
>Priority: Blocker
> Labels: compatibility, incompatibility
> Fix For: 1.1
>
>
> Clirr reports this error:
> {{Removed org.apache.commons.rng.sampling.distribution.SamplerBase from the
> list of superclasses}}
> for this class:
> {{org.apache.commons.rng.sampling.distribution.BoxMullerLogNormalSampler}}
> It is quite true.
> However, no functionality inherited from {{SamplerBase}} could have been
> used since a {{null}} was passed to its constructor (i.e. any call to a
> method from the base class would trigger a {{NullPointerException}}).
> Moreover:
> * {{SamplerBase}} is only meant for internal usage,
> * it only contains {{protected}} methods,
> * {{BoxMullerLogNormalSampler}} is going to be flagged as {{@deprecated}} in
> the next release.
> Hence, I think that it is quite safe to release a 1.1 version (i.e. no change
> in major number!) despite this incompatibility.
> Please confirm.
> See also the [discussion on the "dev"
> ML|http://markmail.org/message/24t4v2bsh5x366fe].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-2) Potential performance issues in "ComplexUtils"
[ https://issues.apache.org/jira/browse/NUMBERS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16340929#comment-16340929 ] Gilles commented on NUMBERS-2: -- Please make a proposal on the "dev" ML. It seems that the current settings is Java 6. There are pros and cons. One of the latter might be that this would prevent using 95% of the Java 6-compatible code on pre-Java 8 environments... Of course, if we can assume that [such environments|https://plumbr.io/blog/java/java-version-and-vendor-data-analyzed-2017-edition] are not going to undergo any new development, the objection can be dropped... > Potential performance issues in "ComplexUtils" > -- > > Key: NUMBERS-2 > URL: https://issues.apache.org/jira/browse/NUMBERS-2 > Project: Commons Numbers > Issue Type: Improvement >Reporter: Gilles >Priority: Minor > Labels: benchmark, performance > > See http://markmail.org/message/qnzauv65nb3gmz2h > To be checked with JMH benchmarking code. > Most of this class is concerned with arrays; I suggest to rename it > "ComplexArrays". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NUMBERS-48) Unreachable statements in Complex.abs()
[
https://issues.apache.org/jira/browse/NUMBERS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16340918#comment-16340918
]
Gilles commented on NUMBERS-48:
---
Why submit a pull request since you have commit access to the repository at
Apache?
> Unreachable statements in Complex.abs()
> ---
>
> Key: NUMBERS-48
> URL: https://issues.apache.org/jira/browse/NUMBERS-48
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: David Nickerson
>Priority: Minor
> Labels: easyfix, newbie, patch
> Fix For: 1.0
>
> Attachments: complex_abs.patch
>
>
> This return statement in Complex.abs() is unreachable:
> {code:java}
> if (FastMath.abs(real) < FastMath.abs(imaginary)) {
> if (imaginary == 0.0) {
> return FastMath.abs(real);
> }
> {code}
> If imaginary == 0, then there's no way that the preceding condition would be
> true. There are two similar inner 'if' statements that were accidentally
> switched. Returned values are still correct, but performance suffers.
> The attached patch switches these back. Note that we're still protected from
> dividing by zero.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-2) Potential performance issues in "ComplexUtils"
[ https://issues.apache.org/jira/browse/NUMBERS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16340881#comment-16340881 ] Eric Barnhill commented on NUMBERS-2: - What about targeting Java 8 with this class and using streams? Anyone wanting to use Java 7, could use the ComplexUtils in commons-math-3.x . > Potential performance issues in "ComplexUtils" > -- > > Key: NUMBERS-2 > URL: https://issues.apache.org/jira/browse/NUMBERS-2 > Project: Commons Numbers > Issue Type: Improvement >Reporter: Gilles >Priority: Minor > Labels: benchmark, performance > > See http://markmail.org/message/qnzauv65nb3gmz2h > To be checked with JMH benchmarking code. > Most of this class is concerned with arrays; I suggest to rename it > "ComplexArrays". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NUMBERS-17) 4D capacity for ComplexUtils
[ https://issues.apache.org/jira/browse/NUMBERS-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16340879#comment-16340879 ] Eric Barnhill commented on NUMBERS-17: -- I made these changes in my complex-dev branch. > 4D capacity for ComplexUtils > > > Key: NUMBERS-17 > URL: https://issues.apache.org/jira/browse/NUMBERS-17 > Project: Commons Numbers > Issue Type: Improvement >Reporter: Eric Barnhill >Priority: Minor > > Adding 4D capacity to the ComplexUtils will make them compatible with the > NIfTI medical image file format which is by default in 4D. Right now neither > Java library that handles .nii files handles complex .nii files so this > library will greatly facilitate that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NUMBERS-48) Unreachable statements in Complex.abs()
[
https://issues.apache.org/jira/browse/NUMBERS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16340877#comment-16340877
]
Eric Barnhill commented on NUMBERS-48:
--
I have been pushing my commits to a branch called complex-dev .
Would you prefer:
1) accepting my pull request, then merging into master yourself
2) me merging into master, then submitting pull request
Eric
> Unreachable statements in Complex.abs()
> ---
>
> Key: NUMBERS-48
> URL: https://issues.apache.org/jira/browse/NUMBERS-48
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: David Nickerson
>Priority: Minor
> Labels: easyfix, newbie, patch
> Fix For: 1.0
>
> Attachments: complex_abs.patch
>
>
> This return statement in Complex.abs() is unreachable:
> {code:java}
> if (FastMath.abs(real) < FastMath.abs(imaginary)) {
> if (imaginary == 0.0) {
> return FastMath.abs(real);
> }
> {code}
> If imaginary == 0, then there's no way that the preceding condition would be
> true. There are two similar inner 'if' statements that were accidentally
> switched. Returned values are still correct, but performance suffers.
> The attached patch switches these back. Note that we're still protected from
> dividing by zero.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
