Sava Jurisic | 1 Feb 2009 21:47

Re: Database reindex itself on eXist-stable-1.2 branch

Dannes Wessels <dizzzz <at> exist-db.org> writes:

> 
> Please upgrade to a newer version (_17) or to Java6.
> 
> If you have the same issue in Java6, please please please report the bug to
the JVM vendor (SUN), the address is in the error message. By giving this
information you help the whole java community.
> 

Hi Dannes,

we use SUN java and I have thought of that, so back in mid-january we upgraded
to JRE 1.6 and here is the error produced by latest jre;

Here is a log:

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d97eba1, pid=1860, tid=884
#
# Java VM: Java HotSpot(TM) Client VM (11.0-b15 mixed mode, sharing windows-x8)
# Problematic frame:
# V  [jvm.dll+0x17eba1]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

(Continue reading)

Dannes Wessels | 1 Feb 2009 22:30

Re: Database reindex itself on eXist-stable-1.2 branch


On 1 Feb 2009, at 21:47 , Sava Jurisic wrote:

we use SUN java and I have thought of that, so back in mid-january we upgraded
to JRE 1.6 and here is the error produced by latest jre;

Here is a log:

Hmmmm I do not see special things in the log. Well you clearly found a fatal JVM bug. Please could you file it at   http://java.sun.com/webapps/bugreport/crash.jsp ?

Brain storm... Is there a virus scanner present?

Kind regards

Dannes

--
eXist-db Open Source Native XML Database







------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Exist-open mailing list
Exist-open <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/exist-open
Brad Clements | 2 Feb 2009 03:11
Gravatar

REST POST problems, incomplete RESTServiceTest.java

I am using Rev 8550

I think there are two problems with the REST interface:

#1

The first, more serious one is that a POST of an xquery to a collection 
appears not to work because the xquery context is either not set, or not 
being used in the xquery.

I thought I would write a test for this, but I see there is already 
testQueryPost in test/src/org/exist/http/RESTServiceTest.java

The testQueryPost is only checking the HTTP Response code, but it could 
do better by examining the resultset from the query.

Looking at QUERY_REQUEST, I would expect that at least one para element 
would be found in the db.

However examining the system.out file for this test, I see:

<exist:result xmlns:exist="http://exist.sourceforge.net/NS/exist" exist:hits="0"
exist:start="1" exist:count="0"/>

I expect exist:count = 1

If  RESTServiceTest.RESTServiceTest.java were modified to check the 
result set, this first error would have been caught a while ago.

I tried debugging this by a debug statement to RESTServer.search, like so:

            if (LOG.isDebugEnabled())
                LOG.debug("static documents " + 
context.getStaticallyKnownDocuments());

This does print the expected list of documents in exist.log

At that point, I've run out of ideas.

#2.

When POSTing an xquery that generates a server-side error, error text is 
not returned to the client

A "202 Accepted" response is returned, but there isn't any information 
about the server-side error:

You can also sort of see this in the system.out file, but estimating 
where the error text would appear:

a. --- Get XQuery error code for posted query ---

b. <exist:result xmlns:exist="http://exist.sourceforge.net/NS/exist" exist:hits="1"
exist:start="1" exist:count="1">ääüüööÄÄÖÖÜÜ</exist:result>

Line a. is from testQueryPostXQueryError

Line b. appears to be  from testQueryGet

Therefore these two lines from testQueryPostXQueryError produced only 
one output line:

            System.out.println("--- Get XQuery error code for posted 
query ---");
            System.out.println(readResponse(connect.getInputStream()));

I would try to make these changes myself, but I don't know enough Java 
to figure out how to parse strings..

--

-- 
Brad Clements,                bkc <at> murkworks.com    (315)268-1000
http://www.murkworks.com                          
AOL-IM: BKClements

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
Paloschi Diego E | 2 Feb 2009 12:46

Re: Unsupported execution mode

Hi Pierrick,

>> Please ignore message below. Problem was in our code in the way we 
>> were creating new xquery contexts and compiled xqueries! Though I am 
>> not sure why we didn't get this errors in eXist 1.2.4 rev8072?
>
>Anyway, you should never get that error message  :-/
>
>It is probably related to a numeric predicate. It would be nice to see
the involved query.

Here is an example of an Xquery (actually, an Xquery update!) which was
returning 'unsupported execution mode' errors:

declare namespace test='http://test.domain.com';
declare variable $docPath external;
let $doc := doc($docPath)
where $doc/test:rootData/test:typeData[contains( <at> subject, 'subject')]
return
update value $doc/test:rootData/ <at> score with '100'

Please note that these Xqueries are now executing ok since we changed
the way in which the Xquery code is initialized and called.

Regards,
Diego.
The information contained in this E-Mail and any subsequent 
correspondence is private and is intended solely for the intended 
recipient(s).  The information in this communication may be 
confidential and/or legally privileged.  Nothing in this e-mail is 
intended to conclude a contract on behalf of QinetiQ or make QinetiQ 
subject to any other legally binding commitments, unless the e-mail 
contains an express statement to the contrary or incorporates a formal Purchase Order.

For those other than the recipient any disclosure, copying, 
distribution, or any action taken or omitted to be taken in reliance 
on such information is prohibited and may be unlawful.

Emails and other electronic communication with QinetiQ may be 
monitored and recorded for business purposes including security, audit 
and archival purposes.  Any response to this email indicates consent 
to this.

Telephone calls to QinetiQ may be monitored or recorded for quality 
control, security and other business purposes.

QinetiQ Limited
Registered in England & Wales: Company Number:3796233
Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX,
United Kingdom 
http://www.qinetiq.com/home/notices/legal.html

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
Andreas Hoheisel | 2 Feb 2009 13:35
Picon
Favicon

Re: How to limit the Memory Consumption of eXist? Problem with scope=session in server-config.wsdd?

For your information:

setting scope="application" for the Query and Admin-Service in 
WEB-INF/server-config.wsdd solved the problem!

Please see the attached figure. Before hour=375 the scope was set to 
"session", after hour=375 the scope was set to "application" and the 
memory consumption was becoming more stable after restarting tomcat.

I recommend to change the server-config.wsdd accordingly in the subversion:

[...]
<service name="Query" provider="java:RPC" style="wrapped" use="literal">
  [...]
  <parameter name="scope" value="application"/>
  [...]
</service>
[...]
<service name="Admin" provider="java:RPC" style="wrapped" use="literal">
  [...]
  <parameter name="scope" value="application"/>
  [...]
</service>

Best regards,

Andreas Hoheisel

Andreas Hoheisel wrote:
>>> I have the suspicion that the regular update each 10 Seconds of few 
>>> documents prevents the database to clean up the memory...  Maybe it 
>>> is also a tomcat/axis problem. I noticed, that you are using 
>>> "scope=session" instead of "scope=application" in the 
>>> server-config.wsdd. Is it safe to switch the scope to "application"? 
>>> This often solves tomcat memory issues...
>>>       
>> I have no experience with those settings, sorry.
>>     
> scope=session means, that your Query and Admin classes are instantiated 
> for each HTTP session. If you set scope=application then the Query and 
> Admin classes are instantiated only once when the first SOAP request 
> arrives and subsequent calls of the SOAP methods are invoked on the same 
> Object (Instance). It is told that scope=session often leads to memory 
> problems within tomcat...
>
> So it depends on the structure of the Query and Admin classes if it is 
> possible to switch to scope=application. It is mainly a matter of being 
> thread safe or not. I will just try it a give you a feedback within the 
> next weeks...
-- 
Besuchen Sie das Grid Workflow Forum auf http://www.gridworkflow.org/
http://www.andreas-hoheisel.de/

-- 
Andreas Hoheisel
Fraunhofer-Institut für Rechnerarchitektur und Softwaretechnik, FIRST
Interaktive Systeme (ISY)
Kekulestraße 7, 12489 Berlin, Germany
Telefon: +49 30 6392-1819
mailto:andreas.hoheisel <at> first.fraunhofer.de
http://www.first.fraunhofer.de

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Exist-open mailing list
Exist-open <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/exist-open
Andrzej Jan Taramina | 2 Feb 2009 16:45

Re: NPE bug in Trunk.....

Piotr:

> It looks like the module loading mechanism breaks when invoked through
> util:eval.  You didn't have this problem when you inherited the context
> since the module was already loaded.  I suspect that fully qualifying
> any path that fails to load might work around this, i.e.:
> 
> import module namespace common="http://chaeron.com/common" at
> "xmldb:exist///db/common.xqm";

Would that have any adverse impact on caching of the .xqm module?

--

-- 
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
Jaroslav Pullmann | 2 Feb 2009 16:32
Picon
Favicon

namespaces are apparently stripped


  Hello,
   I run into the same problem as described in the post from 2008/12/19
   - namespaces in an XForms document (as part of the XSLT) are missing in
   the transformation result. Could you please clarify whether this bug has
   already been solved (did not found anything related in the bug tracker) ?

    Many thanks
     Jaro

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
Clay Redding | 2 Feb 2009 16:52
Picon

Re: xsparql

Hi Mike,

I'm very interested in XSPARQL.  I use RDF quite a bit in eXist and have interest in using eXist as a RDF triple
or graph store that could be queried with both XQuery and SPARQL.  XSPARQL fits the bill.  I think it would be a
great feature if implemented in eXist.

Clay

>>> Mike Scott wrote - 2009-01-26 15:14
>>>Has anyone looked at XSPARQL?
>>>
>>>http://xsparql.deri.org/ 

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
Paul Kelly | 2 Feb 2009 17:30
Favicon

Re: xsparql

At 10:52 AM -0500 2/2/09, Clay Redding wrote:
>I'm very interested in XSPARQL.  I use RDF quite a bit in eXist and have interest in using eXist as a RDF triple
or graph store that could be queried with both XQuery and SPARQL.  XSPARQL fits the bill.  I think it would be a
great feature if implemented in eXist.

If you are willing to share, I'd be interested in how you've set up eXist to be queryable by SPARQL.
--

-- 
--paul

Paul Kelly
Dir. of Operations
XML Team: http://xmlteam.com

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
Clay Redding | 2 Feb 2009 18:19
Picon

Re: xsparql

Hi Paul,

I don't use SPARQL with the data stored in eXist, but that's what I hope can be supported some day.  I typically
only use eXist to pre-process the RDF, and then send the data to a triple store that does support SPARQL.  I
use Sesame and communicate over its REST API.  So at this point I (rather inefficiently) have to duplicate
the data in order to handle the SPARQL query.

HTH,
Clay

>>> Paul Kelly <paul <at> xmlteam.com> 02/02/09 11:30 AM >>>
At 10:52 AM -0500 2/2/09, Clay Redding wrote:
>I'm very interested in XSPARQL.  I use RDF quite a bit in eXist and have interest in using eXist as a RDF triple
or graph store that could be queried with both XQuery and SPARQL.  XSPARQL fits the bill.  I think it would be a
great feature if implemented in eXist.

If you are willing to share, I'd be interested in how you've set up eXist to be queryable by SPARQL.
--

-- 
--paul

Paul Kelly
Dir. of Operations
XML Team: http://xmlteam.com

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword

Gmane