Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Subject: Re: Proposal: New Lock for failing Karaf start if running
To: dev@karaf.apache.org
References: 
 <CAAViHOkEdeL+a5M41qPbTbHHr_pSXNiZ5dx1PPzsmM8D0R=jhw@mail.gmail.com>
 <565EB6AA.5040000@nanthrax.net>
 <CAAViHOmzjuU7=mEX52=TiPkPmX9n+UQN23gKZrkdYVq4gMtu5g@mail.gmail.com>
From: =?UTF-8?Q?Jean-Baptiste_Onofr=c3=a9?= <jb@nanthrax.net>
Message-ID: <565F1A7C.1090201@nanthrax.net>
Date: Wed, 2 Dec 2015 17:21:16 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
 <CAAViHOmzjuU7=mEX52=TiPkPmX9n+UQN23gKZrkdYVq4gMtu5g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hey Fabian,

Do you mind if I create the Jira and try a hack ?

Regards
JB

On 12/02/2015 05:18 PM, Fabian Lange wrote:
> HI,
> yes I understand the current solution. It is really nice. My request was
> for a much simpler much more basic feature.
>
> karaf.lock.exclusive
>
> would probably be what I need. But I would not know how to implement that
>
> Fabian
>
> On Wed, Dec 2, 2015 at 10:15 AM, Jean-Baptiste Onofré <jb@nanthrax.net>
> wrote:
>
>> Hi Fabian,
>>
>> the purpose is also to be able to "prepare" the slave instance, so the
>> instance has to be started somehow.
>>
>> However, what you propose could make sense in some use case. Maybe we can
>> add a karaf.lock.exclusive property to define this behavior.
>>
>> WDYT ?
>>
>> Regards
>> JB
>>
>>
>> On 12/02/2015 09:32 AM, Fabian Lange wrote:
>>
>>> Hi,
>>> to my surprise I saw that while Karaf has a sweet failover mechanism, it
>>> does not provide means to actually prevent startup of a second instance,
>>> should the use case require it.
>>> i can turn Lock off, but then I can start as many instances as I like
>>> (which subsequently have bundle issues due to activators not able to bind
>>> ports).
>>> And I can wait for previous instances to terminate by using File or JDBC
>>> lock.
>>> In my case I want the second start to fail.
>>>
>>> Would it be sufficient to subclass SimpleFileLock, and to overwrite
>>>
>>> boolean lock() throws Exception {
>>>    boolean locked = super.lock();
>>>    if (!locked) throw new RuntimeException("startup aborted");
>>>    return true;
>>> }
>>>
>>> or would that be not a great idea?
>>>
>>> if you think its useful I can make this nice and package as PR
>>>
>>> Fabian
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com