Configuring an IOExceptionHandler

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Configuring an IOExceptionHandler

Martin Lichtin
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
Reply | Threaded
Open this post in threaded view
|

Re: Configuring an IOExceptionHandler

Tim Bain
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" <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Configuring an IOExceptionHandler

Martin Lichtin
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" <[hidden email]> 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
>