You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@jmeter.apache.org by Philippe Mouawad <ph...@gmail.com> on 2015/12/28 23:23:00 UTC

Issue in CheckDirty and its relation to ActionRouter

Hello,
Currently there is an issue in ActionRouter#getInstance()
It returns a partially initialized object so a fix would be to use a local
object and affect it :
    public static ActionRouter getInstance() {
        if (router == null) {
            synchronized (LOCK) {
                if(router == null) {
                    ActionRouter router = new ActionRouter();
                    router.populateCommandMap();
                    ActionRouter.router = router;
                }
            }
        }
        return router;
    }


But due to CheckDirty using getInstance() in its constructor to register
itself as a PreAction to ExitCommand, it leads to a StackoverflowError.

Even without fixing this issue, it reveals an issue that could occur if a
Constructor of an AbstractCommand subclass uses ActionRouter.getInstance()

Regards
Philippe

Re: Issue in CheckDirty and its relation to ActionRouter

Posted by Philippe Mouawad <ph...@gmail.com>.

Issue fixed by sebb
Thanks

On Monday, December 28, 2015, Philippe Mouawad <ph...@gmail.com>
wrote:

> Hello,
> Currently there is an issue in ActionRouter#getInstance()
> It returns a partially initialized object so a fix would be to use a local
> object and affect it :
>     public static ActionRouter getInstance() {
>         if (router == null) {
>             synchronized (LOCK) {
>                 if(router == null) {
>                     ActionRouter router = new ActionRouter();
>                     router.populateCommandMap();
>                     ActionRouter.router = router;
>                 }
>             }
>         }
>         return router;
>     }
>
>
> But due to CheckDirty using getInstance() in its constructor to register
> itself as a PreAction to ExitCommand, it leads to a StackoverflowError.
>
> Even without fixing this issue, it reveals an issue that could occur if a
> Constructor of an AbstractCommand subclass uses ActionRouter.getInstance()
>
> Regards
> Philippe
>
>

-- 
Cordialement.
Philippe Mouawad.