[JBoss JIRA] (AS7-4862) Remote EJB SFSB load balancing still very suboptimal
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4862:
-----------------------------------
Summary: Remote EJB SFSB load balancing still very suboptimal
Key: AS7-4862
URL: https://issues.jboss.org/browse/AS7-4862
Project: Application Server 7
Issue Type: Bug
Components: Clustering, EJB
Affects Versions: 7.1.2.Final (EAP)
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.3.Final (EAP)
Looking at the load-balancing again, it seems still wrong. Checking the logs, servers were started *and cluster was formed* ~10 seconds prior to starting the client and load-balancing was roughly:
* node perf18: ~50% of sessions
* node perf19: 0
* node perf20: 0
* node perf21: ~50% of sessions
I let all the session to be created in one minute (not all at once).
The nodes were also specified in the properties.
{noformat}
node perf18
[JBossINF] 07:01:53,991 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (CacheService lifecycle - 1) ISPN000094: Received new cluster view: [perf19/ejb|3] [perf19/ejb, perf21/ejb, perf20/ejb, perf18/ejb]
node perf19
[JBossINF] 07:01:53,781 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-19,null) ISPN000094: Received new cluster view: [perf19/ejb|3] [perf19/ejb, perf21/ejb, perf20/ejb, perf18/ejb]
node perf20
[JBossINF] 07:01:53,781 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-14,null) ISPN000094: Received new cluster view: [perf19/ejb|3] [perf19/ejb, perf21/ejb, perf20/ejb, perf18/ejb]
node perf21
[JBossINF] 07:01:53,780 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-12,null) ISPN000094: Received new cluster view: [perf19/ejb|3] [perf19/ejb, perf21/ejb, perf20/ejb, perf18/ejb]
controller node
2012/05/22 07:02:02:932 EDT [DEBUG][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Setting thread count: 2000, was: 0
2012/05/22 07:02:53:731 EDT [DEBUG][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - All runners (2000) started in 50799 milliseconds
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-5946) jboss-ejb3.xml faults fail silently and result in a hanging thread
by Stephen Coy (JIRA)
Stephen Coy created AS7-5946:
--------------------------------
Summary: jboss-ejb3.xml faults fail silently and result in a hanging thread
Key: AS7-5946
URL: https://issues.jboss.org/browse/AS7-5946
Project: Application Server 7
Issue Type: Bug
Components: EE, EJB
Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1
Environment: MacOS X 10.8.2
java version "1.6.0_35"
Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
Reporter: Stephen Coy
Assignee: David Lloyd
Attachments: migration-demo.tar.gz
The attached maven application project has a subtle typo in a JNDI name in the jboss-ejb3.xml file.
The deployment process results in a hanging thread shown below. There are no diagnostic log messages at all to indicate what the problem could be.
A second consequence of this hung thread is that the server process can only be terminated with a "kill -9 <pid>".
Note that it is deliberately a JEE5 compatible application.
"management-handler-thread - 4" prio=5 tid=7f843c0bf000 nid=0x10a866000 in Object.wait() [10a864000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <7d42d05f8> (a org.jboss.as.controller.ContainerStateMonitor)
at java.lang.Object.wait(Object.java:485)
at org.jboss.as.controller.ContainerStateMonitor.awaitContainerStateChangeReport(ContainerStateMonitor.java:158)
- locked <7d42d05f8> (a org.jboss.as.controller.ContainerStateMonitor)
at org.jboss.as.controller.ModelControllerImpl.awaitContainerStateChangeReport(ModelControllerImpl.java:442)
at org.jboss.as.controller.OperationContextImpl.awaitModelControllerContainerMonitor(OperationContextImpl.java:147)
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:261)
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
at org.jboss.as.server.deployment.DeploymentHandlerUtil$1.execute(DeploymentHandlerUtil.java:123)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
at org.jboss.as.server.deployment.DeploymentDeployHandler.execute(DeploymentDeployHandler.java:75)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
at org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:168)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
at org.jboss.as.controller.CompositeOperationHandler.execute(CompositeOperationHandler.java:85)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:473)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:126)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:111)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Locked ownable synchronizers:
- <7d42a5150> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
- <7d4f3b598> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JGRP-1545) UNICAST2: message sent before channel is connected leads to exception
by Bela Ban (JIRA)
Bela Ban created JGRP-1545:
------------------------------
Summary: UNICAST2: message sent before channel is connected leads to exception
Key: JGRP-1545
URL: https://issues.jboss.org/browse/JGRP-1545
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
When a *unicast* request is received before the first view is received (which sets the channel to connected), and a response to the request is sent, then the response sending throws an exception as the channel hasn't yet been connected (see stack trace below).
Reason:
What happens when a channel is created is:
- JChannel.connect() is called by the user
- As part of this, start() is called in every protocol
- UDP.start() creates the sockets and starts the socket listener which will receive messages from now on and pass them up
- Connect() now sends a JOIN request to the coordinator and receives the JOIN response or become singleton member
- In either case, a new view is installed, which sets the channel to connected
If, between starting the socket listener and setting the channel to connected, a *unicast* message is received, and it sends a response then you'll get the behavior below.
In NAKACK2, this doesn't happen, as all messages received in the same time frame are queued and replayed when the channel becomes connected.
I could implement the same behavior for UNICAST2, but I'd like to know more about how you got into this situation. What were the steps executed ?
The only way this could happen I can think of is that the coordinator sent a unicast message to P right after it sent the JOIN response to P, e.g. in the view change which includes P. Does this happen in Infinispan code ?
{quote}
13:29:45,467 ERROR (OOB-1,ISPN,NodeB-50197:) [UNICAST2] couldn't deliver OOB message [dst: NodeB-50197, src: NodeA-40526 (3 headers), size=118 bytes, flags=OOB|DONT_BUNDLE]
java.lang.IllegalStateException: channel is not connected
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:621)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:535)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:604)
at org.jgroups.JChannel.up(JChannel.java:688)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
at org.jgroups.protocols.FC.up(FC.java:479)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:736)
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:606)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
at org.jgroups.protocols.Discovery.up(Discovery.java:359)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1294)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1857)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1830)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-5913) RAR (inbound adapter) inside EAR does not see JAR files in EAR/lib
by Juan José Olmedilla Arregui (JIRA)
Juan José Olmedilla Arregui created AS7-5913:
------------------------------------------------
Summary: RAR (inbound adapter) inside EAR does not see JAR files in EAR/lib
Key: AS7-5913
URL: https://issues.jboss.org/browse/AS7-5913
Project: Application Server 7
Issue Type: Bug
Environment: JBoss 7.1.2 on Windows 7 and Windos Vista
Reporter: Juan José Olmedilla Arregui
-I have a RAR file and EJB JAR inside my EAR.
The RAR includes several JAR libraries only used by it which are packed within it.
- The EJB JAR includes an MDB that receives the inbound messages from the Resource Adapter and therefore needs to have access to the same MessageListener interface which is in the common JAR file library included in EAR/lib.
- The RAR has a dependency on the common MessageListener interface included in the JAR file sitting in EAR/lib
- The project is a maven multi-module project using maven jar (for the commong library where the interface is), ejb, ear and rar plugins
- Things I have tried:
1. Including "compile" dependency to the common jar in both, the EJB JAR and RAR. It does not work because it includes two copies of the jar, one in the EAR/lib and one inside the RAR, it deploys but later it fails when a message is received because there are two different bytecodes for the same class.
2. Including a Dependency in the MANIFEST of the RAR pointing to deployment.EARNAME.ear.MYLIBNAME.jar. It does not find that dependency
3. Including a Dependency in the MANIFEST of the RAR pointing to deployment.EARNAME.ear.lib.MYLIBNAME.jar. It does not find that deployment
4. Including the dependency as "provided" in the EJB project as in the RAR, including in both MANIFEST's a dependency on "deployment.MYLIBNAME.jar" and deploying separately the MYLIBNAME.jar and EARNAME.ear. This works but I want a solution that allows me to pack everything in one single EAR file
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6040) Remove the arquillian/service code as it is dead code
by Navin Surtani (JIRA)
Navin Surtani created AS7-6040:
----------------------------------
Summary: Remove the arquillian/service code as it is dead code
Key: AS7-6040
URL: https://issues.jboss.org/browse/AS7-6040
Project: Application Server 7
Issue Type: Task
Affects Versions: 7.2.0.CR1
Reporter: Navin Surtani
Assignee: Navin Surtani
Fix For: 7.2.0.Alpha1
The code in the arquillian/service has been moved to the jmx protocol module. As a result, it should be removed from the AS 7 code base.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JBAS-2473) Remote side ClassCastExceptions as a result of WrapperDataSourceService using "getInterfaces()" to create Proxies.
by Leonardo Mendoza (JIRA)
[ https://issues.jboss.org/browse/JBAS-2473?page=com.atlassian.jira.plugin.... ]
Leonardo Mendoza commented on JBAS-2473:
----------------------------------------
I would like to re-open this issue.
In my testing of JBoss 4.0.4.GA, 5.1.0.GA, and 6.1.0.Final I've always encountered ClassCastExceptions when DatabaseMetaData methods that return ResultSets are called.
According to this post on the ~StackOverflow website: [Java.lang.reflect.Proxy returning another proxy from invocation results in ClassCastException on assignment | http://stackoverflow.com/questions/2642700/java-lang-reflect-proxy-return...], the method that retrieves all interfaces implemented by the provided class needs to use a transitive closure to properly get the interfaces.
The {{org.jboss.util.Classes.getAllInterfaces(Class)}} needs to change so that it properly retrieves all implemented interfaces:
{code:title=org.jboss.util.Classes - current implementation}
/**
* Populates a list with all the interfaces implemented by the argument
* class c and all its superclasses.
*
* @param allIfaces - the list to populate with the interfaces
* @param c - the class to start scanning for interfaces
*/
public static void getAllInterfaces(List allIfaces, Class c)
{
while (c != null)
{
Class[] ifaces = c.getInterfaces();
for (int n = 0; n < ifaces.length; n ++)
{
allIfaces.add(ifaces[n]);
}
c = c.getSuperclass();
}
}
{code}
{code:title=org.jboss.util.Classes - FIXED implementation}
/**
* Populates a list with all the interfaces implemented by the argument
* class c and all its superclasses.
*
* @param allIfaces - the list to populate with the interfaces
* @param c - the class to start scanning for interfaces
*/
public static void getAllInterfaces(List allIfaces, Class c)
{
allIfaces.addAll(getInterfaces(c));
}
/**
* Correctly gets all interfaces implemented by the given class.
* {@code Class.getInterfaces()} returns only the interfaces DIRECTLY
* implemented by the class. You need a transitive closure to obtain all the
* interfaces.
* Solution taken from http://stackoverflow.com/questions/2642700/java-lang-reflect-proxy-return...
* @param clazz the class to get all the interfaces from.
* @return all interfaces implemented by {@code clazz} and its superclasses.
*/
private static List<Class<?>> getInterfaces(Class<?> clazz) {
List<Class<?>> interfaces = new ArrayList<Class<?>>();
if (clazz.isInterface()) {
interfaces.add(clazz);
} else {
do {
addInterfaces(clazz, interfaces);
clazz = clazz.getSuperclass();
} while (clazz != null);
}
for (int i = 0; i < interfaces.size(); ++i) {
addInterfaces(interfaces.get(i), interfaces);
}
return interfaces;
}
/**
* Helper method used by {@code getInterfaces(...)} for getting all the
* interfaces implemented by {@code clazz} and its superclasses.
* @param clazz the class to get all the interfaces from.
* @param interfaces the {@code List} of interfaces implemented by
* {@code clazz} and its parent classes.
*/
private static void addInterfaces(Class<?> clazz, List<Class<?>> interfaces) {
for (Class<?> intf : clazz.getInterfaces()) {
if (!interfaces.contains(intf)) {
interfaces.add(intf);
}
}
}
{code}
I have tested this code on 5.1.0.GA and it works without issue.
> Remote side ClassCastExceptions as a result of WrapperDataSourceService using "getInterfaces()" to create Proxies.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: JBAS-2473
> URL: https://issues.jboss.org/browse/JBAS-2473
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remoting
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: Windows XP, jdk1.5.0_05
> Reporter: J Barkanic
> Fix For: JBossAS-4.0.4.CR2, JBossAS-5.0.0.Beta1
>
>
> The methods, createStatementProxy and createResultSetProxy in WrapperDataSourceService use Object.getClass().getInterfaces() to gather interface information in order to create proxies to the database driver Statement and ResultSet objects. However, if the underlying driver implementation objects inherit their interfaces from a superclass, "getInterfaces()" will not return those interfaces. (Derby Embedded driver does this for ResultSet) This causes a ClassCastException on the remote side.
> Other methods like createDatabaseMetaData just set the java.sql interface explicitly when creating the proxy. (I don't know if there was a reason not to do this in these two methods).
> public interface MyInterface{
> public void interfaceMethod();
> }
> public abstract class MyObjectA implements MyInterface{
> public void interfaceMethod(){
> //Implement interface
> }
> }
> public class MyObjectB extends MyObjectA{
> public void interfaceMethod(){
> //Overridden implementation
> }
> }
> public class Tester{
> public static void main(String[] args){
> MyObjectB b = new MyObjectB();
> Class[] ifaces = b.getClass().getInterfaces(); //<----------- This will not contain MyInterface
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-5792) Deadlock detection for Entity beans
by Christian Inzko (JIRA)
Christian Inzko created AS7-5792:
------------------------------------
Summary: Deadlock detection for Entity beans
Key: AS7-5792
URL: https://issues.jboss.org/browse/AS7-5792
Project: Application Server 7
Issue Type: Feature Request
Components: EJB
Affects Versions: 7.1.1.Final
Environment: Windows 7 64 bit, Java 1.7.0 64 bit
Reporter: Christian Inzko
Assignee: jaikiran pai
Deadlock detection with EJB 2.1 entity beans and pessimistic locking does not work.
We are migrating our application from Jboss 4.05 where we used entity beans. This jboss version was able to detect deadlock situations and throw a org.jboss.util.deadlock.ApplicationDeadlockException. This mechanism does no longer work - instead of that both transactions just hang until a transaction timeout is reached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-4707) Preventing reconnect attempt of remote ejb client
by Serkan Yıldırım (JIRA)
Serkan Yıldırım created AS7-4707:
------------------------------------
Summary: Preventing reconnect attempt of remote ejb client
Key: AS7-4707
URL: https://issues.jboss.org/browse/AS7-4707
Project: Application Server 7
Issue Type: Bug
Components: Remoting, Server
Affects Versions: 7.1.1.Final
Reporter: Serkan Yıldırım
Assignee: David Lloyd
Priority: Blocker
Hi,
I have a remote ejb client and a custom login module. I am testing my login module, i enter an invalid password in remote client. My login module runs correctly and send an exception. However, remote client attempts to recall login module again to login user. But i do not want this. Because when there is an exception in my custom login module, i update some values in my database. Therefore the same code in login module runs twice and my db has inconsistent values. So how can i prevent this reconnect attemp of remote ejb client? I use JBOSS 7.1.2 Final SNAPSHOT version in server and jboss 7.1.1 client maven dependencies. Thanks.
My Client code is like below:
Properties pr = new Properties();
pr.put("endpoint.name", "client-endpoint");
pr.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false");
pr.put("remote.connections", "default");
pr.put("remote.connection.default.port", "4447");
pr.put("remote.connection.default.host", "localhost");
pr.put("remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER");
pr.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false");
pr.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");
pr.put("remote.connection.default.username", "user1");
pr.put("remote.connection.default.password", "Test12345");
EJBClientConfiguration cc = new PropertiesBasedEJBClientConfiguration(pr);
ContextSelector < EJBClientContext > selector = new ConfigBasedEJBClientContextSelector(cc);
EJBClientContext.setSelector(selector);
Properties props = new Properties();
props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
props.put("jboss.naming.client.ejb.context", true);
try {
Context c = new InitialContext(props);
kullaniciEJB = (KullaniciEJBRemote) c.lookup("ejb:merveys-kayit-tckkys/merveys-kayit-ejb-tckkys//KullaniciEJB!tr.gov.tubitak.bilgem.uekae.deys.tckk.merveys.common.controller.ejb.kullanici.KullaniciEJBRemote");
} catch (NamingException e) {
e.printStackTrace();
}
int count = kullaniciEJB.countKartIslemList(1L, null, null);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months