Release Notes

All GUIs: The new context triggered help system is out now!

We have been working on a new help system. It is a mix of UX improvements with empty states and a smart help that guides you while you learn how to master Plastic SCM.

It is implemented as a panel in all views that shows up to help you discover new features you never used, or in response to events that might be causing frustration.

It is better explained with an example: suppose you frantically click the "refresh" button of the labels view. Chances are you are not finding something you are looking for, otherwise you wouldn't click it so frequently. And, suppose you have a filter in the view that is preventing you to see what you are looking for. The GUIs will detect this and show a panel highlighting that you have a filter set and that's probably why you are not finding what you are looking for.

Another example: have you ever colored your Branch Explorer based on the authors of the changesets? The help system will help you discover that.

The new system comes with a good amount of art in the form of a new mascot: our wise Owl, a smart and methodic librarian that aligns well with the Plastic philosophy: preserve history to learn from it.

This new help system is a starting point to improve onboarding, usability and to help users becoming experts on version control in an active way.

Gluon: We improved the performance of the size calculation. Now it's about 5 times faster than before.

Server: New threadpool boosting system to avoid running out of threads when something goes wrong and some operations are blocked.

== How to see this new system in action ==

If this ever happens, you'll see the following on your server log:

 2018-11-16 12:12:10,851 49 (null)    WARN  WorkerThreadPool - All threads are busy attending methods. Spawning 1 new. Something must be going wrong.

== How it works ==

Suppose you have a situation like this, with 5 methods blocking the server:

    ACTIVE METHOD CALLS
    Name                                      Request IP              Time      Thread   Status   Protocol  Sec  User
    GetRepositoryList                             107 127.0.0.1       00:00:01  47       Run      Plastic   None S-1-5-21-514181465-233650702-1722984433-1000
    GetRepositoryList                             102 127.0.0.1       00:00:40  66       Run      Plastic   None S-1-5-21-514181465-233650702-1722984433-1000
    GetRepositoryList                             101 127.0.0.1       00:00:40  65       Run      Plastic   None S-1-5-21-514181465-233650702-1722984433-1000
    GetRepositoryList                              99 127.0.0.1       00:00:41  62       Run      Plastic   None S-1-5-21-514181465-233650702-1722984433-1000
    GetRepositoryList                              98 127.0.0.1       00:00:41  63       Run      Plastic   None S-1-5-21-514181465-233650702-1722984433-1000
    0 requests enqueued. 5 worker threads (0 free)

It shouldn't happen, but sometimes we found issues on very slow networks, or bugs, that blocked some requests.

Now, the server tries to attend a new request, and it enqueues it, and before this fix it had to wait for a free thread.

But now, the following will happen:

 2018-11-16 12:12:10,851 49 (null)    WARN  WorkerThreadPool - All threads are busy attending methods. Spawning 1 new. Something must be going wrong.

And a new thread will be created to attend the new request.

== What if there are many enqueued requests ==

If that's the case, the following happens:

2018-11-16 12:11:15,655 49 (null)    WARN  WorkerThreadPool - All threads are busy attending methods. Spawning 6 new. Something must be going wrong.

A new batch of threads will be added to the thread pool (up to the thread pool limit which is normally the number of cores).