This is a sign of a network error when subversion tried to do a big
ol' svn co http://svn.openlaszlo.org/openlaszlo/(something)
svn-get-source is a target in the nightly build's ant target, in
http://svn.openlaszlo.org/tools/trunk/build-tools/nightly/build.xml :
<target name="svn-get-source" description="Check out a tree
matching the tag"
unless="svn-get-source.done">
<exec executable="svn">
<arg value="checkout" />
<arg value="${path.tag}" />
<arg value="-q" />
<arg value="${tmp.dir}/${build.name}" />
</exec>
<property name="svn-get-source.done" value="true" />
</target>
On Oct 31, 2007, at 10:27 AM, Henry Minsky wrote:
Hmm, well that's not really what I'm talking about, but we
ought to look into that.
Where would I be able to see what
"svn-get-source" is doing? Is that a shell function, or ant target,
or something?
On 10/31/07, Mamye Kratt <[EMAIL PROTECTED]> wrote:
The svn error is below:
On Oct 22, 2007, at 3:04 PM, Mamye Kratt wrote:
svn-get-source:
[exec] svn: REPORT request failed on '/!svn/vcc/default'
[exec] svn: REPORT of '/!svn/vcc/default': Could not read
chunk size: Connection was closed by server. (http://
svn.openlaszlo.org)
----- Original Message -----
From: Henry Minsky
To: Max Carlson ; Laszlo-dev bug reporting
Sent: Wednesday, October 31, 2007 8:07 AM
Subject: Re: [Laszlo-dev] for review, Change 20071028-hqm-6,put XML
parser back into server data proxy pipeline,to do charset transcoding
Note, that this code does not know the content length before it
starts writing the output to
the client, since it's being streamed. So it doesn't set the
content length explicitly, like it used to.
My understanding of Tomcat's behavior is that if the content is
small enough to fit in some tomcat output
buffer size , it will buffer it and then send it all with a content
length header. If it is larger than that
then Tomcat sends it in HTTP chunked encoding. I still have to
verify this with a very large file.
On 10/28/07, Henry Minsky <[EMAIL PROTECTED]> wrote:
Change 20071028-hqm-6 by [EMAIL PROTECTED] on 2007-10-28 20:42:12
EDT
in /cygdrive/c/users/hqm/openlaszlo/trunk
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: put XML parser back into server data proxy pipeline, to do
charset transcoding
New Features:
Bugs Fixed: LPP-4924
Technical Reviewer: max
QA Reviewer: pablo
Doc Reviewer:
Details:
The server data proxy now uses the XMLPULL parser to parse
the data from the backend, in order to use Java to force a translation
into UTF-8
coding if needed.
This change also uses a worker Thread to read from the backend, while
simultaneously
pipelining the data back throug the XML PULL parser to the client.
This should improve
response time and also removes a potential memory overflow and DOS
attack on the server.
Tests:
test/lfc/data/alldata.lzx
amazon
calendar
Files:
D WEB-INF/lib/xpp3-1.1.3.4d_b4.jar
A WEB-INF/lib/xpp3-1.1.4c.jar
M WEB-INF/lps/lfc/kernel/swf/LzLoadQueue.as
A WEB-INF/lps/server/src/org/openlaszlo/data/HttpData.java
M WEB-INF/lps/server/src/org/openlaszlo/data/XMLGrabber.java
M WEB-INF/lps/server/src/org/openlaszlo/data/HTTPDataSource.java
M WEB-INF/lps/server/src/org/openlaszlo/data/DataSource.java
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
