headers
Charles Foster | 3 May 2008 17:37
Gravatar

Sedna Server 3.0 incompatible with Sedna Network Protocol + XQJ Driver

Hi Maria,

I think you will find that you did change the protocol in Sedna 3.0.

In the documentation, the se_ItemEnd Message is defined as follows:

se_ItemEnd (S).
head:
370 (int)
body length = 0 (int)
body:
empty

In Sedna 2.x, when the Server sends the se_ItemEnd message to the client,
it sends the following bytes
0,0,1,114 (int), (370 = se_ItemEnd)
0,0,0,0 (int), (body length = 0)

In Sedna 3.0, when the Server sends the se_ItemEnd message to the client,
it sends the following bytes
0,0,1,114 (int), (370 = se_ItemEnd)
0,0,0,5 (int), (body length = 5) - which means additional information to
read from within the message.
This contradicts the se_ItemEnd message outlined in the Sedna
Client/Server Protocol document.

This is why Sedna XML:DB 1.2 RC1 and earlier versions can not understand
further instructions correctly because it is out of sync.

It just so happens that the Sedna Java client allows for the Server to
(Continue reading)

Permalink | Reply | 3 comments |
headers
Maria Grineva | 4 May 2008 10:22

Re: Sedna Server 3.0 incompatible with Sedna Network Protocol + XQJ Driver

Hi Charles,

yes, you are right: there is a change in protocol in Sedna 3.0 which is actually a bug. I am sorry, you needed to spend time to discover it. As you said, our drivers (C, Java, and Scheme) worked inspite of this change, so I did not notice it in Sedna 3.0. Thank you for helping to discover the problem, I guess Steve (who is writing python driver) had faced with this bug also.


I think you will find that you did change the protocol in Sedna 3.0.

In the documentation, the se_ItemEnd Message is defined as follows:

se_ItemEnd (S).
head:
370 (int)
body length = 0 (int)
body:
empty

In Sedna 2.x, when the Server sends the se_ItemEnd message to the client,
it sends the following bytes
0,0,1,114 (int), (370 = se_ItemEnd)
0,0,0,0 (int), (body length = 0)

In Sedna 3.0, when the Server sends the se_ItemEnd message to the client,
it sends the following bytes
0,0,1,114 (int), (370 = se_ItemEnd)
0,0,0,5 (int), (body length = 5) - which means additional information to
read from within the message.
This contradicts the se_ItemEnd message outlined in the Sedna
Client/Server Protocol document.

yes, here is the problem.

 
So I repeat my previous question,

Will this v3.0 protocol change again in future versions of Sedna?

Sedna Socket Protocol changes *only* with support for backward compatibility. I mean, if it is changed, it still has to support the previous versions. So, we suppose the drivers written once, must work with the future versions of Sedna. Current situation is a bug.


 

and further questions,

What else has changed in the v3.0 protocol?

Nothing. Of course, if it is not a bug, that I don't know about.
 

Shall I try to modify Sedna XML:DB to suite this new v3.0 protocol, or
wait until you change yours and the v3.0 specification?

 No, I will fix this bug today, and tomorrow we will change our recommended Sedna build.
 


It would be perfect to include information about the data type of the
information returned in the se_ItemPart(s),
as this would be perfect for making a XQJ (XQuery For Java) driver and
serializing returned XQuery items into appropriate Java datatypes.

I wanted to write an XQJ Driver in November 2007 but felt hesitant because
I could not get the datatype about the
values returned from the server and thus would have an API that did not
pass the XQJ test suite.


Can you sketch a list of a products which support XQJ, and the products that become integratable with Sedna if Sedna support XQJ? What would support for XQJ give to Sedna? Charles, Sedna team is limited in resources, we need to estimate the value and importance of this piece of work.

I just googled for XQJ and I see it has become more popular compared to the period when XQJ was a draft.

Anyway, outer contributions of a quality that you can provide, are very important for us and we are ready to help you if you start developing XQJ driver.

 
I e-mailed you on the 27th of November 2007 about this and gave some ideas
of how this could be solved including stating
the datatype in the se_ItemEnd message but you never responded, I e-mailed
again on 14th of February 2008 to Ivan but no response
and 1st of April 2008 to Maxim, but no response.

We have been concentrated on finishing Sedna recovery feature and stress testing. Considering responses to our inquery, it is the main thing that prevents wide usage of Sedna in real applications.

Thank you  a lot for your attention and initiative!

M.

 
Regards,

Charles

> Hi Charles,
>
> I've just tried Sedna XML:DB 1.2 Release candidate, and I see there are
> some
> problems. Could you please send me sources, so that I can try to
> understand
> what exactly is wrong with the protocol?
>
> We didn't change the protocol in Sedna 3.0. So, I need looking into the
> sources.
>
> Best regards,
>
> Maria
>
> 2008/4/28 Charles Foster <charles-huu879ivjHnR7s880joybQ@public.gmane.org>:
>
>> Hi Guys,
>>
>> I assumed Sedna 3.0 would just work with Sedna XML:DB.
>>
>> But I've just been notified of a problem, it now appears Sedna XML:DB
>> hardly works at all with Sedna 3.0.
>>
>> The version 3.0 protocol must have changed some how, I am now going to
>> investigate where the issues lies, the question remains if I change it
>> to
>> work for Sedna 3.0, will Sedna XML:DB break for Sedna 2.0? and will this
>> v3.0 protocol change again in future versions of Sedna?
>>
>> Regards,
>>
>> Charles
>>
>> > It looks like something happens to a client socket - the Sedna server
>> > failed
>> > to recv (recv returned SOCKET_ERROR).
>> >
>> > Something wrong is happenning when you execute query. I guess, the
>> > CommitTransaction is not the problem in this case, any command sent
>> after
>> > query execution will provide the same error. Please, check this - try
>> to
>> > execute the next query.  (Begin, doc("$version"), doc("$version")).
>> >
>> > Maybe something is wrong with your current Sedna installation: please,
>> > check
>> > if this sequnce works through the Sedna terminal (se_term):
>> >
>> > \unset AUTOCOMMIT
>> > doc("$version")&
>> > \commit
>> > \quit
>> >
>> > best regards,
>> >
>> > Maria
>> >
>> > 2008/4/14, Steve Howe <howesteve-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>> >>
>> >> Hello Maria,
>> >>
>> >> > That looks strange. Are you sure the query was executed
>> successfully?
>> >> Can
>> >> > you repeat the situation and send me Sedna's event.log (located in
>> >> > <SEDNA_INSTALL>/data)?
>> >> >
>> >> > This part of the protocol didn't change since Sedna 1.0
>> >>
>> >>
>> >> Here is goes:
>> >>
>> >> LOG   13/04/2008 02:46:32 (TRN test sid=49 trid=-1)
>> [tr.cpp:TRmain:258]:
>> >> Session is ready
>> >> LOG   13/04/2008 02:46:37 (TRN test sid=49 trid=49)
>> >> [tr_functions.cpp:on_user_statement_begin:78]: User query:
>> >> ---   doc('$version')
>> >> SYS   13/04/2008 02:46:37 (TRN test sid=49 trid=-1)
>> >> [usocket.c:urecv:285]:
>> >> recv (code = 104): Connection reset by peer
>> >> ERROR 13/04/2008 02:46:37 (TRN test sid=49 trid=-1)
>> >> [socket_client.cpp:read_msg:133]: (SE3007) Failed to recieve a
>> message.
>> >> Details: Connection reset by peer
>> >> LOG   13/04/2008 02:46:37 (TRN test sid=49 trid=-1)
>> [tr.cpp:TRmain:587]:
>> >> Session is closed
>> >>
>> >> Now that I'm reading it - I didn't ask for a connection close but
>> rather
>> >> a
>> >> commit. The code was really like the one I posted.
>> >>
>> >> --
>> >> Best Regards,
>> >>
>> >> Steve Howe
>> >>
>> >
>> -------------------------------------------------------------------------
>> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> > Don't miss this year's exciting event. There's still time to save
>> $100.
>> > Use priority code J8TL2D2.
>> >
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
>> > Sedna-discussion mailing list
>> > Sedna-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> > https://lists.sourceforge.net/lists/listinfo/sedna-discussion
>> >
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Don't miss this year's exciting event. There's still time to save $100.
>> Use priority code J8TL2D2.
>>
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> _______________________________________________
>> Sedna-discussion mailing list
>> Sedna-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> https://lists.sourceforge.net/lists/listinfo/sedna-discussion
>>
>


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Sedna-discussion mailing list
Sedna-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sedna-discussion

Permalink | Reply | 0 comments |
headers
Ivan Shcheklein | 6 May 2008 12:19
Picon

[ANN] New Sedna 3.0 build available for FreeBSD and Mac OS

Hi all,

We are pleased to announce a new build 64 of Sedna 3.0.

New:

  • binary and source builds are available for FreeBSD and Mac OS (PowerPC, i386);
  • support for gcc 4.0 under Mac OS;
  • minor bug fixes.
Best regards,
Sedna Team
Permalink | Reply | 0 comments |
headers
Maria Grineva | 6 May 2008 13:07

Re: Sedna Server 3.0 incompatible with Sedna Network Protocol + XQJ Driver

Hi Charles and Steve,

we have put a new Sedna build recommended for download on our site.

This build contains Sedna Socket Protocol bug fix, so XML:DB API works fine again.

Steve, I guess this can help with your python driver problem also.

Maria Grineva
Sedna team

2008/5/3 Charles Foster <charles-huu879ivjHnR7s880joybQ@public.gmane.org>:
Hi Maria,

I think you will find that you did change the protocol in Sedna 3.0.

In the documentation, the se_ItemEnd Message is defined as follows:

se_ItemEnd (S).
head:
370 (int)
body length = 0 (int)
body:
empty

In Sedna 2.x, when the Server sends the se_ItemEnd message to the client,
it sends the following bytes
0,0,1,114 (int), (370 = se_ItemEnd)
0,0,0,0 (int), (body length = 0)

In Sedna 3.0, when the Server sends the se_ItemEnd message to the client,
it sends the following bytes
0,0,1,114 (int), (370 = se_ItemEnd)
0,0,0,5 (int), (body length = 5) - which means additional information to
read from within the message.
This contradicts the se_ItemEnd message outlined in the Sedna
Client/Server Protocol document.

This is why Sedna XML:DB 1.2 RC1 and earlier versions can not understand
further instructions correctly because it is out of sync.

It just so happens that the Sedna Java client allows for the Server to
change the network protocol in this way.

In essence it appears the Sedna 3.0 server is incompatible with the Sedna
network protocol.

So I repeat my previous question,

Will this v3.0 protocol change again in future versions of Sedna?

and further questions,

What else has changed in the v3.0 protocol?
Shall I try to modify Sedna XML:DB to suite this new v3.0 protocol, or
wait until you change yours and the v3.0 specification?
What is the purpose of including information in the se_ItemEnd message?

It would be perfect to include information about the data type of the
information returned in the se_ItemPart(s),
as this would be perfect for making a XQJ (XQuery For Java) driver and
serializing returned XQuery items into appropriate Java datatypes.

I wanted to write an XQJ Driver in November 2007 but felt hesitant because
I could not get the datatype about the
values returned from the server and thus would have an API that did not
pass the XQJ test suite.

I e-mailed you on the 27th of November 2007 about this and gave some ideas
of how this could be solved including stating
the datatype in the se_ItemEnd message but you never responded, I e-mailed
again on 14th of February 2008 to Ivan but no response
and 1st of April 2008 to Maxim, but no response.

I guess you don't want an XQJ driver for Sedna, even though I've been
prepared to help you write one since November 2007.

Regards,

Charles

> Hi Charles,
>
> I've just tried Sedna XML:DB 1.2 Release candidate, and I see there are
> some
> problems. Could you please send me sources, so that I can try to
> understand
> what exactly is wrong with the protocol?
>
> We didn't change the protocol in Sedna 3.0. So, I need looking into the
> sources.
>
> Best regards,
>
> Maria
>
> 2008/4/28 Charles Foster <charles-huu879ivjHnR7s880joybQ@public.gmane.org>:
>
>> Hi Guys,
>>
>> I assumed Sedna 3.0 would just work with Sedna XML:DB.
>>
>> But I've just been notified of a problem, it now appears Sedna XML:DB
>> hardly works at all with Sedna 3.0.
>>
>> The version 3.0 protocol must have changed some how, I am now going to
>> investigate where the issues lies, the question remains if I change it
>> to
>> work for Sedna 3.0, will Sedna XML:DB break for Sedna 2.0? and will this
>> v3.0 protocol change again in future versions of Sedna?
>>
>> Regards,
>>
>> Charles
>>
>> > It looks like something happens to a client socket - the Sedna server
>> > failed
>> > to recv (recv returned SOCKET_ERROR).
>> >
>> > Something wrong is happenning when you execute query. I guess, the
>> > CommitTransaction is not the problem in this case, any command sent
>> after
>> > query execution will provide the same error. Please, check this - try
>> to
>> > execute the next query.  (Begin, doc("$version"), doc("$version")).
>> >
>> > Maybe something is wrong with your current Sedna installation: please,
>> > check
>> > if this sequnce works through the Sedna terminal (se_term):
>> >
>> > \unset AUTOCOMMIT
>> > doc("$version")&
>> > \commit
>> > \quit
>> >
>> > best regards,
>> >
>> > Maria
>> >
>> > 2008/4/14, Steve Howe <howesteve-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>> >>
>> >> Hello Maria,
>> >>
>> >> > That looks strange. Are you sure the query was executed
>> successfully?
>> >> Can
>> >> > you repeat the situation and send me Sedna's event.log (located in
>> >> > <SEDNA_INSTALL>/data)?
>> >> >
>> >> > This part of the protocol didn't change since Sedna 1.0
>> >>
>> >>
>> >> Here is goes:
>> >>
>> >> LOG   13/04/2008 02:46:32 (TRN test sid=49 trid=-1)
>> [tr.cpp:TRmain:258]:
>> >> Session is ready
>> >> LOG   13/04/2008 02:46:37 (TRN test sid=49 trid=49)
>> >> [tr_functions.cpp:on_user_statement_begin:78]: User query:
>> >> ---   doc('$version')
>> >> SYS   13/04/2008 02:46:37 (TRN test sid=49 trid=-1)
>> >> [usocket.c:urecv:285]:
>> >> recv (code = 104): Connection reset by peer
>> >> ERROR 13/04/2008 02:46:37 (TRN test sid=49 trid=-1)
>> >> [socket_client.cpp:read_msg:133]: (SE3007) Failed to recieve a
>> message.
>> >> Details: Connection reset by peer
>> >> LOG   13/04/2008 02:46:37 (TRN test sid=49 trid=-1)
>> [tr.cpp:TRmain:587]:
>> >> Session is closed
>> >>
>> >> Now that I'm reading it - I didn't ask for a connection close but
>> rather
>> >> a
>> >> commit. The code was really like the one I posted.
>> >>
>> >> --
>> >> Best Regards,
>> >>
>> >> Steve Howe
>> >>
>> >
>> -------------------------------------------------------------------------
>> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> > Don't miss this year's exciting event. There's still time to save
>> $100.
>> > Use priority code J8TL2D2.
>> >
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
>> > Sedna-discussion mailing list
>> > Sedna-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> > https://lists.sourceforge.net/lists/listinfo/sedna-discussion
>> >
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Don't miss this year's exciting event. There's still time to save $100.
>> Use priority code J8TL2D2.
>>
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> _______________________________________________
>> Sedna-discussion mailing list
>> Sedna-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> https://lists.sourceforge.net/lists/listinfo/sedna-discussion
>>
>


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Sedna-discussion mailing list
Sedna-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/sedna-discussion

Permalink | Reply | 1 comment |
headers
Steve Howe | 6 May 2008 13:38
Picon

Re: Sedna Server 3.0 incompatible with Sedna Network Protocol + XQJ Driver

Hello Maria,
> Hi Charles and Steve,
>
> we have put a new Sedna build recommended for download on our site.
>
> This build contains Sedna Socket Protocol bug fix, so XML:DB API works fine
> again.
>
> Steve, I guess this can help with your python driver problem also.
Thanks, I'll take a look at it.

--

-- 
Best Regards,
Steve Howe
Permalink | Reply | 0 comments |
headers
minh thu | 10 May 2008 18:32
Picon
Gravatar

xquery against files and xhtml generation

Hi,

I have two basic questions :

I've read on a mailing list an old message (2005) stating that Sedna
can be used as a query engine, not only as a db.
Is it true ? Can I perform queries against a file without first
loading it into a db ?

I'd like to generate xhtml from xml data.
The namespace for the result is of course http://www.w3.org/1999/xhtml
and the source data has its own namespace.
Also, the xhtml is constructed in fragment, not the whole page in one
return; this means that I don't want to have
<div xmlns="http://www.w3.org/1999/xhtml">...</div> everytime I return
such a div but rather <div>...</div>.
How should I handle the changes of namespaces in queries ?

Thanks a lot,
Vo Minh Thu
Permalink | Reply | 1 comment |
headers
minh thu | 10 May 2008 20:06
Picon
Gravatar

UPDATE in function

Hi again,

Is it possible to use the update language of Sedna inside functions
defined in a module ?

Thanks,
Thu
Permalink | Reply | 1 comment |
headers
ZNV | 11 May 2008 00:49
Picon

Re: UPDATE in function

Hello, Thu

It is not possible to mix Sedna update language with XQuery.

Hence it is impossible to perform updates in a function, both in the
one defined inline or in the one define in a module.

This limitation is by design. Assume mixed updates & xquery were
permitted. Consider the following situation - FLOWER (for.. etc.)
statement feeding a function (the one with update statement inside)
with nodes. To yield correct result FLOWER must not see any changes
made by the nested update. To make this sample work, Sedna would have
to create a temporary copy of the entire document (SLOW!) and run
FLOWER on it. This way nested update would not disrupt FLOWER since
updates are applyed to the document itself but  FLOWER runs on
imutable copy of the document.

Support for huge documents is a major feature of Sedna. We don't allow
mixed xquery/updates since they impose huge performance overhead when
data is large.

Mejedi,
Sedna Team

2008/5/10 minh thu <noteed@...>:
> Hi again,
>
> Is it possible to use the update language of Sedna inside functions
> defined in a module ?
>
> Thanks,
> Thu
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Sedna-discussion mailing list
> Sedna-discussion@...
> https://lists.sourceforge.net/lists/listinfo/sedna-discussion
>
Permalink | Reply | 0 comments |
headers
ZNV | 11 May 2008 00:53
Picon

Re: xquery against files and xhtml generation

Hello, Thu

>Can I perform queries against a file without first
loading it into a db ?
No.

Mejedi,
Sedna Team

2008/5/10 minh thu <noteed@...>:
> Hi,
>
> I have two basic questions :
>
> I've read on a mailing list an old message (2005) stating that Sedna
> can be used as a query engine, not only as a db.
> Is it true ? Can I perform queries against a file without first
> loading it into a db ?
>
> I'd like to generate xhtml from xml data.
> The namespace for the result is of course http://www.w3.org/1999/xhtml
> and the source data has its own namespace.
> Also, the xhtml is constructed in fragment, not the whole page in one
> return; this means that I don't want to have
> <div xmlns="http://www.w3.org/1999/xhtml">...</div> everytime I return
> such a div but rather <div>...</div>.
> How should I handle the changes of namespaces in queries ?
>
> Thanks a lot,
> Vo Minh Thu
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Sedna-discussion mailing list
> Sedna-discussion@...
> https://lists.sourceforge.net/lists/listinfo/sedna-discussion
>
Permalink | Reply | 0 comments |
headers
Adrian Iacob | 11 May 2008 22:20
Picon

Sedna 3.0.64 CRASH

Hi,

 

I have a bug that crashes sedna 3.0.64 – on windows:

 

STEPS:

1)      New sedna instance

2)      Create a database

3)      Load the document test_Crash6

4)      RUN the QUERY

a)      for $e in doc('test_Crash6')/root/a order by $e/b ascending return $e – CRASHES

 

 

the for $e in doc('test_Crash6')/root/a return $e   is  OK… if I put the order by … it CRASHES

 

Thanks

Adrian

Attachment (test_Crash6): application/octet-stream, 57 KiB
Permalink | Reply | 1 comment |

Gmane