Refactoring suggestions

1. ArrayBlockingQueue used in AnalyzerCell.java is leading to extreme form of synchronization between consecutive stages of a pipeline. This synchronization is observed when we have the ArrayBlockingQueue filled to the capacity of 100 packets.
2. The AnalysisRepository, SaveRepository and ElasticSearchConfig classes use factory classes to create objects inside the methods. This leads to untestable code.
3. Each Generic Analyzer Cell gives a packet to the next cell on line-174. The packet is offered on a time-bound basis (please see line-111). This arrangement has the potential to lose packets between pipeline stages.
4. The packet reception part of AnalyzerCell.java uses poll() method which sporadically gives null values. This is giving raise to thread exceptions and incorrect program termination.
5. During the packet processing, a custom analyzer can receive a packet, determine the payload, copy the headers and pass on the packet to the next stage in the pipeline. This is the principle of fast path - slow path applied to analyzer cell itself. In order to make this possible, the analyzer cell may need to have threads in itself. Rather, the custom analyzers need to be active threads.
6. Update all the dependencies to the latest versions.
7. Move the application configuration variables to correct locations, see issue #90.
8. The Experiment run by Session class does not indicate its status of completion to anyone. It is better to convert all the Runnable classes to Callable with Futures so that the completion status can be enquired from with in and outside the Session class.
   Without such a facility, we have to poll the Elastic Search in order to find out the completion status of the experiment. Please see issues #95, #109.
9. When two experiments are started concurrently, the event bus of the custom analyzers get changed. All the event bus wirings / mappings of custom analyzers belonging of generic analyer cell get changed to the last created event bus. As expected, the last created event bus is the internal event bus of generic analyzer cells belonging the last created experiment. As a result, the elastic search queries from all experiments go to AnalysisRepository of last experiment. Thus only last created experiment finishes; none of the other experiments finish.
   Carefully check the autowiring of all event buses in an experiment. They should all be unique across the application.

Future Improvements (after testing, refactoring and bug fixes)

1. Support for new protocols, see issue #36.
2. Integration of ElasticStack into the project, see issue #28.
3. Secure access to Elastic Search stack, see issue #42, #55.
4. Dynamic loading of new custom protocol analyzers, see issue #38.
5. Front-end work
   1. Display all the analyzed protocols in the packet, see issue #85.
   2. Sign up error on front page, see issues #46, #76.
   3. Retain focus on the selected packet, see issue #86.
   4. Smooth loading of analysis view, see issue #91.
   5. Remote access to Darshini application, see issue #108.
   6. Sharing of experiments with other researchers, see issue #87.
   7. Configurable Elastic Search location for front end, see issue #129.
   8. Input validation on all pages of front-end, see issue #39.
   9. Integrate markdown editor into the experimental description page. The editor must support text and code editing for P4 graphs, see issues #99, #104.
   10. Keyboard navigation of the webpages, see issue #77.
6. Move all the model (data structure) logic to the backend, see issue #126.
7. Scripts for common tasks, see issue #72.
8. Architectural lessons from other projects, see issue #16.
9. Dynamic switching of persistence mode with multi-DB support, see issue #98.
10. Elastic Stack optimization, see issue #51.