[jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107397#comment-13107397 ] Luc Maisonobe commented on MATH-650: I guess it was in the other order. I have just changed the name of the constant so it matches the intent. The new name is RECOMPUTE_TABLES_AT_RUNTIME (r1172224). Sorry for the wrong name. FastMath has static code which slows the first access to FastMath - Key: MATH-650 URL: https://issues.apache.org/jira/browse/MATH-650 Project: Commons Math Issue Type: Improvement Affects Versions: Nightly Builds Environment: Android 2.3 (Dalvik VM with JIT) Reporter: Alexis Robert Priority: Minor Attachments: FastMathLoadCheck.java, LucTestPerformance.java Working on an Android application using Orekit, I've discovered that a simple FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the first time it's called). I've launched the Android profiling tool (traceview) and the problem seems to be linked with the static portion of FastMath code named // Initialize tables The timing resulted in : - FastMath.slowexp (40.8%) - FastMath.expint (39.2%) \- FastMath.quadmult() (95.6% of expint) - FastMath.slowlog (18.2%) Hoping that would help Thanks! Alexis Robert -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-419) Not possible to call FTPClient.abort() method correctly
[ https://issues.apache.org/jira/browse/NET-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bogdan Drozdowski updated NET-419: -- Attachment: ftp-synchro.diff The attached file, ftp-synchro.diff, synchronizes all the uses of the control socket (and its associated readers and writers). This should help in avoiding the incorrect replies to commands. It also introduces a boolean that tells if the user has called abort(). Currently all it does is skipping the now-perhaps-unnecessary replies on the control channel after aborting a transfer. This patch works for me: the FTP client does not lock because of synchronization and calling abor() on a separate Thread returns 226 Abort successful and the file is not totally transferred. It needs a re-think, though: do we need to skip the additional answers, so the user can read them? Perhaps something else should be done? To abort a transfer as soon as possible, abor() should be called, followed by closing the Input/OutputStream connected to the transfer. One may call interrupt() on the transfer Thread (after this, read()/write() should throw an InterruptedException, which should propagate all the way up to the code calling the FTP client), but someone noticed that it may not always work. On the other hand, closing the stream should always work. Not possible to call FTPClient.abort() method correctly --- Key: NET-419 URL: https://issues.apache.org/jira/browse/NET-419 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0 Environment: java version 1.6.0_26 Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) Linux cattie 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Reporter: Tomas Mysik Attachments: ftp-synchro.diff Unfortunately, it seems that there are difficulties of using FTPClient.abort() method [1][2]. Also, it is really not clear how the abort() method should be called/used at all - if from another thread (as I would expect) then there is a problem with thread-safety: FTPClient itself is not thread-safe so it means that some custom lock/monitor must be used; but this lock will prevent calling abort() on the FTPClient while it is downloading/uploading file since file upload/download itself is blocking... If I'm wrong and the abort() method works then an example in Javadoc would be more than welcome. Thanks a lot. [1] http://apache-commons.680414.n4.nabble.com/Net-FTPClient-abort-problem-td739542.html [2] http://www.tikalk.com/java/forums/apache-ftp-client-abort-transfer -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-249) FtpClient hangs 20 minutes in FTPClient.completePendingCommand from retrieveFile or listFiles
[
https://issues.apache.org/jira/browse/NET-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107411#comment-13107411
]
Bogdan Drozdowski commented on NET-249:
---
Perhaps timing and synchronization plays a role here? Try the ftp-synchro.diff
patch from NET-419 and let us know.
FtpClient hangs 20 minutes in FTPClient.completePendingCommand from
retrieveFile or listFiles
-
Key: NET-249
URL: https://issues.apache.org/jira/browse/NET-249
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 1.4, 2.0
Environment: Client and Server running on Solaris 9
Reporter: David Tavoularis
I have a Ftp Client with several connections in multi-thread that connects to
a remote Ftp Server to list files and download new ones.
After 3 minutes of runtime, I get a 20-minute timeout for all running Ftp
connections.
Here are the logs for 1 thread :
{noformat}
20090114 142216 (Command Sent Message): PASV
20090114 142216 (Reply Received Message): 227 Entering Passive Mode
(10,250,10,116,224,172)
20090114 142216 (Command Sent Message): LIST /Dir1/Dir2/Dir3
20090114 142216 (Reply Received Message): 150 Opening BINARY mode data
connection for /bin/ls.
20090114 142216 (Reply Received Message): 226 Transfer complete.
20090114 142216 (Command Sent Message): PASV
20090114 142216 (Reply Received Message): 227 Entering Passive Mode
(10,250,10,116,138,240)
20090114 142216 (Command Sent Message): RETR /Dir1/Dir2/Dir3/File1
20090114 142216 (Reply Received Message): 150 Opening BINARY mode data
connection for /Dir1/Dir2/Dir3/File1 (12364 bytes).
*** 20 minutes without any message ***
20090114 144216 (Reply Received Message): 426 Data connection: Interrupted
system call.
20090114 144216 (Command Sent Message): PASV
20090114 144216 (Reply Received Message): 227 Entering Passive Mode
(10,250,10,116,109,169)
20090114 144216 (Command Sent Message): RETR /Dir1/Dir2/Dir3/File1
20090114 144216 (Reply Received Message): 150 Opening BINARY mode data
connection for /Dir1/Dir2/Dir3/File2 (12387 bytes).
20090114 144216 (Reply Received Message): 226 Transfer complete.
{noformat}
Here are the logs for another thread :
{noformat}
20090114 142216 (Command Sent Message): PASV
20090114 142216 (Reply Received Message): 227 Entering Passive Mode
(10,250,10,116,174,233)
20090114 142216 (Command Sent Message): RETR /DirA/DirB/DirC/FileA
20090114 142216 (Reply Received Message): 150 Opening BINARY mode data
connection for /DirA/DirB/DirC/FileA (14209 bytes).
20090114 142216 (Reply Received Message): 226 Transfer complete.
20090114 142216 (Command Sent Message): PASV
20090114 142216 (Reply Received Message): 227 Entering Passive Mode
(10,250,10,116,202,81)
20090114 142216 (Command Sent Message): LIST /DirA/DirB/DirD
20090114 142216 (Reply Received Message): 150 Opening BINARY mode data
connection for /bin/ls.
*** 20 minutes without any message ***
20090114 144216 (Reply Received Message): 426 Data connection: Interrupted
system call.
20090114 144216 (Command Sent Message): PASV
20090114 144216 (Reply Received Message): 227 Entering Passive Mode
(10,250,10,116,11,16)
20090114 144216 (Command Sent Message): RETR /DirA/DirB/DirD/FileB
20090114 144216 (Reply Received Message): 150 Opening BINARY mode data
connection for /DirA/DirB/DirD/FileB (14145 bytes).
{noformat}
So it happens during LIST or during RETR command.
The issue is always reproducible when connecting to this Ftp server.
What is the meaning of the error message 426 Data connection: Interrupted
system call. ?
Here are the stack-traces where the FtpClient is blocked during 20 minutes.
For 1st connection :
{noformat}
Stack 30 - Wed Jan 14 14:40:00 CET 2009
FTPMediationTask prio=3 tid=0x00aac800 nid=0x156 runnable
[0x6877e000..0x6877fb70]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
- locked 0x8fc23880 (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.readLine(BufferedReader.java:299)
- locked 0x8fc23880 (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:294)
at org.apache.commons.net.ftp.FTP.getReply(FTP.java:619)
at
[jira] [Closed] (NET-249) FtpClient hangs 20 minutes in FTPClient.completePendingCommand from retrieveFile or listFiles
[
https://issues.apache.org/jira/browse/NET-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Tavoularis closed NET-249.
Resolution: Cannot Reproduce
Our customer moved to SFTP, which seems more reliable, so I can no longer
provide feedback on this issue. I prefer to close it. Thanks anyway for your
help.
FtpClient hangs 20 minutes in FTPClient.completePendingCommand from
retrieveFile or listFiles
-
Key: NET-249
URL: https://issues.apache.org/jira/browse/NET-249
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 1.4, 2.0
Environment: Client and Server running on Solaris 9
Reporter: David Tavoularis
I have a Ftp Client with several connections in multi-thread that connects to
a remote Ftp Server to list files and download new ones.
After 3 minutes of runtime, I get a 20-minute timeout for all running Ftp
connections.
Here are the logs for 1 thread :
{noformat}
20090114 142216 (Command Sent Message): PASV
20090114 142216 (Reply Received Message): 227 Entering Passive Mode
(10,250,10,116,224,172)
20090114 142216 (Command Sent Message): LIST /Dir1/Dir2/Dir3
20090114 142216 (Reply Received Message): 150 Opening BINARY mode data
connection for /bin/ls.
20090114 142216 (Reply Received Message): 226 Transfer complete.
20090114 142216 (Command Sent Message): PASV
20090114 142216 (Reply Received Message): 227 Entering Passive Mode
(10,250,10,116,138,240)
20090114 142216 (Command Sent Message): RETR /Dir1/Dir2/Dir3/File1
20090114 142216 (Reply Received Message): 150 Opening BINARY mode data
connection for /Dir1/Dir2/Dir3/File1 (12364 bytes).
*** 20 minutes without any message ***
20090114 144216 (Reply Received Message): 426 Data connection: Interrupted
system call.
20090114 144216 (Command Sent Message): PASV
20090114 144216 (Reply Received Message): 227 Entering Passive Mode
(10,250,10,116,109,169)
20090114 144216 (Command Sent Message): RETR /Dir1/Dir2/Dir3/File1
20090114 144216 (Reply Received Message): 150 Opening BINARY mode data
connection for /Dir1/Dir2/Dir3/File2 (12387 bytes).
20090114 144216 (Reply Received Message): 226 Transfer complete.
{noformat}
Here are the logs for another thread :
{noformat}
20090114 142216 (Command Sent Message): PASV
20090114 142216 (Reply Received Message): 227 Entering Passive Mode
(10,250,10,116,174,233)
20090114 142216 (Command Sent Message): RETR /DirA/DirB/DirC/FileA
20090114 142216 (Reply Received Message): 150 Opening BINARY mode data
connection for /DirA/DirB/DirC/FileA (14209 bytes).
20090114 142216 (Reply Received Message): 226 Transfer complete.
20090114 142216 (Command Sent Message): PASV
20090114 142216 (Reply Received Message): 227 Entering Passive Mode
(10,250,10,116,202,81)
20090114 142216 (Command Sent Message): LIST /DirA/DirB/DirD
20090114 142216 (Reply Received Message): 150 Opening BINARY mode data
connection for /bin/ls.
*** 20 minutes without any message ***
20090114 144216 (Reply Received Message): 426 Data connection: Interrupted
system call.
20090114 144216 (Command Sent Message): PASV
20090114 144216 (Reply Received Message): 227 Entering Passive Mode
(10,250,10,116,11,16)
20090114 144216 (Command Sent Message): RETR /DirA/DirB/DirD/FileB
20090114 144216 (Reply Received Message): 150 Opening BINARY mode data
connection for /DirA/DirB/DirD/FileB (14145 bytes).
{noformat}
So it happens during LIST or during RETR command.
The issue is always reproducible when connecting to this Ftp server.
What is the meaning of the error message 426 Data connection: Interrupted
system call. ?
Here are the stack-traces where the FtpClient is blocked during 20 minutes.
For 1st connection :
{noformat}
Stack 30 - Wed Jan 14 14:40:00 CET 2009
FTPMediationTask prio=3 tid=0x00aac800 nid=0x156 runnable
[0x6877e000..0x6877fb70]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
- locked 0x8fc23880 (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.readLine(BufferedReader.java:299)
- locked 0x8fc23880 (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:294)
at org.apache.commons.net.ftp.FTP.getReply(FTP.java:619)
at
[jira] [Resolved] (MATH-601) SingularValueDecompositionImpl psuedoinverse is not consistent with Rank calculation
[
https://issues.apache.org/jira/browse/MATH-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved MATH-601.
--
Resolution: Fixed
SingularValueDecompositionImpl psuedoinverse is not consistent with Rank
calculation
Key: MATH-601
URL: https://issues.apache.org/jira/browse/MATH-601
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2
Environment: All
Reporter: greg sterijevski
Assignee: Phil Steitz
Labels: Pseudoinverse
Fix For: 3.0
Attachments: SingularValueDecompositionImpl.patch
Original Estimate: 24h
Remaining Estimate: 24h
In the SingularValueDecompositionImpl's internal private class Solver, a
pseudo inverse matrix is calculated:
In lines 2600-264 we have:
if (singularValues[i] 0) {
a = 1 / singularValues[i];
} else {
a = 0;
}
This is not consistent with the manner in which rank is determined (lines 225
to 233). That is to say a matrix could potentially be rank deficient, yet the
psuedoinverse would still include the redundant columns...
Also, there is the problem of very small singular values which could result
in overflow.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-670) Merge EmpiricalDistribution interface and implementation
Merge EmpiricalDistribution interface and implementation Key: MATH-670 URL: https://issues.apache.org/jira/browse/MATH-670 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Reporter: Phil Steitz Fix For: 3.0 There is only one implementation of this interface. The source of randomness is now pluggable and the kernel can be made pluggable in the implementation, so I am proposing that we eliminate the interface and rename EmpiricalDistributionImpl to EmpiricalDistribution. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-672) EmpiricalDistribution(Impl) should implement the Distribution interface
EmpiricalDistribution(Impl) should implement the Distribution interface --- Key: MATH-672 URL: https://issues.apache.org/jira/browse/MATH-672 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Reporter: Phil Steitz Fix For: 3.0 To compute cumulative probability at a point x if no data have been loaded, throw IllegalStateException if x is below the global min, return 0 if x is above the global max, return 1 otherwise find the bin that x belongs to, sum the probabilities of the bins below x's bin and use the configured kernel to compute how much of the containing bin's mass should be added the total -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-21) Remove dead and broken code from OgnlRuntime/SimpleNode
[ https://issues.apache.org/jira/browse/OGNL-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107548#comment-13107548 ] Simone Tripodi commented on OGNL-21: I already started feeling obsolete and deprecable, if you call me Mr.Tripodi I feel old and want to unsubscribe from all MLs and JIRA :) Jokes a part, I still haven't had a deep look at your patch, I'd like to ask you the favor of investigating also in Apache Structs source code (it's the OGNL main client AFAIK) and MyBatis (it strongly relies on it). Moreover we should ask also in the commons users ML to collect more feedbacks, not everybody monitors Jira - the main channel of info are the MLs... Remove dead and broken code from OgnlRuntime/SimpleNode --- Key: OGNL-21 URL: https://issues.apache.org/jira/browse/OGNL-21 Project: OGNL Issue Type: Task Reporter: Daniel Pitts Labels: cleanup Attachments: Remove-dead-code.patch I noticed there are some apparently unnecessary methods in both SimpleNode and OgnlRuntime. I've created a patch which removes them, and the unit tests still run fine. One of the methods was clearly buggy and would cause ClassCastExceptions if used (it put an array into a cache which was used to also store Maps). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-21) Remove dead and broken code from OgnlRuntime/SimpleNode
[ https://issues.apache.org/jira/browse/OGNL-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107563#comment-13107563 ] Daniel Pitts commented on OGNL-21: -- That's fine by me Simone. I'm assuming you mean Struts, not Structs. FWIW, google code search does include apache commons and googlecode repositories, so my research above included Struts and MyBatis. Is that communication to the ML something you are willing to take on? I'm new to the open-source contribution scene and I'm not quite sure I'd know the best way to present this. Remove dead and broken code from OgnlRuntime/SimpleNode --- Key: OGNL-21 URL: https://issues.apache.org/jira/browse/OGNL-21 Project: OGNL Issue Type: Task Reporter: Daniel Pitts Labels: cleanup Attachments: Remove-dead-code.patch I noticed there are some apparently unnecessary methods in both SimpleNode and OgnlRuntime. I've created a patch which removes them, and the unit tests still run fine. One of the methods was clearly buggy and would cause ClassCastExceptions if used (it put an array into a cache which was used to also store Maps). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-22) Change the generics signature of ClassCache and ClassCacheImpl.
[ https://issues.apache.org/jira/browse/OGNL-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107565#comment-13107565 ] Daniel Pitts commented on OGNL-22: -- By Alternative to this I mean implementing OGNL-20 for these caches. Change the generics signature of ClassCache and ClassCacheImpl. --- Key: OGNL-22 URL: https://issues.apache.org/jira/browse/OGNL-22 Project: OGNL Issue Type: Improvement Reporter: Daniel Pitts Right now, ClassCache and ClassCacheImpl use some generics, but they do casting at the method level, which leads to possible ClassCastException, and doesn't quite support safe static typing. I'll be glad to provide a patch when I have some time. I'd like to have OGNL-21 resolved first, as it reduces the amount of code I'd have to touch to implement this change. The proposed signatures would be interface ClassCacheV and class ClassCacheImplV implements ClassCacheV Changing the get/put methods to take and return V type objects. Alternative to this is to replace all of them with a ConcurrentMapClass?, V. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OGNL-22) Change the generics signature of ClassCache and ClassCacheImpl.
Change the generics signature of ClassCache and ClassCacheImpl. --- Key: OGNL-22 URL: https://issues.apache.org/jira/browse/OGNL-22 Project: OGNL Issue Type: Improvement Reporter: Daniel Pitts Right now, ClassCache and ClassCacheImpl use some generics, but they do casting at the method level, which leads to possible ClassCastException, and doesn't quite support safe static typing. I'll be glad to provide a patch when I have some time. I'd like to have OGNL-21 resolved first, as it reduces the amount of code I'd have to touch to implement this change. The proposed signatures would be interface ClassCacheV and class ClassCacheImplV implements ClassCacheV Changing the get/put methods to take and return V type objects. Alternative to this is to replace all of them with a ConcurrentMapClass?, V. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CHAIN-58) Update Chain Context interface to use K,V generics
Update Chain Context interface to use K,V generics -- Key: CHAIN-58 URL: https://issues.apache.org/jira/browse/CHAIN-58 Project: Commons Chain Issue Type: Improvement Affects Versions: 2.0 Reporter: Elijah Zupancic Fix For: 2.0 As discussed in the mailing list, I am suggesting that we change the definition of Context from: -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elijah Zupancic updated CHAIN-58:
-
Description:
As discussed in the mailing list, I am suggesting that we change the definition
of Context from:
{noformat}
public interface Context extends MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
was:As discussed in the mailing list, I am suggesting that we change the
definition of Context from:
Update Chain Context interface to use K,V generics
--
Key: CHAIN-58
URL: https://issues.apache.org/jira/browse/CHAIN-58
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Elijah Zupancic
Fix For: 2.0
As discussed in the mailing list, I am suggesting that we change the
definition of Context from:
{noformat}
public interface Context extends MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CHAIN-58) Update Chain Context interface to use K,V generics
[
https://issues.apache.org/jira/browse/CHAIN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elijah Zupancic updated CHAIN-58:
-
Attachment: chain-58.diff
Update Chain Context interface to use K,V generics
--
Key: CHAIN-58
URL: https://issues.apache.org/jira/browse/CHAIN-58
Project: Commons Chain
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Elijah Zupancic
Fix For: 2.0
Attachments: chain-58.diff
As discussed in the mailing list, I am suggesting that we change the
definition of Context from:
{noformat}
public interface Context extends MapString, Object {
{noformat}
to:
{noformat}
public interface ContextK, V extends MapK, V {
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
