11 Replies Latest reply on May 24, 2012 1:14 PM by clebert.suconic

    Porting to FreeBSD

    hsn10

      What is best method for modifying source code for FreeBSD AIO port and easy merge back to project?

       

      place #ifdef __FreeBSD__ into code?

        • 1. Re: Porting to FreeBSD
          ataylor

          HornetQ is pure java so if you have a JDK then you dont need to port anything.

          • 2. Re: Porting to FreeBSD
            hsn10

            Check source tree, look into native-src subdirectory. But yes it works on FreeBSD even without that AIO library fallback to NIO

            • 3. Re: Porting to FreeBSD
              clebert.suconic

              Someone would probably have to write a posix AIO version of our implementation.

               

               

              Our native IO version however is already doing async writes batched by the TimedBuffers. libaio is done at the kernel level, while Posix AIO is a level above the kernel I think. So I"m not sure PosixAIO will give you any benefits in top of our asynchronous implementation in Java.

              • 4. Re: Porting to FreeBSD
                hsn10

                Yes. FreeBSD supports POSIX AIO.

                 

                libaio is linux specific. POSIX AIO will give portability, performance should be about same because posix aio is user mode wrapper above libaio.

                 

                What is decision of development team how to handle portability? Port entire source to POSIX?

                • 5. Re: Porting to FreeBSD
                  ataylor

                  we dont have any plans to support FreeBSD, however feel free to port the code and we will feed it back into the commmunity.

                  • 6. Re: Porting to FreeBSD
                    hsn10

                    Shiping 2 directories native-src (your code) and native-posix will work for you?

                     

                    Posix portability will allow code to run at other OS too. You have no plans to support any other unix then Linux?

                    • 7. Re: Porting to FreeBSD
                      clebert.suconic

                      Radim,

                       

                      If that's something at users thread level and not kernel I suspect posix AIO will hardly give you any benefit in top if the pure java implementation in place which is already simulating asynchronous writes.

                       

                      To give you an idea libaio still alive just because the direct memory and direct writes made a difference, but if Posix AIO is just a good wrapper I don't see a point in oerformance to justify the investment.

                      • 8. Re: Porting to FreeBSD
                        hsn10

                        POSIX AIO for Linux is just wrapper at top of libaio. Performance on Linux should be about same as using libaio directly.

                         

                        Because POSIX AIO is supported by other operation systems which do not supports libaio - FreeBSD, Solaris and AIX, using posix aio will give portability. Other operation systems such as solaris has their native AIO support too, but they also support posix standard.

                        • 9. Re: Porting to FreeBSD
                          clebert.suconic

                          I undestand that. I"m just saying I am not sure it would bring benefit since it's a thread's implementation with asynchronous writes similar to what we do on the TimedBuffer.

                           

                          POSIX AIO on Linux could introduce performance issues since it would be an extra level ot call to the calls.

                          • 10. Re: Porting to FreeBSD
                            hsn10

                            Performance efect on Linux should not be measurable because posix aio wrapper is just one more function call.

                            • 11. Re: Porting to FreeBSD
                              clebert.suconic

                              if you want to contribute the code changes I'm all support for it. It shouldn't be a lot of changes in terms of coding. I would though still prefer to keep the current libaio available in parallel, at least until we are completely sure it has no performance impact.  I have spent quite some good ammount of time on it.. and replacing the whole library will require performance tests and QA tests.