Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(31) |
Nov
(25) |
Dec
(33) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(48) |
Feb
(62) |
Mar
(22) |
Apr
(29) |
May
(9) |
Jun
(45) |
Jul
(28) |
Aug
(41) |
Sep
(60) |
Oct
(96) |
Nov
(99) |
Dec
(70) |
2003 |
Jan
(98) |
Feb
(159) |
Mar
(164) |
Apr
(150) |
May
(143) |
Jun
(97) |
Jul
(184) |
Aug
(143) |
Sep
(207) |
Oct
(126) |
Nov
(159) |
Dec
(165) |
2004 |
Jan
(131) |
Feb
(229) |
Mar
(220) |
Apr
(212) |
May
(320) |
Jun
(223) |
Jul
(191) |
Aug
(390) |
Sep
(261) |
Oct
(229) |
Nov
(215) |
Dec
(184) |
2005 |
Jan
(221) |
Feb
(312) |
Mar
(336) |
Apr
(273) |
May
(359) |
Jun
(277) |
Jul
(303) |
Aug
(321) |
Sep
(256) |
Oct
(415) |
Nov
(428) |
Dec
(508) |
2006 |
Jan
(585) |
Feb
(419) |
Mar
(496) |
Apr
(296) |
May
(403) |
Jun
(404) |
Jul
(553) |
Aug
(296) |
Sep
(252) |
Oct
(416) |
Nov
(414) |
Dec
(245) |
2007 |
Jan
(354) |
Feb
(422) |
Mar
(389) |
Apr
(298) |
May
(397) |
Jun
(318) |
Jul
(315) |
Aug
(339) |
Sep
(253) |
Oct
(317) |
Nov
(350) |
Dec
(264) |
2008 |
Jan
(353) |
Feb
(313) |
Mar
(433) |
Apr
(383) |
May
(343) |
Jun
(355) |
Jul
(321) |
Aug
(338) |
Sep
(242) |
Oct
(206) |
Nov
(199) |
Dec
(279) |
2009 |
Jan
(327) |
Feb
(221) |
Mar
(280) |
Apr
(278) |
May
(237) |
Jun
(345) |
Jul
(322) |
Aug
(324) |
Sep
(676) |
Oct
(586) |
Nov
(735) |
Dec
(329) |
2010 |
Jan
(619) |
Feb
(424) |
Mar
(529) |
Apr
(241) |
May
(312) |
Jun
(554) |
Jul
(698) |
Aug
(576) |
Sep
(408) |
Oct
(268) |
Nov
(391) |
Dec
(426) |
2011 |
Jan
(629) |
Feb
(512) |
Mar
(465) |
Apr
(467) |
May
(475) |
Jun
(403) |
Jul
(426) |
Aug
(542) |
Sep
(418) |
Oct
(620) |
Nov
(614) |
Dec
(358) |
2012 |
Jan
(357) |
Feb
(466) |
Mar
(344) |
Apr
(215) |
May
(408) |
Jun
(375) |
Jul
(241) |
Aug
(260) |
Sep
(401) |
Oct
(461) |
Nov
(498) |
Dec
(294) |
2013 |
Jan
(453) |
Feb
(447) |
Mar
(434) |
Apr
(326) |
May
(295) |
Jun
(471) |
Jul
(463) |
Aug
(278) |
Sep
(525) |
Oct
(343) |
Nov
(389) |
Dec
(405) |
2014 |
Jan
(564) |
Feb
(324) |
Mar
(319) |
Apr
(319) |
May
(384) |
Jun
(259) |
Jul
(210) |
Aug
(219) |
Sep
(315) |
Oct
(478) |
Nov
(207) |
Dec
(316) |
2015 |
Jan
(222) |
Feb
(234) |
Mar
(201) |
Apr
(145) |
May
(367) |
Jun
(318) |
Jul
(195) |
Aug
(210) |
Sep
(234) |
Oct
(248) |
Nov
(217) |
Dec
(189) |
2016 |
Jan
(219) |
Feb
(177) |
Mar
(110) |
Apr
(91) |
May
(159) |
Jun
(124) |
Jul
(192) |
Aug
(119) |
Sep
(125) |
Oct
(64) |
Nov
(80) |
Dec
(68) |
2017 |
Jan
(156) |
Feb
(312) |
Mar
(386) |
Apr
(217) |
May
(89) |
Jun
(115) |
Jul
(79) |
Aug
(122) |
Sep
(100) |
Oct
(99) |
Nov
(129) |
Dec
(77) |
2018 |
Jan
(106) |
Feb
(78) |
Mar
(160) |
Apr
(59) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
1
(2) |
2
(3) |
3
(12) |
4
(9) |
5
(14) |
6
|
7
(1) |
8
(17) |
9
(18) |
10
(34) |
11
(15) |
12
(1) |
13
|
14
(6) |
15
(9) |
16
(25) |
17
(28) |
18
(17) |
19
(22) |
20
(11) |
21
(11) |
22
(9) |
23
(21) |
24
(18) |
25
(12) |
26
(8) |
27
(1) |
28
(1) |
29
(8) |
30
(12) |
|
|
|
|
From: Adam Retter <adam@ex...> - 2009-06-30 19:37:48
|
So you want created if modified does not exist? Well depending on the structure of your data, there are a couple of options... If your 'Dates' element always has just 'created' and/or 'modified' dates in the order you describe, then you could use - let $find-year := 1999 return count( /Dates/Date[last()][year-from-date(@value) eq $find-year] ) Otherwise, if you need to be more specific because your 'Dates' element structure is more complex than you describe here (assuming that modified always follows created) - let $find-year := 1999 return count( /Dates/Date[@type = ('modified','created')][last()][year-from-date(@value) eq $find-year] ) Cheers Adam. 2009/6/30 PencilEd <gstewart@...>: > > I may have 2 resources with the following 'Dates' > > 1) > <Dates> > <Date type='created' value='2008-03-05'> > <Date type='modified' value='2009-01-10'> > </Dates> > > 2) > <Dates> > <Date type='created' value='2008-02-12'> > </Dates> > > I'm wanting to get a count of the records modified in a given year - of > course... if no Date of type='modified' exists then the Date of > type='created' should be counted. > > So - the 2 records above would give 1 for 2008 (#2) and 1 for 2009 (#1, > since it was last modified in 2009). > > I'm using the following: > > {count(collection($my_collection)/Dates/Date[@type = > 'created']/@value[year-from-date(.) >= $year and year-from-date(.) < $year + > 1])} > > Is there a way to do something like [@type = {if exists(@type = 'modified') > then 'modified' else 'created'}]? > -- > View this message in context: http://www.nabble.com/Predicate-change-if-attribute-exists...--tp24276541p24276541.html > Sent from the exist-open mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Exist-open mailing list > Exist-open@... > https://lists.sourceforge.net/lists/listinfo/exist-open > -- Adam Retter eXist Developer { United Kingdom } adam@... irc://irc.freenode.net/existdb |
From: Wolfgang <wolfgang@ex...> - 2009-06-30 18:21:00
|
> I am importing a very large XML document, and have set the VM to -Xms and > -Xmx to 1 GB. Running the VM with -verbosegc, I notice that VM is doing > repetitive garbage collections when the heap reaches 800 MB, 200 MB short of > the 1 GB I set. I thought I removed the call to System.gc, but obviously I did not. Or did I reintroduce it? I forgot, sorry. Normally you would expect Java to trigger a major gc before it runs out of memory, so the call should not be required. But you never know. Well, I would suggest to comment out the call to System.gc and see if the system runs stable or not. If yes, we should consider removing it in trunk as well. The checkAvailableMemory is called because eXist will use the entire free memory to buffer index entries before it flushes them to the actual index. This is not affected by the cacheSize setting in conf.xml (or at least only indirectly). The cacheSize setting controls how much *permanent* cache space will be used, while the indexing process may use additional memory if available. > Is this an indication that I need to increase the cacheSize setting (which I > still have at 48 MB)? No, though 48M cacheSize is really small if you need to store larger documents. I would recommend to carefully increase cacheSize to 128M or so (but always less than 1/3 of the main memory). Wolfgang |
From: James Fuller <james.fuller.2007@gm...> - 2009-06-30 18:18:09
|
are u using java client ? can u clarify how you are importing ? Jim Fuller On Tue, Jun 30, 2009 at 7:38 PM, Alessandro Vernet<avernet@...> wrote: > > I am importing a very large XML document, and have set the VM to -Xms and > -Xmx to 1 GB. Running the VM with -verbosegc, I notice that VM is doing > repetitive garbage collections when the heap reaches 800 MB, 200 MB short of > the 1 GB I set. Surprised by this behavior, I did a few thread dumps while > the import was running, and it seems that those full GCs are forced by > eXist: > > "http-8080-Processor23" daemon prio=5 tid=0x00235910 nid=0x845e00 runnable > [0xb20b2000..0xb20b2d90] > at java.lang.Runtime.gc(Native Method) > at java.lang.System.gc(System.java:891) > at > org.exist.storage.NativeBroker.checkAvailableMemory(NativeBroker.java:2932) > at org.exist.storage.NativeBroker.storeNode(NativeBroker.java:2381) > at org.exist.storage.DBBroker.storeNode(DBBroker.java:503) > > Is this an indication that I need to increase the cacheSize setting (which I > still have at 48 MB)? Can increasing it too much lead to out of memory > errors? Since eXist is forcing a full GC short of 200 MB before reaching the > 1 GB max heap size, should I consider increasing cacheSize by close to 200 > MB (say 150 MB, to be on the safe side)? > > Ideally, I'd like eXist to automagically use as much memory as possible for > the cache, up to the max heap size, and free some of the memory used by the > cache on full garbage collection (sort of what weak references are promised > to offer). But maybe this isn't realistic? > > Alex > > ----- > Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise > Orbeon's Blog: http://www.orbeon.com/blog/ > Personal Blog: http://avernet.blogspot.com/ > Twitter - http://twitter.com/avernet > -- > View this message in context: http://www.nabble.com/eXist-forcing-full-GC-before-heap-full--tp24276360p24276360.html > Sent from the exist-open mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Exist-open mailing list > Exist-open@... > https://lists.sourceforge.net/lists/listinfo/exist-open > |
From: PencilEd <gstewart@lc...> - 2009-06-30 17:49:46
|
I may have 2 resources with the following 'Dates' 1) <Dates> <Date type='created' value='2008-03-05'> <Date type='modified' value='2009-01-10'> </Dates> 2) <Dates> <Date type='created' value='2008-02-12'> </Dates> I'm wanting to get a count of the records modified in a given year - of course... if no Date of type='modified' exists then the Date of type='created' should be counted. So - the 2 records above would give 1 for 2008 (#2) and 1 for 2009 (#1, since it was last modified in 2009). I'm using the following: {count(collection($my_collection)/Dates/Date[@type = 'created']/@value[year-from-date(.) >= $year and year-from-date(.) < $year + 1])} Is there a way to do something like [@type = {if exists(@type = 'modified') then 'modified' else 'created'}]? -- View this message in context: http://www.nabble.com/Predicate-change-if-attribute-exists...--tp24276541p24276541.html Sent from the exist-open mailing list archive at Nabble.com. |
From: Glen Bremner-Stokes <glen@op...> - 2009-06-30 17:45:19
|
Not sure if this is the correct list. Some user feedback: Just installed 1.3 preview on Vista using the binary and got the following install log. "JAVA_HOME: C:\Program Files\Java\jdk1.6.0_13" "EXIST_HOME: C:\exist" WARN: The following JAR file entries from 'org/exist/start/start.config' aren't available (this may NOT be a problem): C:\exist\test\classes --- Starting embedded database instance --- Caught an exception while initializing db: Can not access to local database instance org.xmldb.api.base.XMLDBException: Can not access to local database instance at org.exist.xmldb.DatabaseImpl.getLocalCollection(DatabaseImpl.java:183) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:155) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:150) at org.xmldb.api.DatabaseManager.getCollection(Unknown Source) at org.exist.Setup.initDb(Setup.java:57) at org.exist.Setup.main(Setup.java:46) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.exist.start.Main.invokeMain(Main.java:128) at org.exist.start.Main.run(Main.java:405) at org.exist.start.Main.main(Main.java:59) Caused by: org.exist.EXistException: database instance 'exist' is not available at org.exist.storage.BrokerPool.getInstance(BrokerPool.java:286) at org.exist.xmldb.DatabaseImpl.getLocalCollection(DatabaseImpl.java:181) ... 12 more [B@...: database instance 'exist' is not available at org.exist.storage.BrokerPool.getInstance(BrokerPool.java:286) at org.exist.xmldb.DatabaseImpl.getLocalCollection(DatabaseImpl.java:181) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:155) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:150) at org.xmldb.api.DatabaseManager.getCollection(Unknown Source) at org.exist.Setup.initDb(Setup.java:57) at org.exist.Setup.main(Setup.java:46) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.exist.start.Main.invokeMain(Main.java:128) at org.exist.start.Main.run(Main.java:405) at org.exist.start.Main.main(Main.java:59) Caused by: org.exist.EXistException: database instance 'exist' is not available at org.exist.storage.BrokerPool.getInstance(BrokerPool.java:286) at org.exist.xmldb.DatabaseImpl.getLocalCollection(DatabaseImpl.java:181) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:155) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:150) at org.xmldb.api.DatabaseManager.getCollection(Unknown Source) at org.exist.Setup.initDb(Setup.java:57) at org.exist.Setup.main(Setup.java:46) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) --- Initialization complete. Shutdown embedded database instance --- at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.exist.start.Main.invokeMain(Main.java:128) at org.exist.start.Main.run(Main.java:405) at org.exist.start.Main.main(Main.java:59) File lock last access timestamp: 30-Jun-2009 C:\exist\webapp\WEB-INF\data\dbx_dir.lck Waiting a short time for the lock to be released... C:\exist\webapp\WEB-INF\data\dbx_dir.lck File lock last access timestamp: 30-Jun-2009 C:\exist\webapp\WEB-INF\data\dbx_dir.lck Found a stale lockfile. Trying to remove it: C:\exist\webapp\WEB-INF\data\dbx_dir.lck Caught an exception while initializing db: Can not access to local database instance org.xmldb.api.base.XMLDBException: Can not access to local database instance at org.exist.xmldb.DatabaseImpl.getLocalCollection(DatabaseImpl.java:183) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:155) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:150) at org.xmldb.api.DatabaseManager.getCollection(Unknown Source) at org.exist.Setup.shutdown(Setup.java:73) at org.exist.Setup.main(Setup.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.exist.start.Main.invokeMain(Main.java:128) at org.exist.start.Main.run(Main.java:405) at org.exist.start.Main.main(Main.java:59) Caused by: org.exist.EXistException: database instance 'exist' is not available at org.exist.storage.BrokerPool.getInstance(BrokerPool.java:286) at org.exist.xmldb.DatabaseImpl.getLocalCollection(DatabaseImpl.java:181) ... 12 more [B@...: database instance 'exist' is not available at org.exist.storage.BrokerPool.getInstance(BrokerPool.java:286) at org.exist.xmldb.DatabaseImpl.getLocalCollection(DatabaseImpl.java:181) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:155) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:150) at org.xmldb.api.DatabaseManager.getCollection(Unknown Source) at org.exist.Setup.shutdown(Setup.java:73) at org.exist.Setup.main(Setup.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.exist.start.Main.invokeMain(Main.java:128) at org.exist.start.Main.run(Main.java:405) at org.exist.start.Main.main(Main.java:59) Caused by: org.exist.EXistException: database instance 'exist' is not available at org.exist.storage.BrokerPool.getInstance(BrokerPool.java:286) at org.exist.xmldb.DatabaseImpl.getLocalCollection(DatabaseImpl.java:181) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:155) at org.exist.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:150) at org.xmldb.api.DatabaseManager.getCollection(Unknown Source) at org.exist.Setup.shutdown(Setup.java:73) at org.exist.Setup.main(Setup.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.exist.start.Main.invokeMain(Main.java:128) at org.exist.start.Main.run(Main.java:405) at org.exist.start.Main.main(Main.java:59) |
From: Alessandro Vernet <avernet@sc...> - 2009-06-30 17:38:11
|
I am importing a very large XML document, and have set the VM to -Xms and -Xmx to 1 GB. Running the VM with -verbosegc, I notice that VM is doing repetitive garbage collections when the heap reaches 800 MB, 200 MB short of the 1 GB I set. Surprised by this behavior, I did a few thread dumps while the import was running, and it seems that those full GCs are forced by eXist: "http-8080-Processor23" daemon prio=5 tid=0x00235910 nid=0x845e00 runnable [0xb20b2000..0xb20b2d90] at java.lang.Runtime.gc(Native Method) at java.lang.System.gc(System.java:891) at org.exist.storage.NativeBroker.checkAvailableMemory(NativeBroker.java:2932) at org.exist.storage.NativeBroker.storeNode(NativeBroker.java:2381) at org.exist.storage.DBBroker.storeNode(DBBroker.java:503) Is this an indication that I need to increase the cacheSize setting (which I still have at 48 MB)? Can increasing it too much lead to out of memory errors? Since eXist is forcing a full GC short of 200 MB before reaching the 1 GB max heap size, should I consider increasing cacheSize by close to 200 MB (say 150 MB, to be on the safe side)? Ideally, I'd like eXist to automagically use as much memory as possible for the cache, up to the max heap size, and free some of the memory used by the cache on full garbage collection (sort of what weak references are promised to offer). But maybe this isn't realistic? Alex ----- Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise Orbeon's Blog: http://www.orbeon.com/blog/ Personal Blog: http://avernet.blogspot.com/ Twitter - http://twitter.com/avernet -- View this message in context: http://www.nabble.com/eXist-forcing-full-GC-before-heap-full--tp24276360p24276360.html Sent from the exist-open mailing list archive at Nabble.com. |
From: Frey, Anthony - OJA <Anthony.Frey@wi...> - 2009-06-30 15:06:52
|
We started receiving this same exception after we recently upgraded from 1.2.5 to 1.3dev in our test environment. I believe the problem stems from the reset method getting invoked on the watch dog of the top-level context instead of the context itself. This becomes a problem when executing queries that import modules. The context will iterate through nested contexts and reset them but the watch dog does not so basically the timer continues to run on module contexts. You can read my original post on the problem here: http://sourceforge.net/mailarchive/forum.php?thread_name=1B700CF271115444B0DFCBFD2CA234AC56E14F620C%40MEWMAD0PC01G01.accounts.wistate.us&forum_name=exist-open I patched our eXist locally simply by changing the reset method invocation like this: org.exist.xquery.XQuery: 217: // context.getWatchDog().reset(); 218: context.reset() This fixed the problem for us. However, I don't yet fully understand the dependencies between contexts and modules so I'm not sure if this is correct and won't cause other issues. If any other developers could validate this that would be great. Thanks, --Tony ------------------------------ Message: 6 Date: Tue, 30 Jun 2009 08:05:49 -0400 From: "Michael Sokolov" <sokolov@...> Subject: Re: [Exist-open] query timeout bug To: "'Andrew Hart CEMS Staff'" <Andrew2.Hart@...>, "'exist'" <exist-open@...> Message-ID: <200906301147.n5UBlaKJ001264@...> Content-Type: text/plain; charset="us-ascii" I had a similar issue (1.3-dev version on linux). Queries would randomly die immediately, with the message that they had taken too long: sorry don't have the details, but it really did sound like they had been killed explicitly by the watchdog. I had set the watchdog timer to 30 seconds. -Mike > -----Original Message----- > From: Andrew Hart CEMS Staff [mailto:Andrew2.Hart@...] > Sent: Tuesday, June 30, 2009 6:03 AM > To: exist > Subject: [Exist-open] query timeout bug > > I recently tried to use > - query-timeout > this attribute sets the maximum amount of > time (expressed in > milliseconds) that the query can take before > it is killed.. > from conf.xml to limit queries to 5 minutes or less. This > was because some of our scripts get data from an external > source through a proxy, either of which can take forever to > respond...Anyway it worked well apart from the fact that it > randomly kills xqueries immediately (and gives the query > timed out error). > > Anyone else get this? I am on Solaris 10 java 1.5.0_01 eXist says > 8849-20090416 but this may be wrong as I have to remember to > type it in before build.sh > > I am asking because it could be something local - like our > http proxy - causing the problem. > |
From: Andrew Hart CEMS Staff <Andrew2.Hart@uw...> - 2009-06-30 14:22:26
|
OK I reproduced it in 9181 too The query exceeded the predefined timeout and has been killed.stattime: 1246370822671 elapsed: 573785 It seems if you click around a bit and then wait a good while then your next click gets the error. from the log 2009-06-30 15:16:36,468 [P1-9] WARN (XQueryWatchDog.java [proceed]:123) - Query exceeded predefined timeout (573,785 ms.): 2009-06-30 15:16:36,472 [P1-9] DEBUG (RESTServer.java [doGet]:428) - The query exceeded the predefined timeout and has been killed.1246370822671 elapsed: 573785 [at line 14, column 2] In call to function: ui:pageHeader(item()*) [36:18] org.exist.xquery.TerminatedException$TimeoutException: The query exceeded the predefined timeout and has been killed.1246370 822671 elapsed: 573785 [at line 14, column 2] In call to function: ui:pageHeader(item()*) [36:18] at org.exist.xquery.XQueryWatchDog.proceed(XQueryWatchDog.java:126) at org.exist.xquery.XQueryWatchDog.proceed(XQueryWatchDog.java:132) at org.exist.xquery.XQueryContext.proceed(XQueryContext.java:1817) at org.exist.xquery.ElementConstructor.eval(ElementConstructor.java:219) at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:60) at org.exist.xquery.PathExpr.eval(PathExpr.java:249) at org.exist.xquery.UserDefinedFunction.eval(UserDefinedFunction.java:133) at org.exist.xquery.DynamicCardinalityCheck.eval(DynamicCardinalityCheck.java:71) at org.exist.xquery.DynamicTypeCheck.eval(DynamicTypeCheck.java:61) at org.exist.xquery.FunctionCall.evalFunction(FunctionCall.java:268) at org.exist.xquery.FunctionCall.eval(FunctionCall.java:201) at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:60) at org.exist.xquery.PathExpr.eval(PathExpr.java:249) at org.exist.xquery.EnclosedExpr.eval(EnclosedExpr.java:70) at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:60) at org.exist.xquery.PathExpr.eval(PathExpr.java:249) at org.exist.xquery.ElementConstructor.eval(ElementConstructor.java:266) at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:60) at org.exist.xquery.PathExpr.eval(PathExpr.java:249) at org.exist.xquery.ElementConstructor.eval(ElementConstructor.java:266) at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:60) at org.exist.xquery.PathExpr.eval(PathExpr.java:249) at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:60) at org.exist.xquery.LetExpr.eval(LetExpr.java:205) at org.exist.xquery.LetExpr.eval(LetExpr.java:203) at org.exist.xquery.LetExpr.eval(LetExpr.java:203) at org.exist.xquery.LetExpr.eval(LetExpr.java:203) at org.exist.xquery.BindingExpression.eval(BindingExpression.java:158) at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:60) at org.exist.xquery.PathExpr.eval(PathExpr.java:249) at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:60) at org.exist.xquery.XQuery.execute(XQuery.java:226) at org.exist.xquery.XQuery.execute(XQuery.java:188) at org.exist.http.RESTServer.executeXQuery(RESTServer.java:1178) at org.exist.http.RESTServer.doGet(RESTServer.java:424) at org.exist.http.servlets.EXistServlet.doGet(EXistServlet.java:323) at javax.servlet.http.HttpServlet.service(HttpServlet.java:743) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.exist.http.urlrewrite.PassThrough.doRewrite(PassThrough.java:44) at org.exist.http.urlrewrite.XQueryURLRewrite.doFilter(XQueryURLRewrite.java:337) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:820) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:837) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:245) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Michael Sokolov wrote: > I had a similar issue (1.3-dev version on linux). Queries would randomly > die immediately, with the message that they had taken too long: sorry don't > have the details, but it really did sound like they had been killed > explicitly by the watchdog. I had set the watchdog timer to 30 seconds. > > -Mike > > >> -----Original Message----- >> From: Andrew Hart CEMS Staff [mailto:Andrew2.Hart@...] >> Sent: Tuesday, June 30, 2009 6:03 AM >> To: exist >> Subject: [Exist-open] query timeout bug >> >> I recently tried to use >> - query-timeout >> this attribute sets the maximum amount of >> time (expressed in >> milliseconds) that the query can take before >> it is killed.. >> from conf.xml to limit queries to 5 minutes or less. This >> was because some of our scripts get data from an external >> source through a proxy, either of which can take forever to >> respond...Anyway it worked well apart from the fact that it >> randomly kills xqueries immediately (and gives the query >> timed out error). >> >> Anyone else get this? I am on Solaris 10 java 1.5.0_01 eXist says >> 8849-20090416 but this may be wrong as I have to remember to >> type it in before build.sh >> >> I am asking because it could be something local - like our >> http proxy - causing the problem. >> >> >> This email was independently scanned for viruses by McAfee >> anti-virus software and none were found >> -------------------------------------------------------------- >> ---------------- >> _______________________________________________ >> Exist-open mailing list >> Exist-open@... >> https://lists.sourceforge.net/lists/listinfo/exist-open >> >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Exist-open mailing list > Exist-open@... > https://lists.sourceforge.net/lists/listinfo/exist-open > > > This incoming email to UWE has been independently scanned for viruses by McAfee anti-virus software and none were detected > > This email was independently scanned for viruses by McAfee anti-virus software and none were found |
From: Michael Sokolov <sokolov@if...> - 2009-06-30 12:05:43
|
I had a similar issue (1.3-dev version on linux). Queries would randomly die immediately, with the message that they had taken too long: sorry don't have the details, but it really did sound like they had been killed explicitly by the watchdog. I had set the watchdog timer to 30 seconds. -Mike > -----Original Message----- > From: Andrew Hart CEMS Staff [mailto:Andrew2.Hart@...] > Sent: Tuesday, June 30, 2009 6:03 AM > To: exist > Subject: [Exist-open] query timeout bug > > I recently tried to use > - query-timeout > this attribute sets the maximum amount of > time (expressed in > milliseconds) that the query can take before > it is killed.. > from conf.xml to limit queries to 5 minutes or less. This > was because some of our scripts get data from an external > source through a proxy, either of which can take forever to > respond...Anyway it worked well apart from the fact that it > randomly kills xqueries immediately (and gives the query > timed out error). > > Anyone else get this? I am on Solaris 10 java 1.5.0_01 eXist says > 8849-20090416 but this may be wrong as I have to remember to > type it in before build.sh > > I am asking because it could be something local - like our > http proxy - causing the problem. > > > This email was independently scanned for viruses by McAfee > anti-virus software and none were found > -------------------------------------------------------------- > ---------------- > _______________________________________________ > Exist-open mailing list > Exist-open@... > https://lists.sourceforge.net/lists/listinfo/exist-open > |
From: Thomas White <thomas.0007@gm...> - 2009-06-30 10:04:12
|
Adam, I think I have a better idea than what I wrote last night. At the moment if a file is of unknown MIME type it is assumed it should be well formed and it is parsed before it is saved into the db. I believe then the most common case is - the unknown file is binary and we just save it. This way we can save into the db anything we like, without need to update mime-types.xml. BTW, I have an idea to allow xdb:store-files-from-pattern to filter the imported files agianst the file timestamp: $recent-only as xs:boolean - when this parameter is true, then only the files that have a timestamp recent then timestamp of the corresponding the resource are imported. New files that do not exist in the db are procesed as well. This functinality could be especially useful when we have large number of files to be imported like JavaScript, CSS or configuration XML files and only few of them have been changed recently. I hope this will help. Thomas > You would set the mime type in the mime-types.xml file in EXIST_HOME - > changes to this do require a restart. > > However looking in mime-types.xml I can see we already have a > definition for application/x-javascript - so perhaps that is the > mime-type you need? > > Thanks Adam. |
From: Andrew Hart CEMS Staff <Andrew2.Hart@uw...> - 2009-06-30 10:03:44
|
I recently tried to use - query-timeout this attribute sets the maximum amount of time (expressed in milliseconds) that the query can take before it is killed.. from conf.xml to limit queries to 5 minutes or less. This was because some of our scripts get data from an external source through a proxy, either of which can take forever to respond...Anyway it worked well apart from the fact that it randomly kills xqueries immediately (and gives the query timed out error). Anyone else get this? I am on Solaris 10 java 1.5.0_01 eXist says 8849-20090416 but this may be wrong as I have to remember to type it in before build.sh I am asking because it could be something local - like our http proxy - causing the problem. This email was independently scanned for viruses by McAfee anti-virus software and none were found |
From: Wolfgang Meier <wolfgang@ex...> - 2009-06-30 08:33:39
|
> I would like to propose a small extension in the logic of how > XQueryURLRewrite finds the file with redirection rules. > The idea is to search for controller.xql first in the sub-directories > matching the URL structure and if not such file is found then execute the > main webapp/controller.xql. I implemented your proposal in rev 9247. XQueryURLRewrite can now scan the directory or collection hierarchy to find a controller.xql which matches the request path. For example, if the requested path is /exist/a/b, XQueryURLRewrite will check the directories webapp/a and webapp/a/b for an XQuery file called controller.xql and executes the last one it finds. The start point for the search is determined by configuration parameter "base" in web.xml. This parameter can also point to a collection in the db, causing XQueryURLRewrite to search the collection hierarchy instead of the file system. <filter> <filter-name>XQueryURLRewrite</filter-name> <filter-class>org.exist.http.urlrewrite.XQueryURLRewrite</filter-class> <init-param> <param-name>base</param-name> <param-value>xmldb:exist:///db</param-value> </init-param> </filter> Wolfgang |
From: Tomek Piechowicz <tomasz.piechowicz@gm...> - 2009-06-29 21:55:20
|
Wolfgang Meier-2 wrote: > > Also, you can use all > of eXist's standard functionality to access the db, so the > XMLDBSourceFactory is not really required anymore. > Does It mean that I don`t have to create any configuration files containing definition of protocol and database driver to use XQueryGenerator ? To test this approach I created new cocoon 2.2 block in maven and added xquery generator and simple pipeline to sitemap.xmap: <map:generators> <map:generator name="xquery" logger="sitemap.generator.xquery" src="org.exist.cocoon.XQueryGenerator" user="guest" password="guest" /> </map:generators> <map:pipeline> <map:match pattern="Exist"> <map:generate src="xmldb:exist:///db/tomek/people.xml"; type="xquery"/> <map:serialize type="xml"/> </map:match> </map:pipeline> After I run jetty, server throws exception : java.lang.ClassNotFoundException: org.exist.cocoon.XQueryGenerator Did I forget to copy some jars from eXist lib folder ? Which jar contains XQueryGenerator class ? Regards, Tomasz. -- View this message in context: http://www.nabble.com/Cocoon-2.2-%2B-eXist-1.2.6-%3A-Cocoon-sitemap-configuration.-tp24255711p24261679.html Sent from the exist-open mailing list archive at Nabble.com. |
From: Thomas White <thomas.0007@gm...> - 2009-06-29 20:55:46
|
Adam, 'text/javascript' has been used for long time as MIME type for JavaScript files and it is the only type recognized by IE. A good (and short) information can be found at http://annevankesteren.nl/2005/02/javascript-mime-type and the standard http://www.w3.org/TR/1999/REC-html401-19991224/interact/scripts.html#h-18.2.2.2 recommends 'text/javascript' One file extension can be only of one MIME type. Do you think it will be a good idea to use the standard recommendation of 'text/javascript' MIME type of .js files? Thomas > You would set the mime type in the mime-types.xml file in EXIST_HOME - > changes to this do require a restart. > > However looking in mime-types.xml I can see we already have a > definition for application/x-javascript - so perhaps that is the > mime-type you need? > > Thanks Adam. > > >> Regards, >> Thomas >> >> >> "Adam Retter" <adam@...> wrote in message >> news:3573c61b0906241312h4a516230jc01d46c3b0d438f0@... >>> Its is hopefully fixed now in trunk as SVN revision 9189. >>> >>> Let me know... >>> >>> Cheers Adam. >> >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Exist-open mailing list >> Exist-open@... >> https://lists.sourceforge.net/lists/listinfo/exist-open >> > > > > -- > Adam Retter > > eXist Developer > { United Kingdom } > adam@... > irc://irc.freenode.net/existdb > > ------------------------------------------------------------------------------ |
From: Thomas White <thomas.0007@gm...> - 2009-06-29 20:32:42
|
I have been waiting for this feature. Good job! Wolfgang, are we going to include this patch in the trunk? Thomas "Mike Sokolov" <sokolov@...> wrote in message news:4A452F88.7090000@... >I posted a patch here that addresses this issue (1688224 in the bug > tracker). It includes a test of nested relative module include that > failed before and now works. > > https://sourceforge.net/tracker/?func=detail&aid=2812962&group_id=17691&atid=317691 > > -Mike > > Wolfgang wrote: >>>> There is already a bug report for this, I tried to solve it but was >>>> not successful that time. Relative resolving of imports of xq >>>> modules...... would make apps better "portable" .... >> >> I think what we need to do is to overwrite "moduleLoadPath" in class >> ModuleContext to contain the path to the module, not to the main >> query. Right now, moduleLoadPath is set to the path of the parent >> context. >> >> Wolfgang > > ------------------------------------------------------------------------------ |
From: Adam Retter <adam@ex...> - 2009-06-29 20:31:12
|
> Today I found an interesting case using xdb:store-files-from-pattern. I > tried to import JavaScript files but for some reason 'text/javascript' MIME > type is not recognized as binary file and the parser gives an error: > > 2009-06-29 21:14:48,390 [P1-5] DEBUG (XMLDBLoadFromPattern.java > [evalWithCollection]:148) - D:\eXist\webapp\o8\js\ie7\ie7-recalc.js > 2009-06-29 21:14:48,390 [P1-5] DEBUG (Collection.java > [validateXMLResourceInternal]:1197) - Scanning document > /db/o8/js/ie7/ie7-recalc.js > 2009-06-29 21:14:48,390 [P1-5] DEBUG (Indexer.java [fatalError]:405) - fatal > error at (1,1) : Content is not allowed in prolog. > 2009-06-29 21:14:48,390 [P1-5] WARN (XMLDBLoadFromPattern.java > [evalWithCollection]:182) - Could not store file > D:\eXist\webapp\o8\js\ie7\ie7-recalc.js: The XML parser reported a problem: > fatal error at (1,1) : Content is not allowed in prolog. > > How do we set which MIME types are treated as binary and they are not > checked by the XML parser? You would set the mime type in the mime-types.xml file in EXIST_HOME - changes to this do require a restart. However looking in mime-types.xml I can see we already have a definition for application/x-javascript - so perhaps that is the mime-type you need? Thanks Adam. > Regards, > Thomas > > > "Adam Retter" <adam@...> wrote in message > news:3573c61b0906241312h4a516230jc01d46c3b0d438f0@... >> Its is hopefully fixed now in trunk as SVN revision 9189. >> >> Let me know... >> >> Cheers Adam. > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Exist-open mailing list > Exist-open@... > https://lists.sourceforge.net/lists/listinfo/exist-open > -- Adam Retter eXist Developer { United Kingdom } adam@... irc://irc.freenode.net/existdb |
From: Thomas White <thomas.0007@gm...> - 2009-06-29 20:24:25
|
Adam, Today I found an interesting case using xdb:store-files-from-pattern. I tried to import JavaScript files but for some reason 'text/javascript' MIME type is not recognized as binary file and the parser gives an error: 2009-06-29 21:14:48,390 [P1-5] DEBUG (XMLDBLoadFromPattern.java [evalWithCollection]:148) - D:\eXist\webapp\o8\js\ie7\ie7-recalc.js 2009-06-29 21:14:48,390 [P1-5] DEBUG (Collection.java [validateXMLResourceInternal]:1197) - Scanning document /db/o8/js/ie7/ie7-recalc.js 2009-06-29 21:14:48,390 [P1-5] DEBUG (Indexer.java [fatalError]:405) - fatal error at (1,1) : Content is not allowed in prolog. 2009-06-29 21:14:48,390 [P1-5] WARN (XMLDBLoadFromPattern.java [evalWithCollection]:182) - Could not store file D:\eXist\webapp\o8\js\ie7\ie7-recalc.js: The XML parser reported a problem: fatal error at (1,1) : Content is not allowed in prolog. How do we set which MIME types are treated as binary and they are not checked by the XML parser? Regards, Thomas "Adam Retter" <adam@...> wrote in message news:3573c61b0906241312h4a516230jc01d46c3b0d438f0@... > Its is hopefully fixed now in trunk as SVN revision 9189. > > Let me know... > > Cheers Adam. |
From: Wolfgang Meier <wolfgang@ex...> - 2009-06-29 15:42:21
|
> I`m new to eXist and I`ve been trying to access the database from Apache > Cocoon 2.2 framework via xml:db protocol. Some of the eXist components which were written for Cocoon do currently not work with Cocoon 2.2. The development version of eXist removes all direct dependencies on Cocoon (though it still contains Cocoon examples), so fixing the Cocoon integration isn't really a top priority anymore. We definitely need to work on this for the forthcoming 1.3/1.4 release though. Right now I'm not sure which features have to be upgraded. We may drop a few components which are poorly supported by Cocoon, in particular the XMLDBSourceFactory. However, I guess the most important component is the XQueryGenerator, which should still work. Also, you can use all of eXist's standard functionality to access the db, so the XMLDBSourceFactory is not really required anymore. Wolfgang |
From: Alexei Sakharov <asakharov@it...> - 2009-06-29 14:53:33
|
As i read in Xinclude section "Another common misunderstanding: eXist expands XIncludes at serialization time, which means that the query engine will see the XInclude tags /before/ they are expanded. You cannot query across XIncludes - unless you create your own code (e.g. an XQuery function) for it." Is there in eXist db some method or technique to put links into xml objects that link to another object, to perform search on hole structure of objects? |
From: Tomek Piechowicz <tomasz.piechowicz@gm...> - 2009-06-29 14:48:22
|
Hi. I`m new to eXist and I`ve been trying to access the database from Apache Cocoon 2.2 framework via xml:db protocol. I`ve found some information in Server Configuration section on eXist home page. In subsection 3. Cocoon Sitemap Configuration I found example code of configuration XML:DB Database Driver : <source-handler logger="core.source-handler"> <!-- xmldb pseudo protocol --> <protocol class="org.apache.cocoon.components.source.XMLDBSourceFactory" name="xmldb"> <driver class="org.exist.xmldb.DatabaseImpl" type="exist"/> <!-- Add here other XML:DB compliant databases drivers --> </protocol> </source-handler> After I created new cocoon 2.2 block in maven, I`ve copied following jars to WEB-INF/lib directory : exist/exist.jar exist/exist-optional.jar exist/lib/core/antlr-2.7.6.jar exist/lib/core/commons-pool-1.4.jar exist/lib/core/xmldb.jar exist/lib/core/xmlrpc-client-3.1.1.jar exist/lib/core/xmlrpc-common.3.1.1.jar I created configuration file in WEB-INF/avalon/cocoon.xconf and I put the configuration code into created file. When I try to run maven jetty with new configuration server throws exception : org.apache.avalon.framework.configuration.ConfigurationException: Unknow document 'source-handler' (...). Can anyone help me with this configuration ? Regards, Tomasz. |
From: James Fuller <james.fuller.2007@gm...> - 2009-06-28 13:10:29
|
Hello all, For those who use subversion to check out /trunk version of eXist will find some reorganizations that I performed during this weekend (moved xprocxq from google code scm to eXist). If you are working under extensions directory then commit your code first on specific extensions directory. You may find that when you do a svn update that subversion complains about xprocxq directory To sort this out: 1) remove extensions directory 2) svn up extensions directory should fix things. If anyone needs any help either jump onto IRC or email here or me directly. apologies for the disruption caused. Jim Fuller |
From: claud108 <claud108@ya...> - 2009-06-27 07:28:12
|
Sorry, you are right that i provided too little information. So, I have an web application which is accessed via the REST interface. My intention is to limit access to my server for third parties that could use the eXist client with the 'guest' account. Claudius -- View this message in context: http://www.nabble.com/Accessing-eXist-client-by-using-%27guest%27-account-tp24202090p24231024.html Sent from the exist-open mailing list archive at Nabble.com. |
From: Leif-Jöran Olsson <ljo@ex...> - 2009-06-26 20:32:40
|
Den 2009-06-26 18:33, claud108 skrev: > Changing this password crashed my access by using the admin account. > > Any ideas? No, you supply too little information. Start by saying what you are doing explicitly and we might be able to help you, otherwise not. Changing the guest account password does not affect the admin account in any way. It sounds like you are are in a web context depending on the guest account being default rather than using the java admin client which I assumed from your previous letter. > > My intention is to simply disable the access by using the eXist client when > the username is guest, not changing the password for this username. Sorry, you need to supply a clearly stated use case since I can't tell which layer you are in. > This is a simple way to forbid access to my server by using the eXist client > when the username is guest and, on the other hand, is already used by > admin.xql. You are talking about eXist client and admin.xql in the same sentence this makes me wonder what client you are actually talking about once again? Leif-Jöran |
From: Mike Sokolov <sokolov@if...> - 2009-06-26 20:29:05
|
I posted a patch here that addresses this issue (1688224 in the bug tracker). It includes a test of nested relative module include that failed before and now works. https://sourceforge.net/tracker/?func=detail&aid=2812962&group_id=17691&atid=317691 -Mike Wolfgang wrote: >>> There is already a bug report for this, I tried to solve it but was >>> not successful that time. Relative resolving of imports of xq >>> modules...... would make apps better "portable" .... > > I think what we need to do is to overwrite "moduleLoadPath" in class > ModuleContext to contain the path to the module, not to the main > query. Right now, moduleLoadPath is set to the path of the parent > context. > > Wolfgang |
From: SourceForge.net <noreply@so...> - 2009-06-26 20:17:08
|
Patches item #2812962, was opened at 2009-06-26 15:17 Message generated for change (Tracker Item Submitted) made by sokolovm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=317691&aid=2812962&group_id=17691 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mike sokolov (sokolovm) Assigned to: Nobody/Anonymous (nobody) Summary: relative module import Initial Comment: This patch addresses issue 1688224 in the bug tracker. I'm not sure it handles the difference in import context noted in the comment re: REST vs admin client (don't think so). But it does make it possible to imported one module from another using a relative path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=317691&aid=2812962&group_id=17691 |