Re: [Exist-open] Predicate change if attribute exists...?

[Adam Retter <adam@ex...>]

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

Re: [Exist-open] eXist forcing full GC before heap full?

[Wolfgang <wolfgang@ex...>]

> 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

Re: [Exist-open] eXist forcing full GC before heap full?

[James Fuller <james.fuller.2007@gm...>]

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
>

[Exist-open] Predicate change if attribute exists...?

[PencilEd <gstewart@lc...>]

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] 1.3 install on Vista

[Glen Bremner-Stokes <glen@op...>]

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)

[Exist-open] eXist forcing full GC before heap full?

[Alessandro Vernet <avernet@sc...>]

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.

Re: [Exist-open] query timeout bug

[Frey, Anthony - OJA <Anthony.Frey@wi...>]

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.
>

Re: [Exist-open] query timeout bug

[Andrew Hart CEMS Staff <Andrew2.Hart@uw...>]

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

Re: [Exist-open] query timeout bug

[Michael Sokolov <sokolov@if...>]

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
> 

Re: [Exist-open] 'text/javascript' files parsed as XML byxdb:store-files-from-pattern (wasxdb:store-files-from-pattern skips one directorywhenrecursive pattern is used)

[Thomas White <thomas.0007@gm...>]

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.

[Exist-open] query timeout bug

[Andrew Hart CEMS Staff <Andrew2.Hart@uw...>]

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

Re: [Exist-open] XQueryURLRewrite implementation change proposal

[Wolfgang Meier <wolfgang@ex...>]

> 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

Re: [Exist-open] Cocoon 2.2 + eXist 1.2.6 : Cocoon sitemap configuration.

[Tomek Piechowicz <tomasz.piechowicz@gm...>]

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.

Re: [Exist-open] 'text/javascript' files parsed as XML byxdb:store-files-from-pattern (wasxdb:store-files-from-pattern skips one directorywhenrecursive pattern is used)

[Thomas White <thomas.0007@gm...>]

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
>
> ------------------------------------------------------------------------------

Re: [Exist-open] PATCH posted (was Re: database modules)

[Thomas White <thomas.0007@gm...>]

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
>
> ------------------------------------------------------------------------------

Re: [Exist-open] 'text/javascript' files parsed as XML by xdb:store-files-from-pattern (was xdb:store-files-from-pattern skips one directorywhen recursive pattern is used)

[Adam Retter <adam@ex...>]

> 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

[Exist-open] 'text/javascript' files parsed as XML by xdb:store-files-from-pattern (was xdb:store-files-from-pattern skips one directorywhen recursive pattern is used)

[Thomas White <thomas.0007@gm...>]

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.

Re: [Exist-open] Cocoon 2.2 + eXist 1.2.6 : Cocoon sitemap configuration.

[Wolfgang Meier <wolfgang@ex...>]

> 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

[Exist-open] Xinclude usability

[Alexei Sakharov <asakharov@it...>]

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?

[Exist-open] Cocoon 2.2 + eXist 1.2.6 : Cocoon sitemap configuration.

[Tomek Piechowicz <tomasz.piechowicz@gm...>]

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.

[Exist-open] [IMPORTANT] changes on eXist trunk development with subversion

[James Fuller <james.fuller.2007@gm...>]

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

Re: [Exist-open] Accessing eXist client by using 'guest' account

[claud108 <claud108@ya...>]

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.

Re: [Exist-open] Accessing eXist client by using 'guest' account

[Leif-Jöran Olsson <ljo@ex...>]

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

[Exist-open] PATCH posted (was Re: database modules)

[Mike Sokolov <sokolov@if...>]

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

[Exist-open] [ exist-Patches-2812962 ] relative module import

[SourceForge.net <noreply@so...>]

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