JMS Appender

Pragnesh
2009-07-06
2013-05-09
  • Pragnesh

    Pragnesh - 2009-07-06

    Hi Jason,

    Have you considered writing jms persister? Have you done any performance bechmarks on writing in a file vs Database vs JMS Queue.

    I am of the opinion that JMS would be ideal here may actually give a better performance then a simple File write or a batchDB.

    Please provide your inputs.

    - Pragnesh

     
    • Jason Trump

      Jason Trump - 2009-07-06

      I haven't considered it, but I think it's an excellent idea.  Patches welcome :)

      All persistence is done in a background, low priority thread.  So changing persister implementations doesn't have much impact on application responsiveness, though it does have an impact on local system resource utilization.

      In general testing I found the file persister to be quicker than the JDBC persister, though the total overhead depends a lot on how your system is configured.  For example, if you put your logging on a different storage device than application data, resource impact is negligible, and most likely this will be the highest performance option.  But, if you do a lot of logging to your system's primary storage device, you will get more application interference.

      But back to your main point -- i think a JMS persister will be a great value to the system overall.

       
      • Pragnesh

        Pragnesh - 2009-07-09

        What is the best way that you would recommend to configure the beet's buffering mechanism so that it writes the BTEvent on JMS Queue as soon as it gets it.

         
        • Jason Trump

          Jason Trump - 2009-07-09

          Configuring a SyncTaskExecutor will get you about halfway there:

            <bean id="syncExecutor" class="org.springframework.core.task.SyncTaskExecutor"/>
            <bt:manager task-executor="syncExecutor" ... />

          setting the flush-threshold to '1' will effectively cause instantaneous writes, with the negative side-effect that every event will also record a 'flush' event, which is probably not what you want.  you could configure your persister to ignore these i suppose.

          are you sure you want to disable the buffering completely?  if your JMS queue puts are transactional, there's opportunity to interfere with the calling application, esp. if there's a JTA transaction already in progress.

          if you just want to see your events persisted faster, you could shorten the flush schedule.  default is five minutes; e.g. shorten to 15 seconds:

          <bt:manager flush-schedule="0/15 * * * * ?" ... />

           

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks