The main (and probably only) issue I have with [http://www.jfree.org/jfreechart/ JFreeChart] is its licensing, LGPL 2.1. [https://github.com/knowm/XChart XChart], on the other hand, is licensed under ASL 2.0, the same as for JPPF.
Currentlly, methods in the [https://www.jppf.org/javadoc/6.2/index.html?org/jppf/management/forwarding/JPPFNodeForwardingMBean.html JPPFNodeForwardingMBean] class returns a mapping of node uuids to the result of the JMX request on the specified mbean for each node. For example:
This current approach has several flaws:
* we document in the javadoc that the value of each entry in the returned map is either a JPPFNodeSate or an Exception, but there is nothing to enforce it at compile time
* invocations that return null are often not included in the map, therefore we can't know exactly which nodes the request was sent to
Instead, we propose to enforce the type of the results with an interface like this:
Where InvocationResult would expose the following methods:
To achieve this, we propose the following steps:
* deprecate JPPFNodeForwardingMBean and related classes and APIs, but keep the mbean alive and active so it does not break existing code that uses it
* define a new MBean which provides a very similar API but with strong typing of the results. Thus, there will be 2 mbeans doing the same thing until the deprecated one is removed.
Currently the [https://www.jppf.org/doc/6.2/index.php?title=Management_and_monitoring management and monitoring] documentation is not up to date:
* not all MBeans are documented
* some of the documented MBeans have erroneous, missing or out-of-date information
* docuemntation on accessing the MBeans is not well structured and confusing
Additionally, there is no meanningful description of the mbeans and their operations and attributes that can be accessed at runtime.
We propose to:
* reorganize the documentation on management accordingly
* provide a way to inject descriptive information in the MBeans, which can be retrieved when the MBeans are "live" via the MBeanInfo API, for instance using external tools such as JConsole or VisualVM. It could also be used to automatically generate a reference documentation on the MBeans.
We propose to test the admin console and the underlying grid topology and job monitoring APIs it is based in order to find eventual performance issues and fix them. We shall perform stress and performance tests, along with profiling sessions and take action based on the findings.
We have noted several areas that can be improved preformance-wise, including:
* as shown by profiling drivers and nodes, polling of the default [https://www.jppf.org/doc/6.0/index.php?title=Monitoring_data_providers monitoring data provider] incurs an excessive CPU usage due to the use of com.sun.management.OperatingSystemMXBean for system and process CPU usage
* computation of the persistence identifier for the load-balancer state of each connection is also time-consuming, due to using methods for the discovery of the system's network interfaces and IP addresses. This computation is performed unconditionally, but can be avoided when load-balancer persistence si disabled
* the class [https://github.com/jppf-grid/JPPF/blob/master/common/src/java/org/jppf/utils/NetworkUtils.java NetworkUtils], which discovers the local system's network interfaces and IP addresses, can be improved by caching the IP addresses of the system, and discovering them once and for all at class loading time (static initializer)
From [https://www.jppf.org/forums/index.php/topic,8063.0.html this forums thread].
The constrcutor for org.jppf.execute.AbstractExecutionManager is as follows:
The problem here is in the statement "poolSize = JPPFConfiguration.get(nbThreadsProperty);", which uses the global configuration instead of the config for the JPPF component (client or node) which initializes the execution manger.
Instead, the constructor should have the following signature:
We propose to implement a DSL and asociated API for expressing job selectors in a way similar to what we have for [https://www.jppf.org/doc/6.2/index.php?title=Execution_Policies execution policies]. This will significantly improve the expressiveness of job selectors, without having to resort to [https://www.jppf.org/doc/6.2/index.php?title=Server_management#Scripted_job_selector scripted job selectors] for complex selection functions.
This DSL would include a number of predicates and operators:
* boolean predicates: and, or, xor, not
* comparison operators for Comparable metadata values: ==, !=, <, <=, >, >=, between (including or excluding upper and lower bounds)
* contains, one of, regex matching
* any other predicate that we migth find useful or convenient
The attached dependency-check report lists a number of vulnerabilities in the PPF dependencies. So far, all vulnerabilities are found in the web admin console and tied to wicket. We will need to upgrade the version of Apache Wicket to 8.x (currently 7.4.0), which was overdue anyway