| Task Name | Description | Bugzilla Issue | Skills | Difficulty | Approximate Effort |
|---|
| HA Testing Framework | For testing failover we need a HA test framework. The HA test framework can be based on the TCK. We need a HA RA that functions similar to the TCK RA but works across the cluster on failover. | #39 Priority High | SLEE JBOSS J2EE? | Very Hard | 6 Person Months |
| Distributed Transactional Deployment | We want a single deployment image. Right now each node is individually deployed. We've covered the case of k nodes, with identical deployed images and then one decides to leave. For now we just deploy individually on each node of the cluster. This is a solution that covers one case where everything is pre-deployed and all servers are up before the crash. The harder case is what to do when a node joins. A suggested solution is to put all the generated classes in the cache and share them among cluster members. | Priority High | SLEE JBOSS J2EE? | Very Hard | 4 Person Months |
| More robust SIP RA failover | Currently we don't handle some SIP failure scenarios, one which is mid-transaction. We need some persistant state in the sip RA to handle this case. For example while an INVITE is being processed, if one node fails, the call is lost. One end sees the phone ringing endlessly. Not a good situation. We need to cache the last response of the SBB and retransmit from the new cluster leader if the request is seen again so the failover is transparent. | Priority : High. | JAIN SIP, SLEE, JBOSS J2EE? | Hard | 2 Person Month |
| Concurrency Test Cases | The TCK does not really test concurrency. It tests it mildly but not really. We need some concurrency tests. An idea is to build on the SIPRA again. Ideally we want to stress a service handling multiple concurrent activites and timers. | Priority: High. Unaassigned. | SLEE J2SE? | Hard | 2 Person Months |
| HA Cluster Management | One central control point for the entire cluster. Currently we have multiple JMX consoles. | Priority: Medium | SLEE JBOSS HA J2EE? | Medium Hard | 4 Person Month |
| One top level build system that manages all projects | We need a top level build system leveraging JBoss Build or Maven 2, which can pull in artififact from multuple projects and manage the dependencies between them. This is necessary since the main CVS code base keeps growing and it has to be split into sub-projects. As we are doing that, the continuous build and testsuite run should continue to work effectively across all projects. | Priority: Medium. | Maven ANT | Medium | 3 Person Weeks |
| Performance tuning and bottleneck Identification | Although performance is satisfactory at this stage (1.0b1), we still need to go through the code on a regular basis and identify further performance bottlenecks. | Priority: High | Performance tuning | Hard | 2 Person Month |
| Mobicents Design Document | Sync the design docs up with the code. Need sequence and Class diagrams now that the code has been written ! | Priority : Medium | UML, "MagicDraw" | Medium | 2 Person Month |
| Mobicents Programmers Guide | User friendly how-to with code examples | Priority: Low | SLEE | Medium | 3 Person Months |
| Eclipslee enhancements | User friendly composition of slee services | Priority: Medium | Eclipse, SLEE | Hard | 6 Person Months |
| SLEE-STONE Performance test suite | Light weight resource adaptor and standard set of cannonical SLEE Services to measure SLEE event throughput | Priority : Medium | SLEE | Medium | 3 Person Months |
| Online Profiling | Ability to provide performance profiling data at runtime. Examples include - most active Resource Adaptor, most CPU consuming SLEE Service, SBB with highest number of events processed, top 10 events, call flow graphs with highlighted hot spot arcs and nodes, etc. This task requires deep knowledge of the kernel code. Reference material can be found in the JDK 5 JConsole and Glassfish Management documents. The Slee Graph Viewer prototype can be a starting point. | Priority: Medium | SLEE kernel | Difficulty: Very Hard | 6 Person Months |
| Standardize SIP RA Type | Standardize the SIP RA types so that SIP SBBs can be easily portable between SLEE containers such as Mobicents and Rhino. | #35 Priority Medium | SLEE | Easy | 2 Person Week + JSR Process |
| Container Portability | Abstract out container dependencies so that Mobicents can co-exist with multiple J2EE? containers. For example Glassfish, WebLogic?, WebSphere? | Priority: Medium | SLEE, J2EE? | Hard | 3 Person Months |