You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Martin Lichtin <li...@yahoo.com.INVALID> on 2015/11/27 11:06:54 UTC

Re: Configuring an IOExceptionHandler

That's true, one has to avoid these exceptions. Setting limits is fine, and also allocating a separate partition for it.
The remaining issue is "allow nothing else to write to it" (experience tells me Murphy will hit there).
I now configured a broker plugin that frequently checks free disk space and stops broker connections when a given threshold is reached, starts them again when enough free space is available.

On 14.10.2015 14:38, Tim Bain wrote:
>
> I'd say the tried and true approach to handling out-of-space exceptions is to prevent them from happening in the first place: set the storeLimit and tempLimit to appropriately large values, enable PFC to ensure you don't exceed them, and host them in a storage location that you can guarantee will always have enough space for both of them together.  (For example, allocate a partition only for them that is 10% larger than the sum of the two limits, and allow nothing else to write to it.)  Prevention is usually better than treatment.
>
> On Oct 14, 2015 4:36 AM, "Martin Lichtin" <li...@yahoo.com.invalid> wrote:
>
>     Wanted to ask if it is advisable to configure an IOExceptionHandler, such as
>
>          <bean id="ioExceptionHandler" class="org.apache.activemq.util.DefaultIOExceptionHandler">
>                  <property name="ignoreNoSpaceErrors"><value>false</value></property>
>                  <property name="stopStartConnectors"><value>true</value></property>
>
>          </bean>
>
>     I could not find much information about this feature, besides
>     http://activemq.apache.org/configurable-ioexception-handling.html
>
>     Is this a tried and trusted approach to handle e.g. an out-of-disk-space scenario?
>
>     We've recently had a full disk and experienced lost messages, which is something we obviously try to avoid happening in the future.
>
>     - Martin
>