Re: AIOJ Plan (Was: Re: First release of File Asynchronous File I/O library)
2007-02-03 (토), 13:29 -0500, Alex Karasulu 쓰시길: Uploading the nightly build or snapshot to your home directory at people.apache.org sounds fine for me. I saw people at jakarta project do the same for reviewing purpose. It's OK as long as you state that it's not an official release and retain '-SNAPSHOT' suffix to the distribution. Sombody please correct me if I am saying something wrong. +1 alternatively, there are more official spaces available (on people.apache.org) for snapshots and nightly builds. all that's needed would be a simple vote to approve the snapshot. Please excuse my confusion but do you mean a milestone release or a snapshot because I encountered this on the apache site here: http://www.apache.org/dev/release.html Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. The only people who are supposed to know about such packages are the people following the dev list (or searching its archives) and thus aware of the conditions placed on the package. If you find that the general public are downloading such test packages, then remove them. Just wondering if we should stick to getting a true release for AIOJ rather than taking these intermediate approaches. WDYT? It is stating that we can encourage people on dev list to download non-releases. We could vote on releasing milestones not adding a link in our web site anyway. Releasing AIOJ bundled with MINA 2.0.0-M1 could be reasonable for us. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 signature.asc Description: This is a digitally signed message part
Re: AIOJ Plan (Was: Re: First release of File Asynchronous File I/O library)
On 2/2/07, Trustin Lee [EMAIL PROTECTED] wrote: Hi folks, I won't reply to the other response messsages but this message because I believe everyone understand what Mike's intention was; to show a piece of great software to the community rather than breaking the rule. +1 On 2/1/07, Mike Heath [EMAIL PROTECTED] wrote: Trustin, Thanks for holding me to the Apache process. So, don't think of it as a release then. Perhaps the term 'release' to too formal for what this is. Can we think of it as a conveniently downloadable build for testing purposes? Sure. You could say 'please review this snapshot build.' I know what your intention was, so it's no problem. Everybody makes a mistake. :) +1 snip Until MINA 2.0-M1 is ready for release, is it appropriate to make builds available as progress is made without conducting a formal release? I would like to get feedback earlier rather than later. And make a .jar available for download makes it easier for people to play with the framework. Refactoring JNI code is anything but pleasant so the sooner the API stabilizes the better. Please let me know the proper process for infant projects like this as I've never done anything like this at Apache before and the more I understand about the Apache process, the better off I'll be. Uploading the nightly build or snapshot to your home directory at people.apache.org sounds fine for me. I saw people at jakarta project do the same for reviewing purpose. It's OK as long as you state that it's not an official release and retain '-SNAPSHOT' suffix to the distribution. Sombody please correct me if I am saying something wrong. +1 alternatively, there are more official spaces available (on people.apache.org) for snapshots and nightly builds. all that's needed would be a simple vote to approve the snapshot. - robert
Re: AIOJ Plan (Was: Re: First release of File Asynchronous File I/O library)
robert burrell donkin wrote: On 2/2/07, Trustin Lee [EMAIL PROTECTED] wrote: Hi folks, I won't reply to the other response messsages but this message because I believe everyone understand what Mike's intention was; to show a piece of great software to the community rather than breaking the rule. +1 On 2/1/07, Mike Heath [EMAIL PROTECTED] wrote: Trustin, Thanks for holding me to the Apache process. So, don't think of it as a release then. Perhaps the term 'release' to too formal for what this is. Can we think of it as a conveniently downloadable build for testing purposes? Sure. You could say 'please review this snapshot build.' I know what your intention was, so it's no problem. Everybody makes a mistake. :) +1 snip Until MINA 2.0-M1 is ready for release, is it appropriate to make builds available as progress is made without conducting a formal release? I would like to get feedback earlier rather than later. And make a .jar available for download makes it easier for people to play with the framework. Refactoring JNI code is anything but pleasant so the sooner the API stabilizes the better. Please let me know the proper process for infant projects like this as I've never done anything like this at Apache before and the more I understand about the Apache process, the better off I'll be. Uploading the nightly build or snapshot to your home directory at people.apache.org sounds fine for me. I saw people at jakarta project do the same for reviewing purpose. It's OK as long as you state that it's not an official release and retain '-SNAPSHOT' suffix to the distribution. Sombody please correct me if I am saying something wrong. +1 alternatively, there are more official spaces available (on people.apache.org) for snapshots and nightly builds. all that's needed would be a simple vote to approve the snapshot. Please excuse my confusion but do you mean a milestone release or a snapshot because I encountered this on the apache site here: http://www.apache.org/dev/release.html Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package. The only people who are supposed to know about such packages are the people following the dev list (or searching its archives) and thus aware of the conditions placed on the package. If you find that the general public are downloading such test packages, then remove them. Just wondering if we should stick to getting a true release for AIOJ rather than taking these intermediate approaches. WDYT? Alex
Re: First release of File Asynchronous File I/O library
Colin Fleming wrote: Wow, interesting! That would provide a huge speedup for most apps, I would think. Interesting that for the server VM in 1.5 there's really no difference. BTW I found this following Crazy Bob's blog: http://crazybob.org/2007/01/fast-reflection.html He seemed to get a 40% speedup on Java 5, but doesn't give details about the operation's he's using. There's a comment there also saying that if you turn off the security checks you can get close to direct speed (although Bob says he was doing that - maybe that's why he sees more difference than you). That's interesting! With setAccesible(true) java.lang.reflect is comparable to CGLIB on Java6: java -client: Reflection: 260 ms (2.61) CGLIB FastMethod: 249 ms (2.46) CGLIB InvokeByIndex: 247 ms (2.43) Direct: 72 ms java -server: Reflection: 197 ms (8.38) CGLIB FastMethod: 186 ms (7.86) CGLIB InvokeByIndex: 198 ms (8.43) Direct: 21 ms BTW mina-sm looks excellent, very interesting design. I haven't tried it but I'll play around with it if I get a chance. Let me know if you get the chance. I'd love to get some feedback on it. -- Niklas Therning www.spamdrain.net
AIOJ Plan (Was: Re: First release of File Asynchronous File I/O library)
Hi folks, I won't reply to the other response messsages but this message because I believe everyone understand what Mike's intention was; to show a piece of great software to the community rather than breaking the rule. On 2/1/07, Mike Heath [EMAIL PROTECTED] wrote: Trustin, Thanks for holding me to the Apache process. So, don't think of it as a release then. Perhaps the term 'release' to too formal for what this is. Can we think of it as a conveniently downloadable build for testing purposes? Sure. You could say 'please review this snapshot build.' I know what your intention was, so it's no problem. Everybody makes a mistake. :) This code is certainly not ready for production use yet. My goal was to get a .jar out there so that people can conveniently download the framework and start playing with it and provide some feedback. Yep. Let's focus on reviewing your code. After the review is done, we could move your code to /trunk/aioj or /trunk/another neat name. You are the initial author of the project, so you could name it as you want as long as it is not offensive. :) As far as a formal release of AIOJ, I would love to see it in MINA 2.0-M1. We'll need to figure out the logistics of this because when there's JNI code involved the build/release process gets much more complicated because we have to build and release for each platform. We may want to make POSIX AIO and Linux libaio support (the parts that require JNI) separate releases. Yep. Let's include it in 2.0-M1. I also would like to provide MINA transport for it, rather than just providing AIOJ as a sole subproject. I agree with you for the JNI issues. We could probably provide two providers (the current one and the JNI one) and use Ant or make for the JNI one. WDYT? Until MINA 2.0-M1 is ready for release, is it appropriate to make builds available as progress is made without conducting a formal release? I would like to get feedback earlier rather than later. And make a .jar available for download makes it easier for people to play with the framework. Refactoring JNI code is anything but pleasant so the sooner the API stabilizes the better. Please let me know the proper process for infant projects like this as I've never done anything like this at Apache before and the more I understand about the Apache process, the better off I'll be. Uploading the nightly build or snapshot to your home directory at people.apache.org sounds fine for me. I saw people at jakarta project do the same for reviewing purpose. It's OK as long as you state that it's not an official release and retain '-SNAPSHOT' suffix to the distribution. Sombody please correct me if I am saying something wrong. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: First release of File Asynchronous File I/O library
I guess you are only responsible for a mistake when you know the rules :) As Alex said, this is PMC to check that those rules are not broken... Regarding 'snapshot', the best thing would be to use a continue build system (continuum ?) so that the build is done every night, and store somwhere on an apache repository. Note that we have to do that for Directory project, too, so maybe we can work on it together to avoid duplication of efforts... Emmanuel On 2/1/07, Mike Heath [EMAIL PROTECTED] wrote: On Wed, 2007-01-31 at 23:20 -0500, Alex Karasulu wrote: Youch! Is Trustin the only one that saw a problem with this? Where is the PMC? This is a big red flag. Mike, I'm not trying to bust your keyboard but you really need to read this: http://www.apache.org/dev/release.html You probably just confused a nightly build or SNAPSHOT build with an ASF (PMC) sanctioned release but please do *not* announce these things here without going through the PMC. Thank you for pointing me in the right direction Alex and you're correct this is a SNAPSHOT, not any kind of release intended for the public at large. In the future, is it appropriate for me to post snapshots to my home directory and announce their availability or is there a different process I should follow? Sorry for the red flags. -Mike -- Cordialement, Emmanuel Lécharny www.iktek.com
Re: First release of File Asynchronous File I/O library
On 31/01/07, Niklas Therning [EMAIL PROTECTED] wrote: Well, reflection is of course a lot slower than direct method invocations. snip Anyhow I would still want to optimize these parts of mina-sm using byte code generation and, if possible, eliminate the need for reflection entirely. This might be interesting to you, if you haven't seen it: http://www.sixlegs.com/blog/java/cglib-fastclass.html Cheers, Colin
Re: First release of File Asynchronous File I/O library
Colin Fleming wrote: On 31/01/07, Niklas Therning [EMAIL PROTECTED] wrote: Well, reflection is of course a lot slower than direct method invocations. snip Anyhow I would still want to optimize these parts of mina-sm using byte code generation and, if possible, eliminate the need for reflection entirely. This might be interesting to you, if you haven't seen it: http://www.sixlegs.com/blog/java/cglib-fastclass.html That looks really cool! I just replicated this test with Sun's Java6 (build 1.6.0-b105 under Ubuntu) and it seems like java.lang.reflect is catching up but CGLIB (2.1_3) still seems faster: Using java -client: Reflection: 324 ms (3.70) CGLIB FastMethod: 238 ms (2.45) CGLIB InvokeByIndex: 236 ms (2.42) Direct: 69 ms Using java -server: Reflection: 237 ms (10.29) CGLIB FastMethod: 193 ms (8.19) CGLIB InvokeByIndex: 181 ms (7.62) Direct: 21 ms One thing I noticed is that when I lookup the method in every iteration both CGLIB and reflection performs terribly bad which suggests that if possible one should always try to hold on to the Method, FastMethod or index if possible and only look it up the first time it's used. Here are the same figures using Sun's Java5 (build 1.5.0_08-b03 under Ubuntu): Using java -client: Reflection: 493 ms (5.40) CGLIB FastMethod: 269 ms (2.49) CGLIB InvokeByIndex: 269 ms (2.49) Direct: 77 ms Using java -server: Reflection: 230 ms (2.07) CGLIB FastMethod: 225 ms (2.0) CGLIB InvokeByIndex: 227 ms (2.0) Direct: 75 ms Wow! Seems like Sun managed to speed up direct method invocations a lot for the Server VM in Java 1.6. -- Niklas Therning www.spamdrain.net
Re: First release of File Asynchronous File I/O library
Wow, interesting! That would provide a huge speedup for most apps, I would think. Interesting that for the server VM in 1.5 there's really no difference. BTW I found this following Crazy Bob's blog: http://crazybob.org/2007/01/fast-reflection.html He seemed to get a 40% speedup on Java 5, but doesn't give details about the operation's he's using. There's a comment there also saying that if you turn off the security checks you can get close to direct speed (although Bob says he was doing that - maybe that's why he sees more difference than you). BTW mina-sm looks excellent, very interesting design. I haven't tried it but I'll play around with it if I get a chance. Cheers, Colin
Re: First release of File Asynchronous File I/O library
there is a certain tradition of solo efforts being developed offshore and posted to people.apache.org then announced to apache lists. people have to be careful with the naming and IMHO mike sailed just the right side of the wind. but now we have the http://labs.apache.org/ and that's the right place for efforts such as this. in the labs releases are not ok but tagged milestones are. mike - any objections to moving Asynchronous File I/O library to the labs? (you'll probably need to submit a software grant for the code you've already created) At this point, I can't say that I care where AIO has its home. I just want something that's stable and something that will foster community involvement. Apache Labs might be a good home for AIO. If there aren't any objections to moving this project out of my MINA sandbox and into Apache Labs, I'll do that. If we want to keep it as a sub-project of MINA, I would like to formalize that. -Mike
Re: First release of File Asynchronous File I/O library
On 2/1/07, Mike Heath [EMAIL PROTECTED] wrote: there is a certain tradition of solo efforts being developed offshore and posted to people.apache.org then announced to apache lists. people have to be careful with the naming and IMHO mike sailed just the right side of the wind. but now we have the http://labs.apache.org/ and that's the right place for efforts such as this. in the labs releases are not ok but tagged milestones are. mike - any objections to moving Asynchronous File I/O library to the labs? (you'll probably need to submit a software grant for the code you've already created) At this point, I can't say that I care where AIO has its home. I just want something that's stable and something that will foster community involvement. Apache Labs might be a good home for AIO. If there aren't any objections to moving this project out of my MINA sandbox and into Apache Labs, I'll do that. If we want to keep it as a sub-project of MINA, I would like to formalize that. sorry - my bad: i didn't realize that it was already in the MINA sandbox (i'd assumed you had it locally) in this case, alex is definitely 100% right: it's MINA code and releases require approval from the PMC. - robert
Re: First release of File Asynchronous File I/O library
Trustin, Thanks for holding me to the Apache process. So, don't think of it as a release then. Perhaps the term 'release' to too formal for what this is. Can we think of it as a conveniently downloadable build for testing purposes? This code is certainly not ready for production use yet. My goal was to get a .jar out there so that people can conveniently download the framework and start playing with it and provide some feedback. As far as a formal release of AIOJ, I would love to see it in MINA 2.0-M1. We'll need to figure out the logistics of this because when there's JNI code involved the build/release process gets much more complicated because we have to build and release for each platform. We may want to make POSIX AIO and Linux libaio support (the parts that require JNI) separate releases. Until MINA 2.0-M1 is ready for release, is it appropriate to make builds available as progress is made without conducting a formal release? I would like to get feedback earlier rather than later. And make a .jar available for download makes it easier for people to play with the framework. Refactoring JNI code is anything but pleasant so the sooner the API stabilizes the better. Please let me know the proper process for infant projects like this as I've never done anything like this at Apache before and the more I understand about the Apache process, the better off I'll be. -Mike On 1/31/07, Trustin Lee [EMAIL PROTECTED] wrote: Hi Mike, On 1/31/07, Mike Heath [EMAIL PROTECTED] wrote: I made the first release of my Asynchronous File I/O library. The site for the library can be found here: http://people.apache.org/~mheath/aio/ The .jar can be downloaded here: http://people.apache.org/~mheath/aio/aio-0.1.jar This release uses a java.util.concurrent.ExecutorService to call java.nio.channels.FileChannel methods in a separate thread. The next release will provide support for POSIX AIO. Soon after that, a release that uses the Linux io_submit(2) system call will be made available. Support for Solaris is also in the pipeline. More information and ideas about the framework will be posted on my blog, http://swamp.homelinux.net/blog/ As always, feedback is appreciated. Well, I know you didn't tag anything or upload tarball to the apache distribution directories. But you can't *release* anything without a vote. So you can't say it's a 'first release' at all. Of course, this doesn't mean that I don't want AIO to be under MINA project. It is closely related with MINA, and that's why we need to discuss about where to place the AIO package under MINA project. We had only one project in MINA so far, but now it's not. As you know, we have at least three projects in our sandbox; aioj, mina-sm, and serial. What I can think of for now is to include each sandbox projects to our overall release road map for MINA as the sandbox project gets mature. For example, we could release MINA 2.0-M1 with AIOJ, rather than releasing AIOJ separately. WDYT? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: First release of File Asynchronous File I/O library
Cameron Taggart wrote: project in MINA so far, but now it's not. As you know, we have at least three projects in our sandbox; aioj, mina-sm, and serial. What are the mina-sm serial projects in the sandbox for? mina-sm is a package for defining state machines. Have a look at this JIRA issue: http://issues.apache.org/jira/browse/DIRMINA-160 The design have been changed since my last comments in JIRA. The current design uses annotations on methods to build the SM. You use the @State annotation to define the available states and then you annotate the methods which will be wrapped in MethodTransition objects using the @Handler annotation. Then you use StateMachineFactory and specifiy the classes which you want it to build a StateMachine from. It will read all the annotations and build the directed graph of State and Transition objects. Finally you use StateMachineProxyFactory to create the dynamic proxy for the interfaces of your choice (e.g. IoHandler in MINA). The proxy will translate all method calls on the dynamic proxy into Event objects which are passed on to your state machine methods. Normally the next state is statically defined in the @Handler annotation. However, you can also change the flow programatically through the StateControl class. Using it you can specify a different next state and whether it should handle the next event or the current event. There's also a subroutine like feature. This can be used if you have a sub graph in your state machine which will be called from several places and it should return to different states depending on the state it was called from. One of my favorite features with mina-sm is the method arguments matching described in the comments of the JIRA issue. It could be quite slow since it uses reflection and the matching is executed for every event. But this could probably be optimized significantly using byte code generation. That would be a lot of fun to implement! :-) So far mina-sm seems to work very well for the very complex state machines we have in our app. It hasn't been put in production yet but it will in a few weeks. If you want to check it out you will have to checkout the code from subversion and build yourself for now. -- Niklas Therning www.spamdrain.net
Re: First release of File Asynchronous File I/O library
Niklas Therning wrote: One of my favorite features with mina-sm is the method arguments matching described in the comments of the JIRA issue. It could be quite slow since it uses reflection and the matching is executed for every event. But this could probably be optimized significantly using byte code generation. That would be a lot of fun to implement! :-) reflection is horribly slow. For a desktop app it's ok but not for a server IMO. _ Log på MSN Messenger direkte på nettet: http://webmessenger.msn.com
Re: First release of File Asynchronous File I/O library
James Im wrote: Niklas Therning wrote: One of my favorite features with mina-sm is the method arguments matching described in the comments of the JIRA issue. It could be quite slow since it uses reflection and the matching is executed for every event. But this could probably be optimized significantly using byte code generation. That would be a lot of fun to implement! :-) reflection is horribly slow. For a desktop app it's ok but not for a server IMO. Well, reflection is of course a lot slower than direct method invocations. But whether it's acceptable or not always depends on the application in question. For some applications the performance hit from using reflection could be negligible. Anyhow I would still want to optimize these parts of mina-sm using byte code generation and, if possible, eliminate the need for reflection entirely. -- Niklas Therning www.spamdrain.net
Re: First release of File Asynchronous File I/O library
Mike Heath wrote: I made the first release of my Asynchronous File I/O library. The site for the library can be found here: http://people.apache.org/~mheath/aio/ The .jar can be downloaded here: http://people.apache.org/~mheath/aio/aio-0.1.jar This release uses a java.util.concurrent.ExecutorService to call java.nio.channels.FileChannel methods in a separate thread. The next release will provide support for POSIX AIO. Soon after that, a release that uses the Linux io_submit(2) system call will be made available. Support for Solaris is also in the pipeline. More information and ideas about the framework will be posted on my blog, http://swamp.homelinux.net/blog/ As always, feedback is appreciated. Youch! Is Trustin the only one that saw a problem with this? Where is the PMC? This is a big red flag. Mike, I'm not trying to bust your keyboard but you really need to read this: http://www.apache.org/dev/release.html You probably just confused a nightly build or SNAPSHOT build with an ASF (PMC) sanctioned release but please do *not* announce these things here without going through the PMC. Alex
