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: Andrzej J. T. <an...@ch...> - 2010-02-03 14:01:30
|
Elliotte: > I remain amazed that anyone could design a language with dynamic errors and not build in exception handling. I'm not surprised by anything that comes out of W3C anymore. LOL And as Adam mentioned, the next XQuery standard will include a formal try/catch mechanism. Till then, use eXist's util:catch() function. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Adam R. <ad...@ex...> - 2010-02-03 12:08:08
|
On 3 February 2010 10:52, Elliotte Rusty Harold <el...@ib...> wrote: > On Tue, Feb 2, 2010 at 4:46 PM, Andrzej Jan Taramina > <an...@ch...> wrote: > >> There is no stream...it's a string input. So doing a test parse() on it and storing as XML if the parse succeeds, and >> storing as binary if it fails (eg. catch the exception), is pretty trivial. > > Except that standard XQuery 1.0. doesn't have exception handling. I > think there's probably an extension floating around somewhere but I > remain amazed that anyone could design a language with dynamic errors > and not build in exception handling. It will be in XQuery 1.1 :-) http://www.w3.org/TR/xquery-11/#id-try-catch In the meantime eXist provides its own try and catch functions... > -- > Elliotte Rusty Harold > el...@ib... > > ------------------------------------------------------------------------------ > 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 > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Adam R. <ad...@ex...> - 2010-02-03 11:18:47
|
> 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 |
From: Adam R. <ad...@ex...> - 2010-02-03 11:17:12
|
Perhaps it is also interesting to consider the development of a pragma - (# exist:thread #){ (: asynchronous xquery code :) } 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 |
From: Elliotte R. H. <el...@ib...> - 2010-02-03 10:52:23
|
On Tue, Feb 2, 2010 at 4:46 PM, Andrzej Jan Taramina <an...@ch...> wrote: > There is no stream...it's a string input. So doing a test parse() on it and storing as XML if the parse succeeds, and > storing as binary if it fails (eg. catch the exception), is pretty trivial. Except that standard XQuery 1.0. doesn't have exception handling. I think there's probably an extension floating around somewhere but I remain amazed that anyone could design a language with dynamic errors and not build in exception handling. -- Elliotte Rusty Harold el...@ib... |
From: Andrzej J. T. <an...@ch...> - 2010-02-02 21:46:28
|
Evgeny: > I want do it too, but before storing/parsing/reading from stream we are > creating a XML or binary doc for storing content. > Just I don't see how we can do it at one time, because we parsing > directly into out stream. There is no stream...it's a string input. So doing a test parse() on it and storing as XML if the parse succeeds, and storing as binary if it fails (eg. catch the exception), is pretty trivial. I don't see what the technical problem is, at least with the xmldb:store() function. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Thomas W. <tho...@gm...> - 2010-02-02 19:44:21
|
Andrzej, util:eval-async will be close to what I need with one difference - the ability to create a batch of jobs. I believe it is important especially when we scale things up. 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. With batch functions we can combine results (with batch callback function) or get with one command all available data so far from all completed jobs. 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 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 |
From: Andrzej J. T. <an...@ch...> - 2010-02-02 16:15:23
|
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 |
From: Andrzej J. T. <an...@ch...> - 2010-02-02 16:07:32
|
Loren: > I also know of a great place for beer in the Minneapolis/Saint Paul area. A wonderful little brew pub. First round, maybe even two, will be on me at this brew pub of yours! -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Evgeny G. <gaz...@gm...> - 2010-02-02 15:55:10
|
> > > True on all counts. > > Though I wonder if it wouldn't be convenient to try and parse a string if a > mime type is not specified, and if it > parses, then store it as a text/xml document rather than as a binary > document. > > Most binary types, such as base64, zip files and the like, would fail on > the parse very quickly, so it would seem there > wouldn't be much overhead in trying the parse first. Wouldn't be hard to > implement (the old approach actually did this). > I want do it too, but before storing/parsing/reading from stream we are creating a XML or binary doc for storing content. Just I don't see how we can do it at one time, because we parsing directly into out stream. ---------- Evgeny |
From: Loren C. <lor...@gm...> - 2010-02-02 15:54:55
|
On Feb 2, 2010, at 09:39 AM, Andrzej Jan Taramina wrote: > Dannes: > >> Prague is The Place for a good beer... > > I know! I know! > > Unfortunately, I have a family commitment that weekend, and there would be no way to get back in time for that if I went > to Prague. > > Believe me...I wish I could be there. I would be buying a round (or two) for the whole eXist team in appreciation for > all the hard work everyone puts in. > > Maybe next year in Prague! Or in Minneapolis this summer? I also know of a great place for beer in the Minneapolis/Saint Paul area. A wonderful little brew pub. |
From: Andrzej J. T. <an...@ch...> - 2010-02-02 15:44:25
|
Evgeny: > Did you setup a mime-type for? if no the content will be stored as > binary. Before commit > if you will try to store a binary content without mime you will have > exception, > because content will be stored as xml content. Yup...I figured this all out. However, there was no intrinsic mime type, since we were calling the xmldb:store from inside an XQuery which had read the data from an external source. Like I said, I was just surprised that the old behaviour changed is all. > What about XML content not in string but in base64 stream? I agree. That was problematic. > Think if you store XML content not from element() you can use mime -type > "text/xml" as 4th parameter. > But what mime must you setup, for many binary docs, for example when you > trying unzip somewhere into db? True on all counts. Though I wonder if it wouldn't be convenient to try and parse a string if a mime type is not specified, and if it parses, then store it as a text/xml document rather than as a binary document. Most binary types, such as base64, zip files and the like, would fail on the parse very quickly, so it would seem there wouldn't be much overhead in trying the parse first. Wouldn't be hard to implement (the old approach actually did this). Though again, I'm uncertain whether this "convenience" would be a good thing or not. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Andrzej J. T. <an...@ch...> - 2010-02-02 15:39:59
|
Dannes: > Prague is The Place for a good beer... I know! I know! Unfortunately, I have a family commitment that weekend, and there would be no way to get back in time for that if I went to Prague. Believe me...I wish I could be there. I would be buying a round (or two) for the whole eXist team in appreciation for all the hard work everyone puts in. Maybe next year in Prague! Or in Minneapolis this summer? -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Andrzej J. T. <an...@ch...> - 2010-02-02 15:32:05
|
Adam: > Or you could call util:parse to convert your xs:string into a node() Funny thing is that our code actually did parse the incoming data (comes from an external file, generated by an external system) for other reasons, but the store used the string value rather than the already parsed node() value. All I can say is that this code is a few years old and hasn't been looked at in some time. That's my excuse and I'm sticking to it. ;-) I changed our application code to use the parsed node() for the xmldb:store() this morning, since it will perform better, avoiding the duplicate parsing that eXist would do. This particular routine of ours is used a lot to import data every night, so it made sense to implement this small optimization. Thanks for the comment Adam....made our code better/faster as a result! -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Evgeny G. <gaz...@gm...> - 2010-02-02 15:28:34
|
Offtop! Todays trigger's events is not implemented as well. Suggest discus the one important features too - new triggers events. Who don't know what is it - look: /branches/gev/triggers/eXist. -------- Evgeny |
From: Andrzej J. T. <an...@ch...> - 2010-02-02 15:24:52
|
Wolfgang: > The log file should be cleared by the next checkpoint, which should at > least occur during shutdown, if not before. Is there any way to force a checkpoint? Admin task? XQuery function? The reason I ask is that it would be a useful thing to be able to force a checkpoint to happen after a huge bulk store operation, thus guaranteeing that the database is in a good state and fully optimized before you attempt a shutdown. If there isn't such a method, do you think that it would be useful to add an XQuery function (maybe in the system namespece) or this capability to the admin (web and java) clients? If so, then I'ld be happy to add this capability, if you point me in the general direction of how to initiate a checkpoint (eg, what class/method to call in Java). Thx! -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Dannes W. <di...@ex...> - 2010-02-02 15:23:17
|
Hi, On Tue, Feb 2, 2010 at 3:55 PM, Andrzej Jan Taramina <an...@ch...>wrote: > I owe you a good beer for this! > Prague is The Place for a good beer... D. -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Evgeny G. <gaz...@gm...> - 2010-02-02 15:12:17
|
2010/2/2 Andrzej Jan Taramina <an...@ch...> > It used to be that if you did an: > > xmldb:store( $col, $doc, $content ) > > where $content was a string, but an XML string, store() would store the > document as XML, not as a binary document. > > Now it seems that if you do such a store, even though the $content string > is valid XML it now stores the document as a > binary document. > > Looks like Gev checked in a change on the 30th that broke the existing > behaviour. > > I'm not convinced that the prior behaviour was a bug when you were passing > in a string that was in fact XML. But I've > changed my code to pass in a mimetype parameter in our situation to resolve > this. > > Did you setup a mime-type for? if no the content will be stored as binary. Before commit if you will try to store a binary content without mime you will have exception, because content will be stored as xml content. What about XML content not in string but in base64 stream? Think if you store XML content not from element() you can use mime -type "text/xml" as 4th parameter. But what mime must you setup, for many binary docs, for example when you trying unzip somewhere into db? ---- Evgeny |
From: Andrzej J. T. <an...@ch...> - 2010-02-02 14:59:07
|
Wolfgang: > The idea was that if you pass in a string without specifying a > mime-type, the function would store it as a binary resource instead of > trying to parse it as XML. Evgeny explained this to me before his > commit and I agreed it would make the function more consistent. We may > be wrong though. I don't think it's wrong...in fact, I do believe that it makes the code more "consistent". It was just a surprise that this behaviour changed, which broke our code, after quite a number of years of it working correctly is all. I'm just glad I caught it before we did a deployment in a real environment. As a convenience, it might be useful to try and parse the string and if it parses then store it as xml. Though I'm not really sure on this. In any case, it would probably be useful to clarify the behaviour a bit better in the function documentation so that others don't trip over this. Just came as a surprise is all... -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Andrzej J. T. <an...@ch...> - 2010-02-02 14:56:06
|
Wolfgang: > Found it. The issue was introduced by rev 11074 on January 24. The > code acquires a DBBroker instance without releasing it afterwards > (this is a fatal violation of the internal API). Many, many huge thanks for finding and fixing this one! Saves me from reverting both eXIst and out application code. I owe you a good beer for this! > Please remember that the *only* way to call BrokerPool.get() should be > within a try-finally with a call to BrokerPool.release() in the > finally clause. Noted for the future, though it wasn't moi that made that change. -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Adam R. <ad...@ex...> - 2010-02-02 13:13:27
|
Not at all - all comments are always welcome :-) I just wanted you to understand that each new feature is something else for the core team to maintain should the contributor then disappear. This can be difficult, especially if the feature is not understood or been discussed. Please do comment in future. Cheers Adam. On 2 February 2010 12:53, Thomas White <tho...@gm...> wrote: > Adam, > > All points you make are both valid and important. I agree it is vital to > know when to listen and when (not) to talk, especially when one > misunderstands completely the context of the conversation. > > Please accept my apologies for butting in. > > Thomas > > On 2 February 2010 09:58, Adam Retter <ad...@ex...> wrote: >> >> On 1 February 2010 19:34, Thomas White <tho...@gm...> wrote: >> > I hope this will be taken in the best possible way. >> > >> > I could never understand why a functionality that is used by some >> > users could be proposed to be removed by other users either who don't >> > use it >> > or don't like it. >> > >> > If something have got a momentum it should stay. It is there, it does >> > not >> > require any additional resources and brings other routes to more >> > solutions. >> >> This is not how good software is built, but more importantly its not >> how it is maintained. We have had plenty of contributions in the past, >> some of excellent quality and some of not. But if we just allowed >> anyone to add anything we would end up with a mess, everyone thinks >> eXist should be something different, at present it is a lot of >> different things to different people - but the core team tries not to >> dilute the product too much. Maintainability is also a huge issue for >> us. Basically we like features to be discussed by the core team. >> >> -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Thomas W. <tho...@gm...> - 2010-02-02 12:53:41
|
Adam, All points you make are both valid and important. I agree it is vital to know when to listen and when (not) to talk, especially when one misunderstands completely the context of the conversation. Please accept my apologies for butting in. Thomas On 2 February 2010 09:58, Adam Retter <ad...@ex...> wrote: > On 1 February 2010 19:34, Thomas White <tho...@gm...> wrote: > > I hope this will be taken in the best possible way. > > > > I could never understand why a functionality that is used by some > > users could be proposed to be removed by other users either who don't use > it > > or don't like it. > > > > If something have got a momentum it should stay. It is there, it does not > > require any additional resources and brings other routes to more > solutions. > > This is not how good software is built, but more importantly its not > how it is maintained. We have had plenty of contributions in the past, > some of excellent quality and some of not. But if we just allowed > anyone to add anything we would end up with a mess, everyone thinks > eXist should be something different, at present it is a lot of > different things to different people - but the core team tries not to > dilute the product too much. Maintainability is also a huge issue for > us. Basically we like features to be discussed by the core team. > > > |
From: Wolfgang M. <wol...@ex...> - 2010-02-02 11:11:25
|
> Now it seems that if you do such a store, even though the $content string is valid XML it now stores the > document as a binary document. > > Looks like Gev checked in a change on the 30th that broke the existing behaviour. The idea was that if you pass in a string without specifying a mime-type, the function would store it as a binary resource instead of trying to parse it as XML. Evgeny explained this to me before his commit and I agreed it would make the function more consistent. We may be wrong though. Wolfgang |
From: Dannes W. <di...@ex...> - 2010-02-02 11:05:20
|
Do we have junit tests to 'lock' the behaviour? no? gev? D. On Tue, Feb 2, 2010 at 11:20 AM, Adam Retter <ad...@ex...> wrote: > Or you could call util:parse to convert your xs:string into a node() > > On 2 February 2010 01:00, Andrzej Jan Taramina <an...@ch...> > wrote: > > It used to be that if you did an: > > > > xmldb:store( $col, $doc, $content ) > > > > where $content was a string, but an XML string, store() would store the > document as XML, not as a binary document. > > > > Now it seems that if you do such a store, even though the $content string > is valid XML it now stores the document as a > > binary document. > > > > Looks like Gev checked in a change on the 30th that broke the existing > behaviour. > > > > I'm not convinced that the prior behaviour was a bug when you were > passing in a string that was in fact XML. But I've > > changed my code to pass in a mimetype parameter in our situation to > resolve this. > > > > -- > > Andrzej Taramina > > Chaeron Corporation: Enterprise System Solutions > > http://www.chaeron.com > > > > > ------------------------------------------------------------------------------ > > 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 > > > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > > > ------------------------------------------------------------------------------ > 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: Wolfgang M. <wol...@ex...> - 2010-02-02 10:58:06
|
Found it. The issue was introduced by rev 11074 on January 24. The code acquires a DBBroker instance without releasing it afterwards (this is a fatal violation of the internal API). Please remember that the *only* way to call BrokerPool.get() should be within a try-finally with a call to BrokerPool.release() in the finally clause. Wolfgang |