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)