You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(22) |
Nov
(85) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(47) |
Feb
(127) |
Mar
(268) |
Apr
(78) |
May
(47) |
Jun
(38) |
Jul
(131) |
Aug
(221) |
Sep
(187) |
Oct
(54) |
Nov
(111) |
Dec
(84) |
2011 |
Jan
(152) |
Feb
(106) |
Mar
(94) |
Apr
(90) |
May
(53) |
Jun
(20) |
Jul
(24) |
Aug
(37) |
Sep
(32) |
Oct
(70) |
Nov
(22) |
Dec
(15) |
2012 |
Jan
(33) |
Feb
(110) |
Mar
(24) |
Apr
(1) |
May
(11) |
Jun
(8) |
Jul
(12) |
Aug
(37) |
Sep
(39) |
Oct
(81) |
Nov
(38) |
Dec
(50) |
2013 |
Jan
(23) |
Feb
(53) |
Mar
(23) |
Apr
(5) |
May
(19) |
Jun
(16) |
Jul
(16) |
Aug
(9) |
Sep
(21) |
Oct
(1) |
Nov
(2) |
Dec
(8) |
2014 |
Jan
(16) |
Feb
(6) |
Mar
(27) |
Apr
(1) |
May
(10) |
Jun
(1) |
Jul
(4) |
Aug
(10) |
Sep
(19) |
Oct
(22) |
Nov
(4) |
Dec
(6) |
2015 |
Jan
(3) |
Feb
(6) |
Mar
(9) |
Apr
|
May
(11) |
Jun
(23) |
Jul
(14) |
Aug
(10) |
Sep
(10) |
Oct
(9) |
Nov
(18) |
Dec
(4) |
2016 |
Jan
(5) |
Feb
(5) |
Mar
|
Apr
(2) |
May
(15) |
Jun
(2) |
Jul
(8) |
Aug
(2) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
(2) |
Feb
(12) |
Mar
(22) |
Apr
(6) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(3) |
Aug
|
Sep
(7) |
Oct
(19) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Wolfgang M. <wol...@ex...> - 2010-02-06 20:19:10
|
> I did commit fix for AllXmlRpcTests > ( http://exist.svn.sourceforge.net/exist/?rev=11135&view=rev ) , please > confirm that this one fixed. Mmmh, I think this is a bad fix. Every test should be self-contained. The server should be stopped when the test has finished, so the next test can Anyway, I believe I know where the problem is .... Wolfgang |
From: Dmitriy S. <sha...@gm...> - 2010-02-06 20:13:25
|
Hello, I did commit fix for AllXmlRpcTests ( http://exist.svn.sourceforge.net/exist/?rev=11135&view=rev ) , please confirm that this one fixed. If not we should make server @JettyStart static. -- Cheers, Dmitriy Shabanov On Sat, 2010-02-06 at 20:23 +0100, Wolfgang Meier wrote: > Hi Joe, > > ok, so we are at least all getting those errors. > > > I'm admittedly a testing newbie here. Is there a resource you could > > point me to so I could understand junit or how eXist implements it? > > We are mostly using junit4. This is probably rather difficult to > understand without knowing Java, though I recently tried to write more > tests in XQuery (see test/src/xquery/). > > Anyway, each test class should be self-contained. If a class needs a > running server for its test, it will start one, usually in its > @BeforeClass method and stop it in @AfterClass. This worked perfectly > well until recently. But if you now try to run, for example, > AllXmlRpcTests: > > bin/run.sh org.junit.runner.JUnitCore org.exist.xmlrpc.AllXmlRpcTests > > you more or less see how the first test class completes and closes > down the server, but while the second test class starts up a new > jetty, Java just terminates without further notice. > > Wolfgang |
From: Joe W. <jo...@gm...> - 2010-02-06 19:46:49
|
Hi Wolfgang, > We are mostly using junit4. This is probably rather difficult to > understand without knowing Java, though I recently tried to write more > tests in XQuery (see test/src/xquery/). Yeah, I see what you mean about the difficulty of understanding it without knowing Java. I did just have a look through the XQuery tests in test/src/xquery, and found that pretty easy to understand. Cool! I didn't realize we had a framework for unit tests written in XQuery! I've seen Chris Wallace's blog posts suggesting some ways to do such tests, and I've been following Florent Georges and Jeni Tennison's XSpec project on googlecode. > Anyway, each test class should be self-contained. If a class needs a > running server for its test, it will start one, usually in its > @BeforeClass method and stop it in @AfterClass. This worked perfectly > well until recently. But if you now try to run, for example, > AllXmlRpcTests: > > bin/run.sh org.junit.runner.JUnitCore org.exist.xmlrpc.AllXmlRpcTests > > you more or less see how the first test class completes and closes > down the server, but while the second test class starts up a new > jetty, Java just terminates without further notice. I see.... Hmm... I think this gets into Java territory, above my head. I'm happy to run any tests that would be useful, though, and report my results. Joe |
From: Joe W. <jo...@gm...> - 2010-02-06 19:29:27
|
Hi Dannes, > Running on my Mac dev-box, I have 2 failures and 2 errors. Almost the same. > On the PC, with the big numbers I have also the Spatial index enabled. > Maybe there is a relation.... I remember Pierrick mentioned something in > this area... Ah, I should add that I was running on a Mac (10.6.2), without spatial index. I enabled all optional modules in conf.xml except those that require build.properties or local.build.properties values to be changed (JNDI, XSLFO, etc.). One apparent bug in the teardown of a test: after the test was complete, this entry remained in my /db/system/users.xml <user name="rudi" uid="3" password="{MD5}Gh3JHJBzJcaScd3wyUS8cg==" digest-password="0103d1b2d0c7691e111d7a40d0af50c9"> <group>guest</group> </user> Joe |
From: Wolfgang M. <wol...@ex...> - 2010-02-06 19:24:07
|
Hi Joe, ok, so we are at least all getting those errors. > I'm admittedly a testing newbie here. Is there a resource you could > point me to so I could understand junit or how eXist implements it? We are mostly using junit4. This is probably rather difficult to understand without knowing Java, though I recently tried to write more tests in XQuery (see test/src/xquery/). Anyway, each test class should be self-contained. If a class needs a running server for its test, it will start one, usually in its @BeforeClass method and stop it in @AfterClass. This worked perfectly well until recently. But if you now try to run, for example, AllXmlRpcTests: bin/run.sh org.junit.runner.JUnitCore org.exist.xmlrpc.AllXmlRpcTests you more or less see how the first test class completes and closes down the server, but while the second test class starts up a new jetty, Java just terminates without further notice. Wolfgang |
From: Dannes W. <da...@ex...> - 2010-02-06 19:03:35
|
Running on my Mac dev-box, I have 2 failures and 2 errors. Almost the same. On the PC, with the big numbers I have also the Spatial index enabled. Maybe there is a relation.... I remember Pierrick mentioned something in this area... D. On Sat, Feb 6, 2010 at 8:00 PM, Joe Wicentowski <jo...@gm...> wrote: > Hi Dannes and Wolfgang, > > > I really think we should freeze the codebase at this moment and focus on > the > > stability of the junit test suite. I mean, we have a serious xmlrpc crash > > (unclear where it is originated) and some other strange issues (here: 187 > > failures, 136 errors). > ... > > I would definitely be happy to get some help on this. > > I'm not sure how much I'd be able to help without java skills, but I'd > be happy to help in any way I can. I just ran "./build.sh test" on > trunk and got 0 failures and 2 errors (as reported in > EXIST_HOME/test/junit/html/index.html). The 2 errors are in > org.exist.security and org.exist.xmlrpc. > > I'm admittedly a testing newbie here. Is there a resource you could > point me to so I could understand junit or how eXist implements it? > > Joe > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Joe W. <jo...@gm...> - 2010-02-06 19:00:52
|
Hi Dannes and Wolfgang, > I really think we should freeze the codebase at this moment and focus on the > stability of the junit test suite. I mean, we have a serious xmlrpc crash > (unclear where it is originated) and some other strange issues (here: 187 > failures, 136 errors). ... > I would definitely be happy to get some help on this. I'm not sure how much I'd be able to help without java skills, but I'd be happy to help in any way I can. I just ran "./build.sh test" on trunk and got 0 failures and 2 errors (as reported in EXIST_HOME/test/junit/html/index.html). The 2 errors are in org.exist.security and org.exist.xmlrpc. I'm admittedly a testing newbie here. Is there a resource you could point me to so I could understand junit or how eXist implements it? Joe |
From: Wolfgang M. <wol...@ex...> - 2010-02-06 17:22:32
|
I already spent more than a day to find out what causes those JVM crashes in the test suite, but without any results. For example, org.exist.xmlrpc.AllXmlRpcTests runs two tests: QuerySessionTest and XmlRpcTest. If you run either of these on their own, they will run through perfectly well. If you run them as a suite (AllXmlRpcTests), the second one will crash. The issues are definitely related to jetty somehow. I would definitely be happy to get some help on this. Wolfgang |
From: Dannes W. <da...@ex...> - 2010-02-06 16:58:34
|
Folks, I really think we should freeze the codebase at this moment and focus on the stability of the junit test suite. I mean, we have a serious xmlrpc crash (unclear where it is originated) and some other strange issues (here: 187 failures, 136 errors). That can't be true!...... regards Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Andrzej J. T. <an...@ch...> - 2010-02-04 21:53:28
|
Thomas: > I would like to thank you both for helping me to see the simple solution > that was right in front of my nose :-) No worries! -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Thomas W. <tho...@gm...> - 2010-02-04 21:46:53
|
Andrzej and Adam, I would like to thank you both for helping me to see the simple solution that was right in front of my nose :-) Thomas ----- Original Message ----- From: "Andrzej Jan Taramina" <an...@ch...> To: "Thomas White" <tho...@gm...> Cc: "Adam Retter" <ad...@ex...>; <exi...@li...> Sent: Thursday, February 04, 2010 2:34 PM Subject: Re: Execution Pipeline, async xquery execution... > Thomas: > >> I think the opposite way - this is generic functionality. It is an >> equivalent of BREAK in FOR loop. > > Beware of mixed metaphors. Scheduled jobs and schedulers are not the same > as language design constructs. > > And since it's not that hard to implement what you need with existing > functionality, my vote stays at -1. ;-) > >> One more thing. When we have an asynchronous function it is very >> common to have a callback function that is called at completion of the >> main function. If we have an option to pass a callback function when >> we schedule an XQuery function, this will allow us to do post >> processing on the results. > > The question with an async XQuery call is callback to where? Right now, > there is no way to guarantee that the > initiating XQuery is still running (XQuery being a sort-of, more or less, > functional language). > > Having your async XQuery (initiated using the Scheduler functions) call a > separate XQuery at the end to do post > processing is not that difficult. > > -- > Andrzej Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > |
From: Andrzej J. T. <an...@ch...> - 2010-02-04 14:35:00
|
Thomas: > I think the opposite way - this is generic functionality. It is an > equivalent of BREAK in FOR loop. Beware of mixed metaphors. Scheduled jobs and schedulers are not the same as language design constructs. And since it's not that hard to implement what you need with existing functionality, my vote stays at -1. ;-) > One more thing. When we have an asynchronous function it is very > common to have a callback function that is called at completion of the > main function. If we have an option to pass a callback function when > we schedule an XQuery function, this will allow us to do post > processing on the results. The question with an async XQuery call is callback to where? Right now, there is no way to guarantee that the initiating XQuery is still running (XQuery being a sort-of, more or less, functional language). Having your async XQuery (initiated using the Scheduler functions) call a separate XQuery at the end to do post processing is not that difficult. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Adam R. <ad...@ex...> - 2010-02-04 11:39:12
|
On 4 February 2010 10:27, Thomas White <tho...@gm...> wrote: > On 3 February 2010 21:21, Andrzej Jan Taramina <an...@ch...> wrote: >> >> Thomas: >> >> > That will work, but it seams a little bit messy. The function has to be >> > prepared specifically to know how to chain with re-scheduling call to >> > itself at the end of the function. >> >> True, but that is a very simple thing to do, and the XQuery would be crafted to be run using the scheduler only (though >> there are fancy ways to craft an XQuery that can run with a REST invocation and as a scheduled task). > > I this is an application very specific approach. I would use it only > if there is no other way. > >> > On other hand if we have schedule-xquery-periodic-job extended to pay >> > attentions to the returned value, then any function that returns boolean >> > can be called repeatedly until the data is consumed. >> >> I'm gonna vote -1 on that. It's outside of the scope of what a periodic scheduled job should do and is really >> application specific. > > I think the opposite way - this is generic functionality. It is an > equivalent of BREAK in FOR loop. > I can't think about more generic then a break functionality. > > One more thing. When we have an asynchronous function it is very > common to have a callback function that is called at completion of the > main function. If we have an option to pass a callback function when > we schedule an XQuery function, this will allow us to do post > processing on the results. You can already pass functions in XQuery through the function() and call() functions. I agree with Andrzej though. Everything that you need is already present. > Thomas > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Thomas W. <tho...@gm...> - 2010-02-04 10:28:21
|
On 3 February 2010 21:21, Andrzej Jan Taramina <an...@ch...> wrote: > > Thomas: > > > That will work, but it seams a little bit messy. The function has to be > > prepared specifically to know how to chain with re-scheduling call to > > itself at the end of the function. > > True, but that is a very simple thing to do, and the XQuery would be crafted to be run using the scheduler only (though > there are fancy ways to craft an XQuery that can run with a REST invocation and as a scheduled task). I this is an application very specific approach. I would use it only if there is no other way. > > On other hand if we have schedule-xquery-periodic-job extended to pay > > attentions to the returned value, then any function that returns boolean > > can be called repeatedly until the data is consumed. > > I'm gonna vote -1 on that. It's outside of the scope of what a periodic scheduled job should do and is really > application specific. I think the opposite way - this is generic functionality. It is an equivalent of BREAK in FOR loop. I can't think about more generic then a break functionality. One more thing. When we have an asynchronous function it is very common to have a callback function that is called at completion of the main function. If we have an option to pass a callback function when we schedule an XQuery function, this will allow us to do post processing on the results. Thomas |
From: Evgeny G. <gaz...@gm...> - 2010-02-04 07:23:19
|
> > > I currently get 2 failures and 2 errors. The 2 errors are both due to > "Java VM exited abnormally". We have this issue for a few weeks now > and it is not clear what's causing it. I'd so issue too. I though that this cause out of mem, at me. After closing some java's app, like eclipse, all tests were ran. ---------- Evgney |
From: Andrzej J. T. <an...@ch...> - 2010-02-03 21:23:59
|
Wolfgang: > I currently get 2 failures and 2 errors. The 2 errors are both due to > "Java VM exited abnormally". We have this issue for a few weeks now > and it is not clear what's causing it. If you run the tests > separately, they run ok. I spent a few hours looking into the problem, > but couldn't find anything. The JVM just seems to crash at some point. > I guess it has something to do with Jetty being started as part of the > tests. > > Anyway, apart from those expected errors, the test suite should be fine. I get a ton of NPE's when I run the full suite, plus the VM abnormal exit too. I wonder if something isn't configured correctly for Jetty/Embedded running that might cause this, since I never run embedded mode? -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Andrzej J. T. <an...@ch...> - 2010-02-03 21:21:54
|
Thomas: > That will work, but it seams a little bit messy. The function has to be > prepared specifically to know how to chain with re-scheduling call to > itself at the end of the function. True, but that is a very simple thing to do, and the XQuery would be crafted to be run using the scheduler only (though there are fancy ways to craft an XQuery that can run with a REST invocation and as a scheduled task). > On other hand if we have schedule-xquery-periodic-job extended to pay > attentions to the returned value, then any function that returns boolean > can be called repeatedly until the data is consumed. I'm gonna vote -1 on that. It's outside of the scope of what a periodic scheduled job should do and is really application specific. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Thomas W. <tho...@gm...> - 2010-02-03 20:43:30
|
Andrzej, That will work, but it seams a little bit messy. The function has to be prepared specifically to know how to chain with re-scheduling call to itself at the end of the function. On other hand if we have schedule-xquery-periodic-job extended to pay attentions to the returned value, then any function that returns boolean can be called repeatedly until the data is consumed. Thomas ------ Thomas White Mobile:+44 7711 922 966 Skype: thomaswhite gTalk: thomas.0007 Linked-In:http://www.linkedin.com/in/thomaswhite0007 facebook: http://www.facebook.com/thomas.0007 On 3 February 2010 16:36, Adam Retter <ad...@ex...> wrote: > On 3 February 2010 16:09, Andrzej Jan Taramina <an...@ch...> > wrote: > > Thomas: > > > >> BTW, is there a way to reduce the number remaining calls for > >> *schedule-xquery-periodic-job* in run time? > >> Use case: I need to process a dataset running periodically a XQuery > >> function that process a chunk of that data. I expect to have 5000 calls > >> but the data set is smaller this time and I need to cancel it after the > >> 50th call. Can I do this? If not, I hope we can then extend > >> *schedule-xquery-periodic-job* function to cancel the job if the > >> scheduled function returns false(). > > > > The easiest way to do that might be to just trigger the first call....and > have each call chain to another call (that is, > > fire another scheduled job to run immediately), if there is data left to > process. > > > > That way the calls will just keep being initiated until all the data is > consumed and processed. > > Thats a much nicer approach :-) > > > -- > > Andrzej Taramina > > Chaeron Corporation: Enterprise System Solutions > > http://www.chaeron.com > > > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > |
From: Dmitriy S. <sha...@gm...> - 2010-02-03 19:46:15
|
On Wed, 2010-02-03 at 19:26 +0100, Wolfgang Meier wrote: > > I've noticed that there seem to be quite a few errors due to NPEs for the org.exist.storage, org.exist.xquery and > > org.exist.xmlrpc tests. > > I currently get 2 failures and 2 errors. The 2 errors are both due to > "Java VM exited abnormally". We have this issue for a few weeks now > and it is not clear what's causing it. If you run the tests > separately, they run ok. I spent a few hours looking into the problem, > but couldn't find anything. The JVM just seems to crash at some point. > I guess it has something to do with Jetty being started as part of the > tests. Jetty have 2 minutes delay on shutdown. Can it be a problem maker? -- Cheers, Dmitriy Shabanov |
From: Wolfgang M. <wol...@ex...> - 2010-02-03 18:26:19
|
> I've noticed that there seem to be quite a few errors due to NPEs for the org.exist.storage, org.exist.xquery and > org.exist.xmlrpc tests. I currently get 2 failures and 2 errors. The 2 errors are both due to "Java VM exited abnormally". We have this issue for a few weeks now and it is not clear what's causing it. If you run the tests separately, they run ok. I spent a few hours looking into the problem, but couldn't find anything. The JVM just seems to crash at some point. I guess it has something to do with Jetty being started as part of the tests. Anyway, apart from those expected errors, the test suite should be fine. Wolfgang |
From: Andrzej J. T. <an...@ch...> - 2010-02-03 16:45:43
|
Been running a lot of unit tests, fixing the general comparator regex bug. I've noticed that there seem to be quite a few errors due to NPEs for the org.exist.storage, org.exist.xquery and org.exist.xmlrpc tests. Are these just broken tests? Sure would be nice to get those cleaned up, so that we can get a clean unit test run. <hint, hint, ;-) > -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Adam R. <ad...@ex...> - 2010-02-03 16:36:32
|
On 3 February 2010 16:09, Andrzej Jan Taramina <an...@ch...> wrote: > Thomas: > >> BTW, is there a way to reduce the number remaining calls for >> *schedule-xquery-periodic-job* in run time? >> Use case: I need to process a dataset running periodically a XQuery >> function that process a chunk of that data. I expect to have 5000 calls >> but the data set is smaller this time and I need to cancel it after the >> 50th call. Can I do this? If not, I hope we can then extend >> *schedule-xquery-periodic-job* function to cancel the job if the >> scheduled function returns false(). > > The easiest way to do that might be to just trigger the first call....and have each call chain to another call (that is, > fire another scheduled job to run immediately), if there is data left to process. > > That way the calls will just keep being initiated until all the data is consumed and processed. Thats a much nicer approach :-) > -- > Andrzej Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Adam R. <ad...@ex...> - 2010-02-03 16:35:46
|
On 3 February 2010 15:46, Thomas White <tho...@gm...> wrote: > Adam, > > Where shell I start, may be from the fact I was not aware there are new > functions in the scheduler. Very lame :-) I dont think these are new functions, but perhaps I am not aware that someone else has augmented them? > I guess when you say "one-shot asynchronous execution" you mean > using schedule-xquery-periodic-job called with $period=0, and $repeat=1. > It seams then I have everything I need to create the batch asynch > functionality I described earlier. Yes, that is exactly the case. > BTW, is there a way to reduce the number remaining calls for > schedule-xquery-periodic-job in run time? > Use case: I need to process a dataset running periodically a XQuery function > that process a chunk of that data. I expect to have 5000 calls but the data > set is smaller this time and I need to cancel it after the 50th call. Can I > do this? If not, I hope we can then extend > schedule-xquery-periodic-job function to cancel the job if the scheduled > function returns false(). eXist maintains an Abstract idea of a Scheduler and the underlying implementation is provided by Quartz, it should be fairly easy maybe 1 - 2 hours work to abstract around the Quatz Scheduler.rescheduleJob() function and expose that functionality via the XQuery Scheduler module. > Regards, > Thomas > > ------ > > Thomas White > > Mobile:+44 7711 922 966 > Skype: thomaswhite > gTalk: thomas.0007 > Linked-In:http://www.linkedin.com/in/thomaswhite0007 > facebook: http://www.facebook.com/thomas.0007 > > > > On 3 February 2010 11:18, Adam Retter <ad...@ex...> wrote: >> >> > If we have an application where every user can fire a federated search >> > to 25 remote servers, we do need a simple and robust way to cancel >> > incompleted long running jobs, if the user makes a new federated >> > search, logs off prematurely or when the session times out. >> >> This is where I struggle to understand your vision a little bit, and >> maybe I need to revisit the original discussion. But all of what you >> want above can be achieved with the Scheduler module - the Scheduler >> module enables you to immediately Schedule an XQuery for one-shot >> asynchronous execution, it also manages the status of running Queries >> and enables you to cancel long running queries. >> >> >> > >> > >> > >> > ------ >> > >> > Thomas White >> > >> > Mobile:+44 7711 922 966 >> > Skype: thomaswhite >> > gTalk: thomas.0007 >> > Linked-In:http://www.linkedin.com/in/thomaswhite0007 >> > facebook: http://www.facebook.com/thomas.0007 >> > >> > >> > >> > On 2 February 2010 16:15, Andrzej Jan Taramina <an...@ch...> >> > wrote: >> >> >> >> Thomas asked: >> >> >> >> >> do believe, having asynchronous mechanism for fetching data in >> >> >> eXist will >> >> >> > give us foundation for many?interesting new?ideas. >> >> >> > I will need this functionality in about two months time and >> >> >> > I?really hope >> >> >> > somebody from the dev team will be interested in implementing the >> >> >> > execution >> >> >> > pipeline. >> >> >> >> To which Adam replied: >> >> >> >> > I think we will be very pushed for time to meet that deadline. The >> >> > roadmap for the next two versions is already laid out - although it >> >> > is >> >> > subject to change. >> >> >> >> This feature, asynchronous execution of XQueries, is something that I'm >> >> really interested in having as well. >> >> >> >> And I'm willing to implement this within the next two months (probably >> >> sooner than that!). >> >> >> >> I was thinking of a new function along the lines of: >> >> >> >> util:eval-async( ... ) >> >> >> >> which would return some sort of id for the spawned xquery that could be >> >> used to check completion status and obtain the >> >> results of the execution. Same function signatures as the original >> >> util:eval() function to start. >> >> >> >> Would this kind of new function meet your needs as well, Thomas? >> >> >> >> Thoughts from the crew on such a new function? >> >> >> >> >> >> -- >> >> Andrzej Taramina >> >> Chaeron Corporation: Enterprise System Solutions >> >> http://www.chaeron.com >> > >> >> >> >> -- >> Adam Retter >> >> eXist Developer >> { United Kingdom } >> ad...@ex... >> irc://irc.freenode.net/existdb > > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Andrzej J. T. <an...@ch...> - 2010-02-03 16:10:07
|
Thomas: > BTW, is there a way to reduce the number remaining calls for > *schedule-xquery-periodic-job* in run time? > Use case: I need to process a dataset running periodically a XQuery > function that process a chunk of that data. I expect to have 5000 calls > but the data set is smaller this time and I need to cancel it after the > 50th call. Can I do this? If not, I hope we can then extend > *schedule-xquery-periodic-job* function to cancel the job if the > scheduled function returns false(). The easiest way to do that might be to just trigger the first call....and have each call chain to another call (that is, fire another scheduled job to run immediately), if there is data left to process. That way the calls will just keep being initiated until all the data is consumed and processed. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Thomas W. <tho...@gm...> - 2010-02-03 15:47:06
|
Adam, Where shell I start, may be from the fact I was not aware there are new functions in the scheduler. Very lame :-) I guess when you say "one-shot asynchronous execution" you mean using schedule-xquery-periodic-job called with $period=0, and $repeat=1. It seams then I have everything I need to create the batch asynch functionality I described earlier. BTW, is there a way to reduce the number remaining calls for * schedule-xquery-periodic-job* in run time? Use case: I need to process a dataset running periodically a XQuery function that process a chunk of that data. I expect to have 5000 calls but the data set is smaller this time and I need to cancel it after the 50th call. Can I do this? If not, I hope we can then extend *schedule-xquery-periodic-job* function to cancel the job if the scheduled function returns false(). Regards, Thomas ------ Thomas White Mobile:+44 7711 922 966 Skype: thomaswhite gTalk: thomas.0007 Linked-In:http://www.linkedin.com/in/thomaswhite0007 facebook: http://www.facebook.com/thomas.0007 On 3 February 2010 11:18, Adam Retter <ad...@ex...> wrote: > > If we have an application where every user can fire a federated search > > to 25 remote servers, we do need a simple and robust way to cancel > > incompleted long running jobs, if the user makes a new federated > > search, logs off prematurely or when the session times out. > > This is where I struggle to understand your vision a little bit, and > maybe I need to revisit the original discussion. But all of what you > want above can be achieved with the Scheduler module - the Scheduler > module enables you to immediately Schedule an XQuery for one-shot > asynchronous execution, it also manages the status of running Queries > and enables you to cancel long running queries. > > > > > > > > > > ------ > > > > Thomas White > > > > Mobile:+44 7711 922 966 > > Skype: thomaswhite > > gTalk: thomas.0007 > > Linked-In:http://www.linkedin.com/in/thomaswhite0007 > > facebook: http://www.facebook.com/thomas.0007 > > > > > > > > On 2 February 2010 16:15, Andrzej Jan Taramina <an...@ch...> > wrote: > >> > >> Thomas asked: > >> > >> >> do believe, having asynchronous mechanism for fetching data in eXist > will > >> >> > give us foundation for many?interesting new?ideas. > >> >> > I will need this functionality in about two months time and > I?really hope > >> >> > somebody from the dev team will be interested in implementing the > execution > >> >> > pipeline. > >> > >> To which Adam replied: > >> > >> > I think we will be very pushed for time to meet that deadline. The > >> > roadmap for the next two versions is already laid out - although it is > >> > subject to change. > >> > >> This feature, asynchronous execution of XQueries, is something that I'm > really interested in having as well. > >> > >> And I'm willing to implement this within the next two months (probably > sooner than that!). > >> > >> I was thinking of a new function along the lines of: > >> > >> util:eval-async( ... ) > >> > >> which would return some sort of id for the spawned xquery that could be > used to check completion status and obtain the > >> results of the execution. Same function signatures as the original > util:eval() function to start. > >> > >> Would this kind of new function meet your needs as well, Thomas? > >> > >> Thoughts from the crew on such a new function? > >> > >> > >> -- > >> Andrzej Taramina > >> Chaeron Corporation: Enterprise System Solutions > >> http://www.chaeron.com > > > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > |