Re: Broker-J and database configuration

2018-02-19 Thread Oleksandr Rudyy 
Thanks Olivier,

I'll review the changes

On 19 February 2018 at 16:54, VERMEULEN Olivier
 wrote:
> Hello Alex,
>
> I just pushed a pull-request on the master.
> Note that I also had to modify some locales in a few unit tests to be able to 
> run them on my machine.
>
> Regards,
> Olivier
>
> -Original Message-
> From: Oleksandr Rudyy [mailto:oru...@gmail.com]
> Sent: mercredi 7 février 2018 11:06
> To: users@qpid.apache.org
> Subject: Re: Broker-J and database configuration
>
> Hi Olivier,
>
> The attachments have been stripped from the message.
>
> Though, I can confirm that Broker continue to operate as normal when one or 
> more virtual hosts fail to start.
> Broker users can use management interfaces to fix the problem with ERRORED 
> virtual host(s) or even create new virtual hosts if required.
> At the moment, Broker only reports warning on start-up when any of the direct 
> children fails to start and transits into ERRORED state.
> By setting context variable 'broker.failStartupWithErroredChild' to 'true', 
> the Broker does not start with any direct child in ERRORED state but that 
> does not include Virtual Host, as Virtual Host is not direct child of the 
> Broker.
>
> A improvement JIRA QPID-7972 [1] was raised to put Virtual Host Node into 
> error state if the underlying Virtual Host is in error state. We do not have 
> plans to include the work for the JIRA into upcoming releases. Please, fill 
> free to contribute the patch for it to speed up the inclusion of improvement 
> into new releases.
>
> Kind Regards,
> Alex
>
>
> [1] https://issues.apache.org/jira/browse/QPID-7972
>
>
> On 6 February 2018 at 11:01, VERMEULEN Olivier  
> wrote:
>> Hello,
>>
>>
>>
>> When the Java broker fails to connect to the database I get an error
>> in the logs but the broker keeps starting normally and is considered
>> as “ready “ in the end…
>>
>> You can check the log file attached. I reproduced the problem by
>> specifying a wrong derby database in the configuration.
>>
>>
>>
>> Thanks,
>>
>> Olivier
>>
>> ***
>>
>> This e-mail contains information for the intended recipient only. It
>> may contain proprietary material or confidential information. If you
>> are not the intended recipient you are not authorised to distribute,
>> copy or use this e-mail or any attachment to it. Murex cannot
>> guarantee that it is virus free and accepts no responsibility for any loss 
>> or damage arising from its use.
>> If you have received this e-mail in error please notify immediately
>> the sender and delete the original email received, any attachments and
>> all copies from your system.
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For
>> additional commands, e-mail: users-h...@qpid.apache.org
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional 
> commands, e-mail: users-h...@qpid.apache.org
>
> ***
>
> This e-mail contains information for the intended recipient only. It may 
> contain proprietary material or confidential information. If you are not the 
> intended recipient you are not authorised to distribute, copy or use this 
> e-mail or any attachment to it. Murex cannot guarantee that it is virus free 
> and accepts no responsibility for any loss or damage arising from its use. If 
> you have received this e-mail in error please notify immediately the sender 
> and delete the original email received, any attachments and all copies from 
> your system.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

RE: Broker-J and database configuration

2018-02-19 Thread VERMEULEN Olivier 
Hello Alex,

I just pushed a pull-request on the master.
Note that I also had to modify some locales in a few unit tests to be able to 
run them on my machine.

Regards,
Olivier

-Original Message-
From: Oleksandr Rudyy [mailto:oru...@gmail.com] 
Sent: mercredi 7 février 2018 11:06
To: users@qpid.apache.org
Subject: Re: Broker-J and database configuration

Hi Olivier,

The attachments have been stripped from the message.

Though, I can confirm that Broker continue to operate as normal when one or 
more virtual hosts fail to start.
Broker users can use management interfaces to fix the problem with ERRORED 
virtual host(s) or even create new virtual hosts if required.
At the moment, Broker only reports warning on start-up when any of the direct 
children fails to start and transits into ERRORED state.
By setting context variable 'broker.failStartupWithErroredChild' to 'true', the 
Broker does not start with any direct child in ERRORED state but that does not 
include Virtual Host, as Virtual Host is not direct child of the Broker.

A improvement JIRA QPID-7972 [1] was raised to put Virtual Host Node into error 
state if the underlying Virtual Host is in error state. We do not have plans to 
include the work for the JIRA into upcoming releases. Please, fill free to 
contribute the patch for it to speed up the inclusion of improvement into new 
releases.

Kind Regards,
Alex


[1] https://issues.apache.org/jira/browse/QPID-7972


On 6 February 2018 at 11:01, VERMEULEN Olivier  
wrote:
> Hello,
>
>
>
> When the Java broker fails to connect to the database I get an error 
> in the logs but the broker keeps starting normally and is considered 
> as “ready “ in the end…
>
> You can check the log file attached. I reproduced the problem by 
> specifying a wrong derby database in the configuration.
>
>
>
> Thanks,
>
> Olivier
>
> ***
>
> This e-mail contains information for the intended recipient only. It 
> may contain proprietary material or confidential information. If you 
> are not the intended recipient you are not authorised to distribute, 
> copy or use this e-mail or any attachment to it. Murex cannot 
> guarantee that it is virus free and accepts no responsibility for any loss or 
> damage arising from its use.
> If you have received this e-mail in error please notify immediately 
> the sender and delete the original email received, any attachments and 
> all copies from your system.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For 
> additional commands, e-mail: users-h...@qpid.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional 
commands, e-mail: users-h...@qpid.apache.org

***

This e-mail contains information for the intended recipient only. It may 
contain proprietary material or confidential information. If you are not the 
intended recipient you are not authorised to distribute, copy or use this 
e-mail or any attachment to it. Murex cannot guarantee that it is virus free 
and accepts no responsibility for any loss or damage arising from its use. If 
you have received this e-mail in error please notify immediately the sender and 
delete the original email received, any attachments and all copies from your 
system.

Re: qpid-broker-j-7.0.0 failover is slow

2018-02-19 Thread bryand 
I was utilizing DLQs (Alternate Binding) for most of my queues and I think
that is why the Virtual Host Node startup time was so slow (1 minute 45
seconds).  After I deleted all those DLQs, the startup time was down to 11
seconds - a huge difference especially when dealing with a failover
situation.

Here are some log messages I was seeing in the Broker-j log file regarding
the DLQs (note that all my DLQs were empty):

2018-02-12 10:42:24,719 WARN  [VirtualHostNode-spgqpiddev3-Config]
(o.a.q.s.m.AbstractConfiguredObject) - Gave up waiting for Queue
'app_attach_workqueue_DLQ' to attain state. Check object's state via
Management.

So I'm wondering if there is some type of issue with broker-j regarding
DLQs/Alternate Bindings




--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org