You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@karaf.apache.org by "Matej Ferencak (JIRA)" <ji...@apache.org> on 2015/11/16 17:01:10 UTC

[jira] [Created] (KARAF-4115) Hard coded timeout values for shell commands in Karaf and Cellar

Matej Ferencak created KARAF-4115:
-------------------------------------

             Summary: Hard coded timeout values for shell commands in Karaf and Cellar
                 Key: KARAF-4115
                 URL: https://issues.apache.org/jira/browse/KARAF-4115
             Project: Karaf
          Issue Type: Bug
          Components: cellar-core, karaf-shell
    Affects Versions: 4.0.3, 3.0.5
            Reporter: Matej Ferencak


In Cellar, all commands seem to be set to timeout after 10s.

This is causing us a lot of problems in situations when there are multiple Karaf Instances deployed on multiple nodes (we usually deploy a total of 12-14 overall instances on 4 different VMs), when Hazelcast tends to be really slow due to network traffic during cluster synchronization.
In such a setup, running *cluster:group-set* can be very slow, and 50% of the time it times out. Once this happens, the node is unuseable, i.e. it enters an undefined state where it can not easily join or quit a cluster group any more.


There are a couple of places in code where this can be found:
org.apache.karaf.cellar.core.command.Command : timeout = 10000
org.apache.karaf.cellar.core.event.EventDispatchTask : timeout = 10000
(referencing Karaf 4.0.3 master)

I can't find it right now, but a very similar thing seems to be implemented in Karaf Shell, where I think I saw the value being bumped from 10s to a higher value of 30s at some point in history (but still hard coded).

Currently, we are working around this by re-implementing the *cluster:group-set* by invoking Karaf Cellar services directly (ClusterManager & GroupManager). Since we implemented this, we don't have problems with cluster set up any more.

It would be great if this value could be somehow made configurable, or as the last resort, increased.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)