Project

Profile

Help

Bug #2271 » Bug #3876 - 2014-12-24T12_14_35Z.eml

Tomaž Erjavec, 2014-12-24 13:14

 
1
Return-Path: <Tomaz.Erjavec@ijs.si>
2
Received: from mi015.mc1.hosteurope.de ([80.237.138.240]) by wp245.webpack.hosteurope.de running ExIM with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1Y3kpj-0006x6-9P; Wed, 24 Dec 2014 13:14:31 +0100
3
Received: from mail.ijs.si ([193.2.4.66]) by mx0.webpack.hosteurope.de (mi015.mc1.hosteurope.de) with esmtps (TLSv1.1:DHE-RSA-AES256-SHA:256) id 1Y3kph-00015i-Rf for dropbox+saxonica+f38e@plan.io; Wed, 24 Dec 2014 13:14:31 +0100
4
Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3k6tdK3cBnzDJ for <dropbox+saxonica+f38e@plan.io>; Wed, 24 Dec 2014 13:14:29 +0100
5
Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id u6TylcPhGTvx for <dropbox+saxonica+f38e@plan.io>; Wed, 24 Dec 2014 13:14:25 +0100
6
Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for <dropbox+saxonica+f38e@plan.io>; Wed, 24 Dec 2014 13:14:25 +0100
7
Received: from [IPv6:2001:1470:ff80:e8:3c6d:3d1f:10bc:1667] (unknown [IPv6:2001:1470:ff80:e8:3c6d:3d1f:10bc:1667]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id 3k6tdF0L3Xz1Ch for <dropbox+saxonica+f38e@plan.io>; Wed, 24 Dec 2014 13:14:25 +0100
8
Date: Wed, 24 Dec 2014 13:14:34 +0100
9
From: =?UTF-8?B?VG9tYcW+IEVyamF2ZWM=?= <Tomaz.Erjavec@ijs.si>
10
To: Saxonica Developer Community <dropbox+saxonica+f38e@plan.io>
11
Message-ID: <549AAE2A.5090107@ijs.si>
12
In-Reply-To: <redmine.journal-3874.20141223230614@plan.io>
13
References: <redmine.issue-2271.20141221205103@plan.io>
14
 <redmine.journal-3874.20141223230614@plan.io>
15
Subject: Re: [Saxon - Bug #2271] (Resolved) AIOOBE with large xml file
16
Mime-Version: 1.0
17
Content-Type: multipart/alternative;
18
 boundary=------------020308060604080408010703;
19
 charset=UTF-8
20
Content-Transfer-Encoding: 7bit
21
Delivery-date: Wed, 24 Dec 2014 13:14:31 +0100
22
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h=
23
 content-type:content-type:in-reply-to:references:subject:subject
24
 :mime-version:user-agent:from:from:date:date:message-id:received
25
 :received:received; s=jakla4; t=1419423265; x=1422015266; bh=dJi
26
 JcIiyvZzovhM8keDLi0m6lcBTdLX7/f89b+1vgSQ=; b=Q1CZQRq6aQPAwFuWvkF
27
 q1ZTFLSG5F1TBlP7XMAcR6OnjxvPTxPi4Sr25hUzM8wW90cRgqpIKTDYRemmxEGt
28
 sa56v2f14hNHUaCfozTOCQVpcOd4Jbb3WvYfVMm500a93gEGZcXiEdFPFSABDrkD
29
 pUL+h0s1zqVvYLuZ4AJFkCfk=
30
X-Virus-Scanned: amavisd-new at ijs.si
31
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101
32
 Thunderbird/31.3.0
33
X-HE-Spam-Level: -----
34
X-HE-Spam-Score: -5.0
35
X-HE-Spam-Report: Content analysis details: (-5.0 points) pts rule name
36
 description ---- ----------------------
37
 -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL:
38
 Sender listed at http://www.dnswl.org/, high trust [193.2.4.66 listed in
39
 list.dnswl.org] 0.1 HTML_MESSAGE BODY: HTML included in message -0.1
40
 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain
41
 -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1
42
 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
43
X-HE-SPF: PASSED
44
Envelope-to: dropbox+saxonica+f38e@plan.io
45

    
46
This is a multi-part message in MIME format.
47
--------------020308060604080408010703
48
Content-Type: text/plain;
49
 charset=utf-8;
50
 format=flowed
51
Content-Transfer-Encoding: quoted-printable
52

    
53
I won't pretend to understand Saxon datastructures and functions that =
54

    
55
need to be modified but, yes, for me it would certainly be nice if I =
56

    
57
could feed large files to XSLT; I'm working with corpora, where there =
58

    
59
are lots of conversions to be done, and working on the whole corpus / =
60

    
61
file is of course very convenient (it's not such a bit thing to split =
62

    
63
it, but it's one more layer of complication). And my server has 47G of =
64

    
65
memory, so no problem there.
66
So, very glad that it seems doable, and fingers crossed that a dark cold =
67

    
68
winter day comes along to provide the opportunity to do it :)
69
All the best,
70
Toma=C5=BE
71

    
72
Dne 24.12.2014 ob 0:06 je Saxonica Developer Community zapisal(a):
73
>
74
> --- In your reply, please do not write below this line ---
75
>
76
> Issue #2271 has been updated by Michael Kay.
77
>
78
>   * *Status* changed from /In Progress/ to /Resolved/
79
>
80
> I've been thinking a little about how one might tackle this, without =
81

    
82
> relying on any Java changes.
83
>
84
> It would be easy to change the LargeStringBuffer to support 2^31 =
85

    
86
> segments of 2^16 characters, instead of 2^15 segments as at present. =
87

    
88
> It wouldn't be possible to implement CharSequence properly, because =
89

    
90
> CharSequence uses int offsets; but there's actually no great need for =
91

    
92
> LargeStringBuffer to implement CharSequence. We would also need a =
93

    
94
> variant of the TinyTree that uses longs instead of ints for the =
95

    
96
> offsets into the buffer. (Actually, I don't think there's a really =
97

    
98
> great need for the string value of the document to be held in =
99

    
100
> pseudo-contiguous storage at all, but it would reduce the changes =
101

    
102
> needed to keep it that way).
103
>
104
> If someone actually asks for the string value of the root node, which =
105

    
106
> will be longer than 2^31 characters, we can return a StringValue that =
107

    
108
> contains pointers into the LargeStringBuffer. That's no great problem =
109

    
110
> at the XPath level. At the Java API level we would need to make =
111

    
112
> changes to NodeInfo.getStringValue(), but I think we could do this by =
113

    
114
> retaining this method and having it throw an exception if the string =
115

    
116
> value is too long, and providing an alternative method for getting the =
117

    
118
> string value without the 2^31 limit.
119
>
120
> In 9.6 we've started making greater use of the interface UnicodeString =
121

    
122
> which provides direct addressing into strings using Unicode codepoint =
123

    
124
> counting rather than 16-bit char counting. This also has the advantage =
125

    
126
> that strings using only Latin-1 characters only need 8 bits per =
127

    
128
> character. We could easily extend this interface to use longs rather =
129

    
130
> than ints for codepoint addressing, and we could underpin it with =
131

    
132
> something like the LargeStringBuffer data structure to bypass Java =
133

    
134
> limits on string and array sizes. So I think it's do-able.
135
>
136
> (Just been looking at the specs for current MacBooks and I'm actually =
137

    
138
> slightly surprised that they're not very much higher than my =
139

    
140
> early-2011 model. Perhaps things are reaching a plateau? Who knows.)
141
>
142
> -----------------------------------------------------------------------=
143
-
144
>
145
>
146
>   Bug #2271: AIOOBE with large xml file
147
>   <https://saxonica.plan.io/issues/2271#change-3874>
148
>
149
>   * Author: Toma=C5=BE Erjavec
150
>   * Status: Resolved
151
>   * Priority: Normal
152
>   * Assignee: Toma=C5=BE Erjavec
153
>   * Category: Internals
154
>   * Sprint/Milestone:
155
>   * Legacy ID:
156
>   * Found in version: 9.6
157
>   * Fixed in version:
158
>
159
> Hi,
160
> Saxon gives me an array index out of bounds when I try to process a =
161

    
162
> large file and this happens even with an empty stylesheet. I can =
163

    
164
> understand that it wouldn't work, but with an exception saying out of =
165

    
166
> memory, but not AIOOBE.
167
> I'm using Saxon 9.6.0.3 (I tried with some older versions, same =
168

    
169
> problem) with java 1.8.0_25:
170
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
171
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
172
> Below is the trace.
173
> All the best,
174
> Toma=C5=BE
175
> PS: I can send the file if it would help.
176
>
177
> $ du -h blog.bug.xml
178
> 2,8G blog.bug.xml
179
> $ java -jar /usr/local/bin/saxon9he.jar -xsl:empty.xsl blog.bug.xml > =
180

    
181
> bug.vert
182
> java.lang.ArrayIndexOutOfBoundsException: -32768
183
> at =
184

    
185
> net.sf.saxon.tree.tiny.LargeStringBuffer.append(LargeStringBuffer.java:=
186
90)
187
> at net.sf.saxon.tree.tiny.TinyTree.appendChars(TinyTree.java:405)
188
> at net.sf.saxon.tree.tiny.TinyBuilder.makeTextNode(TinyBuilder.java:380=
189
)
190
> at net.sf.saxon.tree.tiny.TinyBuilder.characters(TinyBuilder.java:362)
191
> at =
192

    
193
> net.sf.saxon.event.ReceivingContentHandler.flush(ReceivingContentHandle=
194
r.java:544)
195
> at =
196

    
197
> net.sf.saxon.event.ReceivingContentHandler.endElement(ReceivingContentH=
198
andler.java:435)
199
> at =
200

    
201
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement=
202
(AbstractSAXParser.java:609)
203
> at =
204

    
205
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.=
206
scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
207
> at =
208

    
209
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$=
210
FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2973)
211
> at =
212

    
213
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XML=
214
DocumentScannerImpl.java:606)
215
> at =
216

    
217
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(X=
218
MLNSDocumentScannerImpl.java:117)
219
> at =
220

    
221
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.=
222
scanDocument(XMLDocumentFragmentScannerImpl.java:510)
223
> at =
224

    
225
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML=
226
11Configuration.java:848)
227
> at =
228

    
229
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML=
230
11Configuration.java:777)
231
> at =
232

    
233
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.ja=
234
va:141)
235
> at =
236

    
237
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Abst=
238
ractSAXParser.java:1213)
239
> at =
240

    
241
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.par=
242
se(SAXParserImpl.java:649)
243
> at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:440)
244
> at net.sf.saxon.event.Sender.send(Sender.java:171)
245
> at net.sf.saxon.Controller.transform(Controller.java:1690)
246
> at net.sf.saxon.s9api.XsltTransformer.transform(XsltTransformer.java:54=
247
7)
248
> at net.sf.saxon.Transform.processFile(Transform.java:1056)
249
> at net.sf.saxon.Transform.doTransform(Transform.java:659)
250
> at net.sf.saxon.Transform.main(Transform.java:80)
251
> Fatal error during transformation: =
252

    
253
> java.lang.ArrayIndexOutOfBoundsException: -32768
254
>
255
> -----------------------------------------------------------------------=
256
-
257
>
258
> You have received this notification because you have either subscribed =
259

    
260
> to or are involved in a project on Saxonica Developer Community site.
261
> To change your notification preferences, please click here: =
262

    
263
> https://saxonica.plan.io/my/account
264
>
265
> 	=
266

    
267
>
268
> This notification was cheerfully delivered by <https://plan.io/>
269
> 	=
270

    
271
> Planio <https://plan.io/>
272
>
273

    
274

    
275
--------------020308060604080408010703
276
Content-Type: text/html;
277
 charset=utf-8
278
Content-Transfer-Encoding: quoted-printable
279

    
280
<html>
281
  <head>
282
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
283
pe">
284
  </head>
285
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
286
    I won't pretend to understand Saxon datastructures and functions
287
    that need to be modified but, yes, for me it would certainly be nice
288
    if I could feed large files to XSLT; I'm working with corpora, where
289
    there are lots of conversions to be done, and working on the whole
290
    corpus / file is of course very convenient (it's not such a bit
291
    thing to split it, but it's one more layer of complication). And my
292
    server has 47G of memory, so no problem there.<br>
293
    So, very glad that it seems doable, and fingers crossed that a dark
294
    cold winter day comes along to provide the opportunity to do it :)<br=
295
>
296
    All the best,<br>
297
    Toma=C5=BE<br>
298
    <br>
299
    <div class=3D"moz-cite-prefix">Dne 24.12.2014 ob 0:06 je Saxonica
300
      Developer Community zapisal(a):<br>
301
    </div>
302
    <blockquote cite=3D"mid:redmine.journal-3874.20141223230614@plan.io"
303
      type=3D"cite">
304
      <style>
305
@import url(<a class=3D"moz-txt-link-freetext" href=3D"https://assets.pla=
306
n.io/stylesheets/fonts.css">https://assets.plan.io/stylesheets/fonts.css<=
307
/a>);
308
body {
309
  font-family: "ProximaNova-Regular", Verdana, sans-serif;
310
  font-size: 1.1em;
311
  color:#333434;
312
}
313
h1, h2, h3 { font-family: "ProximaNova-Bold", "Trebuchet MS", Verdana, sa=
314
ns-serif; margin: 0px; }
315
h1 { font-size: 1.2em; }
316
h2, h3 { font-size: 1.1em; }
317
a, a:link, a:visited, a:hover, a:active { color:#2b7a94; }
318
a.wiki-anchor { display: none; }
319
hr {
320
  width: 100%;
321
  height: 1px;
322
  background: #ccc;
323
  border: 0;
324
}
325
</style>
326
      <table width=3D"100%">
327
        <tbody>
328
          <tr>
329
            <td style=3D"font-family: MarketWeb, Verdana,
330
              sans-serif;font-size:0.8em;text-align:center;width:100%;col=
331
or:#D7D7D7;">
332
              <p>--- In your reply, please do not write below this line
333
                ---</p>
334
            </td>
335
          </tr>
336
          <tr>
337
            <td>Issue #2271 has been updated by Michael Kay.
338
              <ul>
339
                <li><strong>Status</strong> changed from <i>In Progress</=
340
i>
341
                  to <i>Resolved</i></li>
342
              </ul>
343
              <p>I've been thinking a little about how one might tackle
344
                this, without relying on any Java changes.</p>
345
              <p>It would be easy to change the LargeStringBuffer to
346
                support 2^31 segments of 2^16 characters, instead of
347
                2^15 segments as at present. It wouldn't be possible to
348
                implement CharSequence properly, because CharSequence
349
                uses int offsets; but there's actually no great need for
350
                LargeStringBuffer to implement CharSequence. We would
351
                also need a variant of the TinyTree that uses longs
352
                instead of ints for the offsets into the buffer.
353
                (Actually, I don't think there's a really great need for
354
                the string value of the document to be held in
355
                pseudo-contiguous storage at all, but it would reduce
356
                the changes needed to keep it that way).</p>
357
              <p>If someone actually asks for the string value of the
358
                root node, which will be longer than 2^31 characters, we
359
                can return a StringValue that contains pointers into the
360
                LargeStringBuffer. That's no great problem at the XPath
361
                level. At the Java API level we would need to make
362
                changes to NodeInfo.getStringValue(), but I think we
363
                could do this by retaining this method and having it
364
                throw an exception if the string value is too long, and
365
                providing an alternative method for getting the string
366
                value without the 2^31 limit.</p>
367
              <p>In 9.6 we've started making greater use of the
368
                interface UnicodeString which provides direct addressing
369
                into strings using Unicode codepoint counting rather
370
                than 16-bit char counting. This also has the advantage
371
                that strings using only Latin-1 characters only need 8
372
                bits per character. We could easily extend this
373
                interface to use longs rather than ints for codepoint
374
                addressing, and we could underpin it with something like
375
                the LargeStringBuffer data structure to bypass Java
376
                limits on string and array sizes. So I think it's
377
                do-able.</p>
378
              <p>(Just been looking at the specs for current MacBooks
379
                and I'm actually slightly surprised that they're not
380
                very much higher than my early-2011 model. Perhaps
381
                things are reaching a plateau? Who knows.)</p>
382
              <hr>
383
              <h1><a moz-do-not-send=3D"true"
384
                  href=3D"https://saxonica.plan.io/issues/2271#change-387=
385
4">Bug
386
                  #2271: AIOOBE with large xml file</a></h1>
387
              <ul>
388
                <li>Author: Toma=C5=BE Erjavec</li>
389
                <li>Status: Resolved</li>
390
                <li>Priority: Normal</li>
391
                <li>Assignee: Toma=C5=BE Erjavec</li>
392
                <li>Category: Internals</li>
393
                <li>Sprint/Milestone: </li>
394
                <li>Legacy ID: </li>
395
                <li>Found in version: 9.6</li>
396
                <li>Fixed in version: </li>
397
              </ul>
398
              <p>Hi,<br>
399
                Saxon gives me an array index out of bounds when I try
400
                to process a large file and this happens even with an
401
                empty stylesheet. I can understand that it wouldn't
402
                work, but with an exception saying out of memory, but
403
                not AIOOBE.<br>
404
                I'm using Saxon 9.6.0.3 (I tried with some older
405
                versions, same problem) with java 1.8.0_25:<br>
406
                Java(TM) SE Runtime Environment (build 1.8.0_25-b17)<br>
407
                Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02,
408
                mixed mode)<br>
409
                Below is the trace.<br>
410
                All the best,<br>
411
                Toma=C5=BE<br>
412
                PS: I can send the file if it would help.</p>
413
              <p>$ du -h blog.bug.xml<br>
414
                2,8G blog.bug.xml<br>
415
                $ java -jar /usr/local/bin/saxon9he.jar -xsl:empty.xsl
416
                blog.bug.xml &gt; bug.vert<br>
417
                java.lang.ArrayIndexOutOfBoundsException: -32768<br>
418
                at
419
net.sf.saxon.tree.tiny.LargeStringBuffer.append(LargeStringBuffer.java:90=
420
)<br>
421
                at
422
                net.sf.saxon.tree.tiny.TinyTree.appendChars(TinyTree.java=
423
:405)<br>
424
                at
425
                net.sf.saxon.tree.tiny.TinyBuilder.makeTextNode(TinyBuild=
426
er.java:380)<br>
427
                at
428
                net.sf.saxon.tree.tiny.TinyBuilder.characters(TinyBuilder=
429
.java:362)<br>
430
                at
431
net.sf.saxon.event.ReceivingContentHandler.flush(ReceivingContentHandler.=
432
java:544)<br>
433
                at
434
net.sf.saxon.event.ReceivingContentHandler.endElement(ReceivingContentHan=
435
dler.java:435)<br>
436
                at
437
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(A=
438
bstractSAXParser.java:609)<br>
439
                at
440
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.sc=
441
anEndElement(XMLDocumentFragmentScannerImpl.java:1782)<br>
442
                at
443
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$Fr=
444
agmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2973)<br>
445
                at
446
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDo=
447
cumentScannerImpl.java:606)<br>
448
                at
449
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XML=
450
NSDocumentScannerImpl.java:117)<br>
451
                at
452
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.sc=
453
anDocument(XMLDocumentFragmentScannerImpl.java:510)<br>
454
                at
455
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11=
456
Configuration.java:848)<br>
457
                at
458
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11=
459
Configuration.java:777)<br>
460
                at
461
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java=
462
:141)<br>
463
                at
464
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Abstra=
465
ctSAXParser.java:1213)<br>
466
                at
467
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse=
468
(SAXParserImpl.java:649)<br>
469
                at
470
                net.sf.saxon.event.Sender.sendSAXSource(Sender.java:440)<=
471
br>
472
                at net.sf.saxon.event.Sender.send(Sender.java:171)<br>
473
                at
474
                net.sf.saxon.Controller.transform(Controller.java:1690)<b=
475
r>
476
                at
477
                net.sf.saxon.s9api.XsltTransformer.transform(XsltTransfor=
478
mer.java:547)<br>
479
                at
480
                net.sf.saxon.Transform.processFile(Transform.java:1056)<b=
481
r>
482
                at
483
                net.sf.saxon.Transform.doTransform(Transform.java:659)<br=
484
>
485
                at net.sf.saxon.Transform.main(Transform.java:80)<br>
486
                Fatal error during transformation:
487
                java.lang.ArrayIndexOutOfBoundsException: -32768</p>
488
              <script type=3D"application/ld+json">
489
{
490
  "@context": <a class=3D"moz-txt-link-rfc2396E" href=3D"http://schema.or=
491
g">"http://schema.org"</a>,
492
  "@type": "EmailMessage",
493
  "action": {
494
    "@type": "ViewAction",
495
    "url": <a class=3D"moz-txt-link-rfc2396E" href=3D"https://saxonica.pl=
496
an.io/issues/2271#change-3874">"https://saxonica.plan.io/issues/2271#chan=
497
ge-3874"</a>,
498
    "name": "View on Planio"
499
  },
500
  "description": "Click here to view this issue update on Planio."
501
}
502
</script></td>
503
          </tr>
504
          <tr>
505
            <td style=3D"font-size:0.8em;width:100%;">
506
              <hr>
507
              <p>You have received this notification because you have
508
                either subscribed to or are involved in a project on
509
                Saxonica Developer Community site.<br>
510
                To change your notification preferences, please click
511
                here: <a moz-do-not-send=3D"true" class=3D"external"
512
                  href=3D"https://saxonica.plan.io/my/account">https://sa=
513
xonica.plan.io/my/account</a></p>
514
            </td>
515
            <td><br>
516
            </td>
517
          </tr>
518
          <tr>
519
            <td style=3D"font-family: MarketWeb, Verdana,
520
              sans-serif;font-size:1.2em;text-align:center;width:100%;col=
521
or:#D7D7D7;"><br>
522
              <div><a moz-do-not-send=3D"true" href=3D"https://plan.io/"
523
                  style=3D"color:#D7D7D7;text-decoration:none;">This
524
                  notification was cheerfully delivered by</a></div>
525
            </td>
526
            <td><br>
527
            </td>
528
          </tr>
529
          <tr>
530
            <td style=3D"text-align:center;width:100%;"><a
531
                moz-do-not-send=3D"true" href=3D"https://plan.io/"
532
                title=3D"Planio"><img moz-do-not-send=3D"true"
533
                  src=3D"https://assets.plan.io/images/planio_logo_gray_2=
534
04x50.png"
535
                  alt=3D"Planio" style=3D"vertical-align: middle;"
536
                  height=3D"25" width=3D"102"></a></td>
537
          </tr>
538
        </tbody>
539
      </table>
540
    </blockquote>
541
    <br>
542
  </body>
543
</html>
544

    
545
--------------020308060604080408010703--
    (1-1/1)