-
15. Re: Build broken with new AIO tests
timfox May 8, 2008 8:12 AM (in response to timfox)"clebert.suconic@jboss.com" You also need libaio: on the U word OS aptitude install libaio or On Fedora yum libaio [/quote wrote:
Well... you're libaio tests (apart from those known two) pass for me, so I must have libaio installed already.
It's just when I start a server it doesn't recognise this and uses NIO instead. -
16. Re: Build broken with new AIO tests
timfox May 8, 2008 8:14 AM (in response to timfox)"ataylor" wrote:
When running the perf examples i get no difference in performance between nio and asyncio,
Also bear in mind, that when running with just one producer/consumer you probably won't see any difference.
aio comes into its own when there are multiple concurrent producers/consumers. NIO doesn't scale like that. -
17. Re: Build broken with new AIO tests
ataylor May 8, 2008 8:20 AM (in response to timfox)You also need libaio:
on the U word OS
aptitude install libaio
or
On Fedora
yum libaio
I'll add a chapter to the new user doc about this. -
18. Re: Build broken with new AIO tests
ataylor May 8, 2008 8:23 AM (in response to timfox)in fact i'll add a chapter something like "using asynchio for fast reliable performance" (or something, where we can inform the user of the how, why etc etc
-
19. Re: Build broken with new AIO tests
timfox May 8, 2008 8:33 AM (in response to timfox)Ok, I worked out what is happening:
AIO is picked up successfully when running tests on the command line, but is not picked up when running tests in eclipse.
Probably because java.lib path is not set.
Can we avoid this dependency on java lib path? I don't really like the idea of users having to set env properties to get our software to run. It's messy IMHO. -
20. Re: Build broken with new AIO tests
timfox May 8, 2008 8:49 AM (in response to timfox)Andy and I were just discussing on IRC how, the user (for alpha) should be able to download the distro, unzip, and type ant and it should work, no config necessary.
Can we include libaio in the distro? If so, then we can programmatically set the java lib path and no conf is necessary? -
21. Re: Build broken with new AIO tests
clebert.suconic May 8, 2008 9:19 AM (in response to timfox)"timfox" wrote:
Ok, I worked out what is happening:
AIO is picked up successfully when running tests on the command line, but is not picked up when running tests in eclipse.
Probably because java.lib path is not set.
That's what I said few posts ago:"clebert.suconic@jboss.com" wrote:
I have changed the native library load a bit to make sure the conditional test for 32 and 64 bits are working.
To make your life easier during development, you could change the script that starts your IDE to something like this:export LD_LIBRARY_PATH=/extra/work-clebert/workspaces/jboss-messaging-trunk/trunk/native/bin:$LD_LIBRARY_PATH /usr/share/eclipse/eclipse
"timfox" wrote:
Can we avoid this dependency on java lib path? I don't really like the idea of users having to set env properties to get our software to run. It's messy IMHO.
The only way around would be to install the library on /usr/lib, and we should have that when we have the RPM or .DEB package. -
22. Re: Build broken with new AIO tests
clebert.suconic May 8, 2008 9:22 AM (in response to timfox)"timfox" wrote:
Andy and I were just discussing on IRC how, the user (for alpha) should be able to download the distro, unzip, and type ant and it should work, no config necessary.
Can we include libaio in the distro? If so, then we can programmatically set the java lib path and no conf is necessary?
I have tried (without much success) to compile libaio statically. I'm still trying.
But I would be concerned about redistributing libaio in our packages, since it is a OS dependent package. -
23. Re: Build broken with new AIO tests
clebert.suconic May 8, 2008 9:58 AM (in response to timfox)"ataylor" wrote:
When running the perf examples i get no difference in performance between nio and asyncio, in fact when i set journal-sync to false nio is faster. What should i expect?
I just realized this is awesome news actually. At the moment, the code is aways waiting for the callback before going to the next one:
Every call to storeManager.persistMessage
will only return when the callback is returned, or the message is persisted on disk.
If this is performing as fast as noSync already.. this is great.