Class PoolingMessageSplitterService

All Implemented Interfaces:
AdaptrisComponent, ComponentLifecycle, ComponentLifecycleExtension, EventHandlerAware, MessageEventGenerator, Service, ServiceWrapper, StateManagedComponent

@ComponentProfile(summary="Split a message and execute an arbitary number of services on the split message", tag="service,splitter", since="3.7.1") public class PoolingMessageSplitterService extends AdvancedMessageSplitterService
Extension to AdvancedMessageSplitterService that uses a underlying thread and object pool to execute the service on each split message.

Note that using this splitter may mean that messages become un-ordered; if the order of the split messages is critical, then you probably shouldn't use this service. Additionally, individual split-message failures will only be reported on after all the split messages have been processed, so unlike AdvancedMessageSplitterService; MessageSplitterServiceImp.setIgnoreSplitMessageFailures(Boolean) will not halt the processing of the subsequent split messages

In the adapter configuration file this class is aliased as pooling-message-splitter-service which is the preferred alternative to the fully qualified classname when building your configuration.

  • Constructor Details

    • PoolingMessageSplitterService

      public PoolingMessageSplitterService()
  • Method Details

    • handleSplitMessage

      protected void handleSplitMessage(AdaptrisMessage msg, Consumer<Exception> callback) throws ServiceException
      Overrides:
      handleSplitMessage in class AdvancedMessageSplitterService
      Throws:
      ServiceException
    • initService

      protected void initService() throws CoreException
      Overrides:
      initService in class AdvancedMessageSplitterService
      Throws:
      CoreException
    • start

      public void start() throws CoreException
      Description copied from interface: ComponentLifecycle
      Starts the component.

      Once a component is started it should be ready to process messages. In the case of AdaptrisMessageConsumer, calling start will begin message delivery.

      Specified by:
      start in interface ComponentLifecycle
      Overrides:
      start in class AdvancedMessageSplitterService
      Throws:
      CoreException - wrapping any underlying Exceptions
      See Also:
    • closeService

      protected void closeService()
      Overrides:
      closeService in class AdvancedMessageSplitterService
    • withWarmStart

      public PoolingMessageSplitterService withWarmStart(Boolean b)
    • withMaxThreads

      public PoolingMessageSplitterService withMaxThreads(Integer i)
    • withWaitWhileBusy

      public PoolingMessageSplitterService withWaitWhileBusy(Boolean b)
    • waitQuietly

      protected void waitQuietly(Object monitor)
    • getMaxThreads

      public Integer getMaxThreads()
      Set the max number of threads to operate on split messages

      The default is 10 if not explicitly specified

    • setMaxThreads

      public void setMaxThreads(Integer maxThreads)
      Set the max number of threads to operate on split messages

      The default is 10 if not explicitly specified

    • getWarmStart

      public Boolean getWarmStart()
      Specify if the underlying object pool should be warmed up on start().

      The default is false if not specified

    • setWarmStart

      public void setWarmStart(Boolean warmStart)
      Specify if the underlying object pool should be warmed up on start().

      The default is false if not specified

    • getWaitWhileBusy

      public Boolean getWaitWhileBusy()
      Actively check if the underlying object pool is ready to accept more workers.

      If set to true, then we check that the underlying object pool has enough space for us to submit more jobs. This means that if you have a large number of split messages, then we don't attempt to flood the queue with thousands of messages causing possible issues within constrained environments. It defaults to false if not explicitly specified, and if set to true will have a small negative impact on performance.

    • setWaitWhileBusy

      public void setWaitWhileBusy(Boolean waitWhileBusy)
      Actively check if the underlying object pool is ready to accept more workers.

      If set to true, then we check that the underlying object pool has enough space for us to submit more jobs. This means that if you have a large number of split messages, then we don't attempt to flood the queue with thousands of messages causing possible issues within constrained environments. It defaults to false if not explicitly specified, and if set to true will have a small negative impact on performance.