JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
feature_request_small.png
CLOSED  Feature request JPPF-528  -  Restructuring of and major improvements to the documentation
Posted Mar 15, 2018 - updated Oct 06, 2018
action_vote_minus_faded.png
0
Votes
 action_vote_plus_faded.png
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Feature request
  • Status
     
    		 Closed
  • Assigned to
    lolo4j
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
    lolo4j
  • Owned by
    Not owned by anyone
  • Category
    Documentation
  • Resolution
    RESOLVED
  • Priority
    High
  • Targetted for
    icon_milestones.png JPPF 6.0
Issue description
Excellent feedback, suggestions and comments from a long-time JPPF user:
  1. It is not obvious that JPPF benefits from multiple core processors. We might want to make that more obvious, as it might help attract more users and help people decide what kind of cloud service or physical servers to use. People might be wasting time multi-threading their programs when it would be better to use JPPF. There was a time when Rackspace had only single core servers. JPPF would have been fine for that. Linode has many cores and to use them with JPPF is not wasteful. To go from one to the other requires no programming changes. To go from one to the other requires no configuration changes. To me this was a non-obvious benefit of JPPF.
  2. It isn't obvious either that JPPF is probably better for many small tasks rather than a few long elapsed time tasks. That is, 64 million tasks of 10 seconds each is better than 64 tasks of 10 million seconds each. Knowledge of this might save people some rewriting effort.
  3. The documentation is kind of discouraging and lengthy. This results in readers/users being unwilling or unable to read the whole thing because they cannot grasp the relevance of much of it. I haven't looked at the documentation in recent years so perhaps my comment is no longer relevant. Yes it is!
  4. The following use case is typical: homogeneous tasks, each task would last many hours, one task per processor core, no internet and no database since everything required is in the serialized object passed to each processor core. The fact that it is typical may lead users to think they can set up JPPF by themselves, but in the end they actually need help found in the forums. The allocation decisions JPPF makes are often very difficult to understand (i.e. how the tasks are distributed to the nodes). In particular, it is difficult to understand the "nodethreads" algorithm. A suggestion is that each typical case be matched with a brief cheat sheet.
  5. It is not obvious where to enable assertions. It was observed that it needed to be in 2 places: the invocation of the application and inside the node configuration file. It is not obvious that it is not necessary in to enable assertions for the invocation of the driver, the configuration file of the driver, the invocation of the node. This would be good to put on a cheat sheet.
  6. When an application might need more memory it is not obvious that it is not necessary to increase it for the driver launcher, the node launcher, and the driver configuration, but rather it must be done for the application and in the node properties. This would be good to put on a cheat sheet.
  7. For some applications virtual memory doesn't solve a problem; it creates a problem. VM is probably helpful mainly in applications where the memory need is highly variable across time. A compute intensive application might have a nearly constant level of needed memory. If swapping happens at all, not only will it will slow progress, what is worse is that it will probably persist for hours. It was found that it is best to disable swapping and discover as soon as possible if more physical memory is needed. While this is not a JPPF specific problem it might be relevant for some it would help to know this as soon as possible in the development life cycle.
  8. Files that contain the "jppf.jvm.options" property are probably more relevant for the user so perhaps it would be good to point out that some configuration files are not important and the configuration files are long but there are only a few lines that matter to some (or most) users. It can be useful to see suggestions like: "do not waste time looking at log4j-node.properties" because you will not enable assertions there and you will not increase memory there.
  9. It is a minor point but sometimes the word "server" appears and it is confusing because everything is a server. The line "#jppf.server.host=localhost" is confusing. If the reader thinks a node is a "server" because the driver is a "master", he will be more confused because he will think this property is supposed to point to a node. The default value "localhost" is confusing because the majority of the time it will not be local. Perhaps it could be "#jppf.driver.host=IPADDRESS".

#3
Comment posted by
lolo4j
May 04, 08:52
Point 1. addressed in the front page of the web site, and also in the about page, section "Extreme scalability"

Point 2. adressed in the doc in JPPF Overview > Jobs and tasks granularity. Also moved the JPPF Overview chapter to 2nd position, before the tutorial.
#4
Comment posted by
lolo4j
Jul 18, 08:00
I have now reorganized and (I hope) clarified the doc on configuring a JPPF server, node and client. Any feedback is welcome smileys/2.png