jcyclone-devs Mailing List for JCyclone
Brought to you by:
jm7
You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Toli K. <to...@ma...> - 2007-03-13 00:45:28
|
Dima, Thanks for filing the bug and submitting a patch. It's in a part of code i've never looked at - we've only used the Jcyclone core, w/out any of the ext stuff. I'll take a look at the patch, write some unit tests, and submit it. Not sure about your second question - the project is fairly old, so I am not sure why certain things were written the way they have been toli On 3/9/07, Dmitry Motylev <d.m...@gm...> wrote: > Hello, > > I just started to play with jcyclone. I'm working on project where very rich > JS client framework uses http servlets mostly for fetching data from db. And > I'm wonder about SEDA as possible change for our current implementation > based on servlet as those servlets seems uses HW resources not as efficient > as it could be. And jcyclone looks very promisingly here. > > I found some minor bug in HttpRequest (submitted bug #1677172) and try to > understand is there any reason to use Hashtable and Vector instead of Map > and List correspondingly? I guess it is not necessary to have these > collection always synchronized so switching to "lightweight" collections > would add a bit of performance :) > > -- > Yours sincerely Dmitri Motylev. > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Jcyclone-devs mailing list > Jcy...@li... > https://lists.sourceforge.net/lists/listinfo/jcyclone-devs > > -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
From: Dmitry M. <d.m...@gm...> - 2007-03-09 12:24:13
|
Hello, I just started to play with jcyclone. I'm working on project where very rich JS client framework uses http servlets mostly for fetching data from db. And I'm wonder about SEDA as possible change for our current implementation based on servlet as those servlets seems uses HW resources not as efficient as it could be. And jcyclone looks very promisingly here. I found some minor bug in HttpRequest (submitted bug #1677172) and try to understand is there any reason to use Hashtable and Vector instead of Map and List correspondingly? I guess it is not necessary to have these collection always synchronized so switching to "lightweight" collections would add a bit of performance :) -- Yours sincerely Dmitri Motylev. |
From: Toli K. <to...@ma...> - 2006-09-27 02:05:27
|
hey everyone, With Jean's permission, i have just checked in some changes to the JCyclone project. Her's a short list of updates: 1. Addition of TPSSchedulerConcurrent, based on the java.uitl.concurrency code note: we create a new EventRunnable for each incoming batch of events, so this is something to keep an eye out in terms of potential performance hits for the future 2. added a series of unit tests for all scheduling logic - invoke them with ant -f build-junit.xml junit 3. unit tests are written using generics, which means it's an open-season on updating JCyclone to use Java 1.5 the new TPSSchedulerConcurrent is invoked by setting global.defaultThreadManager = TPSTM-Concurrent in the jcyclone config file. You can see the example of it in http://trac.marketcetera.org/trac.fcgi/browser/platform/trunk/core/src/main/java/org/marketcetera/core/ApplicationBase.java#L120 I've discussed the road map for the future of JCyclone, and Jean is going to write it up soon and put it up on the SourceForge page, where others can comment and perhaps sign up for things that they'd like to see implemented. happy using! and thanks to Jean for doing the code review -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
From: Toli K. <to...@ma...> - 2006-09-11 19:41:27
|
Jean (and others), We've taken a look at the changes you proposed for making the ThreadPool more efficient, and it seems that it may be easier to just re-implement it using the native Java concurrency stuff. If having JCyclone depend on Java 1.5 is acceptable, then it's a lot easier to implement the concrrent thread pool using the built-in concurrentcy functionality. We've put together a set of changes that creates a new TPSConcurrentScheduler.java class that uses the built-in concurrency, along with a set of unit tests that runs using both the old TPSScheduler and the new concurrent scheduler. The changeset consists of 3 files: patch.diff - apply using the usual patch -p0 < patch.out command from jcyclone/core directory, this modifies the existing files. MapConfig.diff - the last time i checked in code i had the MapConfig.java file be in DOS mode (with \r\r line endings). I couldn't figure out a clean way to have patch work with 2 kinds of line endings so this patch file is separate). so apply this with patch -p0 < MapConfig.diff to see the changes. newfiles.tar - to be expanded in jcyclone/core directory. this contains the new src and test files. Here's the general list of changes: MapConfig.java - i actually had a bug in this class that i found with a unit test. it's been fixed. test/org/jcyclone/core/cfg/FileConfigTest.java test/org/jcyclone/core/cfg/JCycloneConfigTest.java test/org/jcyclone/core/cfg/MapConfigTest.java - added unit tests for File/MapConfig TPSSchedulerConcurrent - implementation of a concurrent thread pool scheduler using the java cocurrency code build-junit.xml and build-junit-shared.xml - refactored the junit build code to live in a shared file. this is more of a personal preference/nicety - we can't use the regular build.xml file b/c it's referring to the share.xml file that doesn't exist in the same directory, so we factored out the junit code to be coming in from a shared file we can include in a different build-xxx.xml file src/org/jcyclone/core/boot/JCyclone.java In order to make it easier to write unit tests, i modified JCyclone to allow for starting/stopping it multiple times. It is still essentially a signleton, but i've added code to allow for it to be reset and restarted again. src/org/jcyclone/core/cfg/JCycloneConfig.java - added the constant for the new scheduler src/org/jcyclone/core/internal/TPSScheduler.java - found a bug - the code actually doesn't remove anything during deregisterAll(). Didn't actually fix the bug - it breaks the subsequent implementation of deregister(). Basically, currently JCyclone calls deregisterAll() and the subsequently deregister() on each stage. So each stage was being deregistered twice. We didn't fix the workflow, but modified our TPSSchedulerConcurrent to handle double calls to deregister correctly. src/org/jcyclone/core/internal/AggThrottleBatchSorter.java src/org/jcyclone/core/internal/NullBatchSorter.java It turns out that the NullBatchSorter was resuing the same array of batched events it passed on to a stage to store new incoming events in it. Due to the new threading behaviour we would come up on a ConcurrentModificatonException when a stage was processing events and new events were being added to the list. We fixed that by having the BatchSorters always return a new list every time and not reuse the existing ThreadLocal one. src/org/jcyclone/core/stage/JCycloneMgr.java code to recognize the new scheduler test/org/jcyclone/core/internal/Consumer.java test/org/jcyclone/core/internal/ConsumerSingleThreaded.java test/org/jcyclone/core/internal/Producer.java test/org/jcyclone/core/internal/ProducerSingleThreaded.java test/org/jcyclone/core/internal/SchedulerTestBase.java test/org/jcyclone/core/internal/TPSConcurrentScheduler_MixedThreadingTest.java test/org/jcyclone/core/internal/TPSConcurrent_SingleThreadedTest.java test/org/jcyclone/core/internal/TPSSchedulerConcurrentTest.java test/org/jcyclone/core/internal/TPSSchedulerTest.java test/org/jcyclone/core/internal/TPSScheduler_SIngleThreadedTest.java test/org/jcyclone/core/internal/ThreadSampleEvent.java - code for creating the simple producer/consumer framework for unit testing the TPS schedulers. Producers send events, and consumers are stages that recieve them, and then add them back to the test. we then verify that all events go through, that they are in right order (if appropriate), etc. there are multiple setup combinations: one-one (producer-consumer), many-one, many-many, etc; both with original TPSScheduler and TPSSchedulerConcurrent. Tests are written to be somewhat random - stages may wait a random amount to send an event, and will send a random # of events as well. I wrote it that way to introduce more randomness in order to force concurrency/scheduling issues to surface faster. in addition to using the java concurrency code (1.4) the unit tests also use generics from 1.5. the unit tests now take about 8-9 minutes to complete (run them with ant -f build-junit clean junit). let me know what you think. --- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
From: Toli K. <to...@ma...> - 2006-09-08 21:11:06
|
hey everyone, I uncovered a bug in the way we wrote our TPSSchedulerConcurrent that i submitted in a prior email. When using the new java5 for-each iterator, we were getting ConcurrentModificationExceptions in our stage code when processing events. It turns out that the NullBatchSorter was resuing the same array of batched events it passed on to a stage to store new incoming events in it. Due to the new threading behaviour we would come up on a ConcurrentModificatonException when a stage was processing events and new events were being added to the list. We fixed that by having the BatchSorters always return a new list every time and not reuse the existing ThreadLocal one. has anybody experienced similar issues? any thoughts? Regardless, i added new unit tests that fail with the old NullBatchSorter behaviour, and pass with the modifications (as does our app). pathset attached. -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
From: Toli K. <to...@ma...> - 2006-09-06 01:33:53
|
Jean (and others), We've taken a look at the changes you proposed for making the ThreadPool more efficient, and it seems that it may be easier to just re-implement it using the native Java concurrency stuff. If having JCyclone depend on Java 1.5 is acceptable, then it's a lot easier to implement the concrrent thread pool using the built-in concurrentcy functionality. We've put together a set of changes that creates a new TPSConcurrentScheduler.java class that uses the built-in concurrency, along with a set of unit tests that runs using both the old TPSScheduler and the new concurrent scheduler. The changeset consists of 3 files: patch.out - apply using the usual patch -p0 < patch.out command from jcyclone/core directory, this modifies the existing files. patch-MapConfig.out - the last time i checked in code i had the MapConfig.java file be in DOS mode (with \r\r line endings). I couldn't figure out a clean way to have patch work with 2 kinds of line endings so this patch file is separate) patch-newFiles.zip - to be expanded in jcyclone/core directory. this contains the new src and test files. Here's the general list of changes: MapConfig.java - i actually had a bug in this class that i found with a unit test. it's been fixed. test/org/jcyclone/core/cfg/FileConfigTest.java test/org/jcyclone/core/cfg/JCycloneConfigTest.java test/org/jcyclone/core/cfg/MapConfigTest.java - added unit tests for File/MapConfig TPSSchedulerConcurrent - implementation of a concurrent thread pool scheduler using the java cocurrency code build-junit.xml and build-junit-shared.xml - refactored the junit build code to live in a shared file. this is more of a personal preference/nicety - we can't use the regular build.xml file b/c it's referring to the share.xml file that doesn't exist in the same directory, so we factored out the junit code to be coming in from a shared file we can include in a different build-xxx.xml file src/org/jcyclone/core/boot/JCyclone.java In order to make it easier to write unit tests, i modified JCyclone to allow for starting/stopping it multiple times. It is still essentially a signleton, but i've added code to allow for it to be reset and restarted again. src/org/jcyclone/core/cfg/JCycloneConfig.java - added the constant for the new scheduler src/org/jcyclone/core/internal/TPSScheduler.java - found a bug - the code actually doesn't remove anything during deregisterAll(). Didn't actually fix the bug - it breaks the subsequent implementation of deregister(). Basically, currently JCyclone calls deregisterAll() and the subsequently deregister() on each stage. So each stage was being deregistered twice. We didn't fix the workflow, but modified our TPSSchedulerConcurrent to handle double calls to deregister correctly. src/org/jcyclone/core/stage/JCycloneMgr.java code to recognize the new scheduler test/org/jcyclone/core/internal/Consumer.java test/org/jcyclone/core/internal/ConsumerSingleThreaded.java test/org/jcyclone/core/internal/Producer.java test/org/jcyclone/core/internal/ProducerSingleThreaded.java test/org/jcyclone/core/internal/SchedulerTestBase.java test/org/jcyclone/core/internal/TPSConcurrentScheduler_MixedThreadingTest.java test/org/jcyclone/core/internal/TPSConcurrent_SingleThreadedTest.java test/org/jcyclone/core/internal/TPSSchedulerConcurrentTest.java test/org/jcyclone/core/internal/TPSSchedulerTest.java test/org/jcyclone/core/internal/TPSScheduler_SIngleThreadedTest.java test/org/jcyclone/core/internal/ThreadSampleEvent.java - code for creating the simple producer/consumer framework for unit testing the TPS schedulers. Producers send events, and consumers are stages that recieve them, and then add them back to the test. we then verify that all events go through, that they are in right order (if appropriate), etc. there are multiple setup combinations: one-one (producer-consumer), many-one, many-many, etc; both with original TPSScheduler and TPSSchedulerConcurrent. Tests are written to be somewhat random - stages may wait a random amount to send an event, and will send a random # of events as well. I wrote it that way to introduce more randomness in order to force concurrency/scheduling issues to surface faster. in addition to using the java concurrency code (1.4) the unit tests also use generics from 1.5. the unit tests now take about 8-9 minutes to complete (run them with ant -f build-junit clean junit). let me know what you think. -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
From: Jean M. <jea...@gm...> - 2006-07-03 17:54:25
|
> i think then maybe we should have a notion of a "source" anyway? > I would rather have separations of "sources" and "sinks" - that way we > can rely on having the sinks be loaded first, for example, and then > have the "sources" be loaded second; plus we have a clear semantic > separation of functionality too. I totally agree. I would like to implement that in the next major version of JCyclone. I will try to commit some code in the sandbox directory to experiment and share ideas. > So maybe we could leave IPlugins as they are for now, and then make a > decision on whether we want to introduce "sources" as first-order > objects separate from plugins, and move plugins into the SPI dir as > you suggest. I agree, however we will need to update classes that implement IPlugin : AFileMgr and ASocketMgr. Be free to commit your changes. Thanks, Jean |
From: Toli K. <to...@ma...> - 2006-07-03 14:58:44
|
SmVhbiwKClRoaXMgaXMgYSBnb29kIHBvaW50IC0gaSBjYW4gZml4IHRoZSBNYXBDb25maWcgY29k ZSB0byB1c2UgYW4KZW50cnlTZXQoKSB0byBzcGVlZCB0aGluZ3MgdXAgYSBiaXQuCgpBcyBmYXIg YXMgSVBsdWdpbnMgLSBmb3IgdXMgaXQgZGlkbid0IG1ha2Ugc2Vuc2UgdG8gaGF2ZSBvdXIgInNv dXJjZXMiCmFzIGZ1bGwtb24gc3RhZ2VzLCBzaW5jZSB0aGV5IG9ubHkgZnVsZmlsbGVkIG9uZSBo YWxmIG9mIHRoZSBjb250cmFjdAoob25seSBzZW5kaW5nIHN0dWZmKS4KaSB0aGluayB0aGVuIG1h eWJlIHdlIHNob3VsZCBoYXZlIGEgbm90aW9uIG9mIGEgInNvdXJjZSIgYW55d2F5PwpJIHdvdWxk IHJhdGhlciBoYXZlIHNlcGFyYXRpb25zIG9mICJzb3VyY2VzIiBhbmQgInNpbmtzIiAtIHRoYXQg d2F5IHdlCmNhbiByZWx5IG9uIGhhdmluZyB0aGUgc2lua3MgYmUgbG9hZGVkIGZpcnN0LCBmb3Ig ZXhhbXBsZSwgYW5kIHRoZW4KaGF2ZSB0aGUgInNvdXJjZXMiIGJlIGxvYWRlZCBzZWNvbmQ7IHBs dXMgd2UgaGF2ZSBhIGNsZWFyIHNlbWFudGljCnNlcGFyYXRpb24gb2YgZnVuY3Rpb25hbGl0eSB0 b28uCihhbHRob3VnaCwgaSBhc3N1bWUgdGhhdCBsaXN0aW5nIHRoZSBzdGFnZXMgaW4gdGhlIHJl dmVyc2Ugb3JkZXIgaW4KdGhlIGNvbmZpZyBmaWxlIHdvdWxkIGRvIHRoZSBzYW1lIHRyaWNrKS4K ClNvIG1heWJlIHdlIGNvdWxkIGxlYXZlIElQbHVnaW5zIGFzIHRoZXkgYXJlIGZvciBub3csIGFu ZCB0aGVuIG1ha2UgYQpkZWNpc2lvbiBvbiB3aGV0aGVyIHdlIHdhbnQgdG8gaW50cm9kdWNlICJz b3VyY2VzIiBhcyBmaXJzdC1vcmRlcgpvYmplY3RzIHNlcGFyYXRlIGZyb20gcGx1Z2lucywgYW5k IG1vdmUgcGx1Z2lucyBpbnRvIHRoZSBTUEkgZGlyIGFzCnlvdSBzdWdnZXN0LgoKcHM6IGknbSBj YydpbmcgdGhlIGRldiBsaXN0IHRvbywgaW4gY2FzZSBvdGhlcnMgaGF2ZSBzaW1pbGFyIG5lZWRz IGFzIEkgZm91bmQKCk9uIDcvMy8wNiwgSmVhbiBNb3Jpc3NldHRlIDxqZWFuLm1vcmlzc2V0dGVA Z21haWwuY29tPiB3cm90ZToKPiBIaSBUb2xpLAo+Cj4gSSByZXZpZXdlZCB5b3VyIHBhdGNoIGFu ZCBpdCdzIGFsbCBmaW5lIHRvIG1lLiAgUmVmYWN0b3Jpbmcgc29tZSBjb2RlCj4gb2YgSkN5Y2xv bmVDb25maWcgaW50byBGaWxlQ29uZmlnIHdhcyBhIGdvb2QgaWRlYS4gQWxzbywgTWFwQ29uZmln IGNhbgo+IGJlIHZlcnkgdXNlZnVsbCBmb3IgdW5pdCB0ZXN0cy4gIEdvb2Qgam9iIQo+Cj4gSSBq dXN0IGhhdmUgYSBtaW5vciByZW1hcms6IGluIEZpbGVDb25maWcsIGluc3RlYWQgb2YKPgo+ICAg IGZvciAoT2JqZWN0IGFDb25maWdLZXkgOiBjb25maWdzLmtleVNldCgpKSB7Cj4gICAgICAgU3Ry aW5nIGFLZXkgPSAoU3RyaW5nKWFDb25maWdLZXk7Cj4gICAgICAgT2JqZWN0IGFWYWx1ZSA9IGNv bmZpZ3MuZ2V0KGFLZXkpOwo+ICAgICAgIC4uLgo+Cj4gSSB3b3VsZCB3cml0ZQo+Cj4gICAgU2V0 PE1hcC5FbnRyeT4gZW50cmllcyA9IGNvbmZpZ3MuZW50cnlTZXQoKTsKPiAgICBmb3IgKE1hcC5F bnRyeSBlbnRyeSA6IGVudHJpZXMpIHsKPiAgICAgICBTdHJpbmcgYUtleSA9IChTdHJpbmcpIGVu dHJ5LmdldEtleSgpOwo+ICAgICAgIE9iamVjdCBhVmFsdWUgPSBlbnRyeS5nZXRWYWx1ZSgpOwo+ ICAgICAgIC4uLgo+Cj4gd2hpY2ggaXMgYSBsaXR0bGUgYml0IG1vcmUgZWZmaWNpZW50Lgo+Cj4g VGhlIG9ubHkgdGhpbmcgdGhhdCBJJ20gbm90IHN1cmUgaXMgdGhlIGNoYW5nZXMgcmVsYXRlZCB0 byBJUGx1Z2luLgo+IFBlcnNvbm5hbHksIEkgdGhpbmsgdGhhdCBJUGx1Z2luIHNob3VsZCBiZSB1 c2VkIGV4Y2x1c2l2ZWx5IHRvICJwbHVnIgo+IEpDeWNsb25lIGV4dGVuc2lvbnMuICBJIHdvdWxk IGV2ZW4gY29uc2lkZXIgbW92aW5nIGl0IGZyb20gdGhlIGFwaQo+IGRpcmVjdG9yeSB0byBhIFNl cnZpY2UgUHJvdmlkZXIgSW50ZXJmYWNlIChzcGkpIGRpcmVjdG9yeSwgZm9yIGJldHRlcgo+IGNs YXJpdHkuICBXaHkgeW91IGRvbid0IHVzZSBzdGFnZXMgaW5zdGVhZCBvZiBJUGx1Z2luPwo+Cj4g VGhhbmtzLAo+IEplYW4KPgo+Cj4gMjAwNi82LzMwLCBUb2xpIEt1em5ldHMgPHRvbGlAbWFya2V0 Y2V0ZXJhLmNvbT46Cj4gPiBKZWFuIGFuZCBvdGhlcnMsCj4gPgo+ID4gV2UgaGF2ZSBiZWVuIHVz aW5nIHRoZSBKQ3ljbG9uZSBDb3JlIGZyYW1ld29yayBmb3IgYSBmZXcgbW9udGhzIGluIG91cgo+ ID4gaW50ZXJuYWwgZGV2ZWxvcG1lbnQsIGFuZCBtYWRlIGEgZmV3IChpIGhvcGUpIHVzZWZ1bCBp bXByb3ZlbWVudHMgYW5kCj4gPiBidWcgZml4ZXMuCj4gPgo+ID4gSSd2ZSBhdHRhY2hlZCBhIHRh cmJhbGwgb2YgYWxsIGNoYW5nZWQgZmlsZXMgKGZvciB0aG9zZSB0aGF0IGxpa2UgdG8KPiA+IGRv IGEgZGlmZiBiZXR3ZWVuICJjbGVhbiIgYW5kIG1vZGlmaWVkIGRpcmVjdG9yaWVzKSwgYW5kIGEg cGF0Y2ggZmlsZS4KPiA+IFRoZSB0YXJiYWxsIGNvbnRhaW5zIGFsbCB0aGUgIm5ldyIgZmlsZXMs IGkgZGlkbid0IGtub3cgaG93IHRvIGluY2x1ZGUKPiA+IHRoZW0gaW50byB0aGUgcGF0Y2ggc2V0 IChpJ3ZlIGFsd2F5cyBkb25lIHRoZSAidW50YXIgdGhlIG5ldyBjb250ZW50Cj4gPiBpbnRvIG9u ZSBkaXIgYW5kIGNvbXBhcmUgYWdhaW5zdCBhICJwdXJlIiB2ZXJzaW9uIGFwcHJvYWNoKS4KPiA+ Cj4gPiBJIGFkZGVkIGEgdmVyeSBiYXNpYyB1bml0IHRlc3QgdG8gdGhlIGZyYW1ld29yaywgYnV0 IGhvcGVmdWxseSB3ZSBjYW4KPiA+IGFkZCBhIGZldyBtb3JlIGluIHRoZSBmdXR1cmUuCj4gPgo+ ID4gQ291bGQgc29tZWJvZHkgKEplYW4/KSBkbyBhIGNvZGUgcmV2aWV3IG9mIHRoaXM/IGknZCBi ZSBoYXBweSB0byBkbyBpdAo+ID4gb3ZlciBTa3lwZSwgYXMgc29tZSBvZiB0aGUgY2hhbmdlcyBt YXkgbm90IGJlIHRvdGFsbHkgZWFzeSB0byBzZWUuCj4gPiBJIm0gaW4gRVNUIChOZXcgWW9yaykg dGltZSB6b25lLgo+ID4KPiA+Cj4gPgo+ID4gSkN5Y2xvbmUgQ29yZSBjaGFuZ2VzCj4gPgo+ID4g ICAgICAgICAxLiAgICAgIFRlc3RzOiBjcmVhdGVkIGEgdGVzdC9jb25maWcgZGlyZWN0b3J5IGFu ZCBtb3ZlZC9yZW5hbWVkIGFsbAo+ID4gaW5kaXZpZHVhbCBqY3ljbG9uZS5jZmcgZmlsZXMgZm9y IGVhY2ggdGVzdCBpbnRvIHRoZSB0ZXN0L2NvbmZpZwo+ID4gc3ViZGlyZWN0b3J5Lgo+ID4gICAg ICAgICDigYMgICAgICAgdGhlc2UgYXJlIHRoZSBjaGFuZ2VzIGZvciBhbGwgdGVzdC8qKi9NYWlu LmphdmEgZmlsZXMKPiA+ICAgICAgICAgMi4gICAgICBBZGRlZCBhIG5ldyB0ZXN0L2ZpbGVjb25p ZmcgdGVzdCBkaXJlY3Rvcnkgd2hpY2ggaXMgYSBiYXNpYyB0ZXN0Cj4gPiB0aGF0IGNyZWF0ZXMg YSBjb25maWcgZmlsZSB3aXRoIHNvbWUgc3RhZ2VzIGFuZCBwbHVnaW5zIGFuZCB0cmllcyB0bwo+ ID4gbG9hZCB0aGVtIGFsbCB1cCBhbmQgdmVyaWZpZXMgdGhlIG9yZGVyIGluIHdoaWNoIHRoZXkg YXJlIGxvYWRlZC4KPiA+ICAgICAgICAg4oGDICAgICAgIHRoaXMgaXMgdGhlIGZpcnN0IEpVbml0 IHRlc3QKPiA+ICAgICAgICAgMy4gICAgICBBZGRlZCBhIHN1YmNsYXNzIG9mIEpDeWNsb25lQ29u ZmlnIGNhbGxlZCBGaWxlQ29uZmlnIHRoYXQgYWxsb3dzCj4gPiB0aGUgY29uZmlndXJhdGlvbiB0 byBiZSBzZXQgZnJvbSBhIGZpbGUgdGhhdCBpcyBwYXNzZWQgaW4uIHRoZQo+ID4gRmlsZUNvbmZp ZyBpbmhlcml0ZWQgdGhlIFBhcnNlckZhY3RvcnkgY2xhc3MgdGhhdCB3YXMgcGFydCBvZgo+ID4g SkN5Y2xvbmVDb25maWcKPiA+ICAgICAgICAgNC4gICAgICBQbHVnaW5zOiBhZGRlZCBhIHBsdWdp bk5hbWUgYW5kIGEgZGVzdHJveSgpIG1ldGhvZCB0byBJUGx1Z2luLmphdmEKPiA+ICAgICAgICAg NS4gICAgICBNb2RpZmllZCBKQ3ljbG9uZU1nciB0byBrZWVwIHRyYWNrIG9mIGFsbCBwbHVnaW5z LCBhbmQgdG8gZGVzdHJveQo+ID4gdGhlbSBhdCB0aGUgZW5kLiBQbHVnaW5zIGFyZSBub3cgdW5s b2FkZWQgYmVmb3JlIHN0YWdlcyBpbiB0aGUgc3RvcCgpCj4gPiBtZXRob2QsIGFuZCBhcmUgaW5p dGlhbGl6ZWQgaW4gdGhlIEpDeWNsb25lIGNvbnN0cnVjdG9yIHJpZ2h0IGFmdGVyCj4gPiBzdGFn ZXMgaGF2ZSBiZWVuIHN0YXJ0ZWQuIFRoZSBpZGVhIGhlcmUgaXMgdGhhdCB3ZSB3YW50IHRvIGJl Cj4gPiBzeW1tZXRyaWNhbCAtIFBsdWdpbnMgYXJlIHRyZWF0ZWQgYXMgcHJvZHVjZXJzIChpbml0 aWFsIGlucHV0cykgaW50bwo+ID4gdGhlIEpDeWNsb25lIGZyYW1ld29ya3MsIHNvIHRoZXkgbmVl ZCB0byBiZSBzdGFydGVkIGFmdGVyIHRoZSBzdGFnZXMKPiA+ICh3aGljaCBhcmUgY29uc3VtZXJz KSBoYXZlIGJlZW4gc3RhcnRlZCwgbm90IGJlZm9yZSAod2hpY2ggd2FzIHRoZQo+ID4gY2FzZSku Cj4gPiAgICAgICAgIDYuICAgICAgVGhyZWFkUG9vbCBjbGFzcyBnb3QgYSBiaXQgb2YgYSByZXdy aXRlCj4gPiAgICAgICAgIOKBgyAgICAgICB0aGVyZSB3YXMgYSBzdGFydmF0aW9uIGlzc3VlIGlu IFRocmVhZFBvb2wuYXdhaXRUZXJtaW5hdGlvbigpIC0gb24KPiA+IExpbnV4ICh1bmxpa2UgV2lu ZG93cy9NYWNPU1gpIHdlIHNhdyB0aHJlYWQgc3RhcnZhdGlvbiB3aGVuIHRoZQo+ID4gdGhyZWFk cG9vbCB3YXMgc2h1dHRpbmcgZG93biBhbmQgdGVybWluYXRpbmcgYWxsIGNoaWxkIHRocmVhZHMu IFNvIHRoZQo+ID4gYXdhaXRUZXJtaW5hdGlvbigpIGZ1bmN0aW9uIHdhcyByZXdyaXR0ZW4gdG8g bWluaW1pemUgb2JqZWN0LWxldmVsCj4gPiBibG9ja2luZyBhbmQgYnJlYWsgdXAgc3luY2hyb25p emF0aW9uIGludG8gc21hbGxlciBwaWVjZXMKPiA+ICAgICAgICAg4oGDICAgICAgIERFRkFVTFRf QkxPQ0tfVElNRSBhbmQgREVGQVVMVF9JRExFX1RIUkVTSE9MRCB3ZXJlIG5vdCByZWFkCj4gPiBj b3JyZWN0bHkgZnJvbSBjb25maWcgZmlsZSAtIHRoZXkgd2VyZSBkZWZhdWx0aW5nIHRvIDAgKHdo YXQgdGhleSB3ZXJlCj4gPiBpbml0aWFsaXplZCB0byBpbiBjb25zdHJ1Y3RvcikuIEFzIGEgcmVz dWx0LCB3aGVuIElQbHVnaW5zIHRoYXQgd2VyZQo+ID4gaW5zdGFuY2VzIG9mIElTaW5nbGVUaHJl YWRlZEV2ZW50SGFuZGxlciBjYW1lIGludG8gdGhlIFRQU1NjaGVkdWxlciwKPiA+IHRoZXkgd2Vy ZSBjcmVhdGVkIHdpdGggYSB0aHJlYWRwb29sIG9mIGlkbGUvYmxvY2sgdGltZSBvZiAwIC0gd2hp Y2gKPiA+IHdhcyBpbmVmZmljaWVudC4KPiA+ICAgICAgICAg4oGDCj4gPgo+ID4KPgo= |
From: Toli K. <to...@ma...> - 2006-06-30 20:11:02
|
SmVhbiBhbmQgb3RoZXJzLAoKV2UgaGF2ZSBiZWVuIHVzaW5nIHRoZSBKQ3ljbG9uZSBDb3JlIGZy YW1ld29yayBmb3IgYSBmZXcgbW9udGhzIGluIG91cgppbnRlcm5hbCBkZXZlbG9wbWVudCwgYW5k IG1hZGUgYSBmZXcgKGkgaG9wZSkgdXNlZnVsIGltcHJvdmVtZW50cyBhbmQKYnVnIGZpeGVzLgoK SSd2ZSBhdHRhY2hlZCBhIHRhcmJhbGwgb2YgYWxsIGNoYW5nZWQgZmlsZXMgKGZvciB0aG9zZSB0 aGF0IGxpa2UgdG8KZG8gYSBkaWZmIGJldHdlZW4gImNsZWFuIiBhbmQgbW9kaWZpZWQgZGlyZWN0 b3JpZXMpLCBhbmQgYSBwYXRjaCBmaWxlLgpUaGUgdGFyYmFsbCBjb250YWlucyBhbGwgdGhlICJu ZXciIGZpbGVzLCBpIGRpZG4ndCBrbm93IGhvdyB0byBpbmNsdWRlCnRoZW0gaW50byB0aGUgcGF0 Y2ggc2V0IChpJ3ZlIGFsd2F5cyBkb25lIHRoZSAidW50YXIgdGhlIG5ldyBjb250ZW50CmludG8g b25lIGRpciBhbmQgY29tcGFyZSBhZ2FpbnN0IGEgInB1cmUiIHZlcnNpb24gYXBwcm9hY2gpLgoK SSBhZGRlZCBhIHZlcnkgYmFzaWMgdW5pdCB0ZXN0IHRvIHRoZSBmcmFtZXdvcmssIGJ1dCBob3Bl ZnVsbHkgd2UgY2FuCmFkZCBhIGZldyBtb3JlIGluIHRoZSBmdXR1cmUuCgpDb3VsZCBzb21lYm9k eSAoSmVhbj8pIGRvIGEgY29kZSByZXZpZXcgb2YgdGhpcz8gaSdkIGJlIGhhcHB5IHRvIGRvIGl0 Cm92ZXIgU2t5cGUsIGFzIHNvbWUgb2YgdGhlIGNoYW5nZXMgbWF5IG5vdCBiZSB0b3RhbGx5IGVh c3kgdG8gc2VlLgpJIm0gaW4gRVNUIChOZXcgWW9yaykgdGltZSB6b25lLgoKCgpKQ3ljbG9uZSBD b3JlIGNoYW5nZXMKCgkxLglUZXN0czogY3JlYXRlZCBhIHRlc3QvY29uZmlnIGRpcmVjdG9yeSBh bmQgbW92ZWQvcmVuYW1lZCBhbGwKaW5kaXZpZHVhbCBqY3ljbG9uZS5jZmcgZmlsZXMgZm9yIGVh Y2ggdGVzdCBpbnRvIHRoZSB0ZXN0L2NvbmZpZwpzdWJkaXJlY3RvcnkuCgnigYMJdGhlc2UgYXJl IHRoZSBjaGFuZ2VzIGZvciBhbGwgdGVzdC8qKi9NYWluLmphdmEgZmlsZXMKCTIuCUFkZGVkIGEg bmV3IHRlc3QvZmlsZWNvbmlmZyB0ZXN0IGRpcmVjdG9yeSB3aGljaCBpcyBhIGJhc2ljIHRlc3QK dGhhdCBjcmVhdGVzIGEgY29uZmlnIGZpbGUgd2l0aCBzb21lIHN0YWdlcyBhbmQgcGx1Z2lucyBh bmQgdHJpZXMgdG8KbG9hZCB0aGVtIGFsbCB1cCBhbmQgdmVyaWZpZXMgdGhlIG9yZGVyIGluIHdo aWNoIHRoZXkgYXJlIGxvYWRlZC4KCeKBgwl0aGlzIGlzIHRoZSBmaXJzdCBKVW5pdCB0ZXN0Cgkz LglBZGRlZCBhIHN1YmNsYXNzIG9mIEpDeWNsb25lQ29uZmlnIGNhbGxlZCBGaWxlQ29uZmlnIHRo YXQgYWxsb3dzCnRoZSBjb25maWd1cmF0aW9uIHRvIGJlIHNldCBmcm9tIGEgZmlsZSB0aGF0IGlz IHBhc3NlZCBpbi4gdGhlCkZpbGVDb25maWcgaW5oZXJpdGVkIHRoZSBQYXJzZXJGYWN0b3J5IGNs YXNzIHRoYXQgd2FzIHBhcnQgb2YKSkN5Y2xvbmVDb25maWcKCTQuCVBsdWdpbnM6IGFkZGVkIGEg cGx1Z2luTmFtZSBhbmQgYSBkZXN0cm95KCkgbWV0aG9kIHRvIElQbHVnaW4uamF2YQoJNS4JTW9k aWZpZWQgSkN5Y2xvbmVNZ3IgdG8ga2VlcCB0cmFjayBvZiBhbGwgcGx1Z2lucywgYW5kIHRvIGRl c3Ryb3kKdGhlbSBhdCB0aGUgZW5kLiBQbHVnaW5zIGFyZSBub3cgdW5sb2FkZWQgYmVmb3JlIHN0 YWdlcyBpbiB0aGUgc3RvcCgpCm1ldGhvZCwgYW5kIGFyZSBpbml0aWFsaXplZCBpbiB0aGUgSkN5 Y2xvbmUgY29uc3RydWN0b3IgcmlnaHQgYWZ0ZXIKc3RhZ2VzIGhhdmUgYmVlbiBzdGFydGVkLiBU aGUgaWRlYSBoZXJlIGlzIHRoYXQgd2Ugd2FudCB0byBiZQpzeW1tZXRyaWNhbCAtIFBsdWdpbnMg YXJlIHRyZWF0ZWQgYXMgcHJvZHVjZXJzIChpbml0aWFsIGlucHV0cykgaW50bwp0aGUgSkN5Y2xv bmUgZnJhbWV3b3Jrcywgc28gdGhleSBuZWVkIHRvIGJlIHN0YXJ0ZWQgYWZ0ZXIgdGhlIHN0YWdl cwood2hpY2ggYXJlIGNvbnN1bWVycykgaGF2ZSBiZWVuIHN0YXJ0ZWQsIG5vdCBiZWZvcmUgKHdo aWNoIHdhcyB0aGUKY2FzZSkuCgk2LglUaHJlYWRQb29sIGNsYXNzIGdvdCBhIGJpdCBvZiBhIHJl d3JpdGUJCgnigYMJdGhlcmUgd2FzIGEgc3RhcnZhdGlvbiBpc3N1ZSBpbiBUaHJlYWRQb29sLmF3 YWl0VGVybWluYXRpb24oKSAtIG9uCkxpbnV4ICh1bmxpa2UgV2luZG93cy9NYWNPU1gpIHdlIHNh dyB0aHJlYWQgc3RhcnZhdGlvbiB3aGVuIHRoZQp0aHJlYWRwb29sIHdhcyBzaHV0dGluZyBkb3du IGFuZCB0ZXJtaW5hdGluZyBhbGwgY2hpbGQgdGhyZWFkcy4gU28gdGhlCmF3YWl0VGVybWluYXRp b24oKSBmdW5jdGlvbiB3YXMgcmV3cml0dGVuIHRvIG1pbmltaXplIG9iamVjdC1sZXZlbApibG9j a2luZyBhbmQgYnJlYWsgdXAgc3luY2hyb25pemF0aW9uIGludG8gc21hbGxlciBwaWVjZXMKCeKB gwlERUZBVUxUX0JMT0NLX1RJTUUgYW5kIERFRkFVTFRfSURMRV9USFJFU0hPTEQgd2VyZSBub3Qg cmVhZApjb3JyZWN0bHkgZnJvbSBjb25maWcgZmlsZSAtIHRoZXkgd2VyZSBkZWZhdWx0aW5nIHRv IDAgKHdoYXQgdGhleSB3ZXJlCmluaXRpYWxpemVkIHRvIGluIGNvbnN0cnVjdG9yKS4gQXMgYSBy ZXN1bHQsIHdoZW4gSVBsdWdpbnMgdGhhdCB3ZXJlCmluc3RhbmNlcyBvZiBJU2luZ2xlVGhyZWFk ZWRFdmVudEhhbmRsZXIgY2FtZSBpbnRvIHRoZSBUUFNTY2hlZHVsZXIsCnRoZXkgd2VyZSBjcmVh dGVkIHdpdGggYSB0aHJlYWRwb29sIG9mIGlkbGUvYmxvY2sgdGltZSBvZiAwIC0gd2hpY2gKd2Fz IGluZWZmaWNpZW50LgoJ4oGDCg== |
From: Jean M. <jea...@vi...> - 2005-11-01 09:48:49
|
Hi, It's time to think on the next steps for JCyclone. The way i see it we have several things to do for having a healty community and reach a good momemtum. First, I would like to discuss about our roadmap for the next version and once we will reach agreement, I will post on SourceForge (and others OS forums) for voluteers to get some help. Here are some suggestions. - Remote management/monitoring by using JMX. - Logging mecanism. We have already discussed about that, however we still don't have reached agreement on the library choice. - Support true XML configuration file. - Remote queues (for a first step in distributed JCyclone applications). One simple approach would be to set up individual TCP connections, one per queue, between node pair. However, if the number of remote queues grows, the overhead of running several TCP connections become important. A more scalable approach is to multiplex all the events to a single TCP connection. Also, we could investigate UDP-based approachs, especially if events don't need to be ordered. - Finish the very experimental (and very interesting) continuation-based scheduler, which give us a fine control over the threads scheduling. This scheduler opens the door to make JCyclone a real-time platform! - Implement new scheduler policies, so user would be able to choose the most appropriate one for its application. Note that the continuation-based scheduler could be used to implement a lot of efficient scheduling policy. - New JVMs handle memory very efficiently (see http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html). However, we could do even better. Indeed, since events in a SEDA-based applications flow from downstream stages to upstream stages, each stage that create event could use a factory which keep a pool of events in FIFO order. The idea is to allocate and deallocate in order events belonging to a factory. Doing so, we would prevent costly and not predictable garbage collection, making JCyclone fully real-time! This would be easy to implement for a tree-based stages network, however I don't know if it's possible for a graph-based stages network. What do you think? Also, I invite you to give me your feedback. What would you love to see in future releases? Do you use JCyclone in production? Is the learning curve too high? Do performances respond to your expectations? etc Thanks, -Jean |