Subject: Re: [xml2rfc] Large I-D and large artwork

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 02 Jul 2018 18:22:55 +0200

This time draft-faltstrom-unicode11.

On 27 Jun 2018, at 23:06, Henrik Levkowetz wrote:

>> This creates timeouts both in the submission tool and ID-nit tool. Requires me to fall back to manual submission (which worked).
>
> Huh.  I'll have to spend some debugging time on that; a trial conversion
> shows an xml2rfc conversion time of 2.16 seconds, which does not seem
> objectionable in itself.  The hiccup is somewhere else.

Hmm...my Chrome says:

> Gateway Timeout
> The gateway did not receive a timely response from the upstream server or application.

And this after much more than 2.16 seconds.

I do a reload, and get:

> A submission with same name and revision is currently being processed. Check the status here.

When I "check the status" I see among other things:

> Pages	78
> File size	0 bytes
> Formal languages used	None recognized

Did click "Request full access URL"

When there, I could click on my name, get confirmation and the I-D was posted.

So no manual processing needed. Just an additional confirmation.

   Patrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 2 Jul 2018 23:05:58 +0200

Ok, I've identified the issue.  What takes time is the first time through
idnits processing.  During the preprocessing stage, a very simplified
parser tries to extract all 4-digit numbers, in case they are RFC numbers,
and then goes and fetches xml state files for each of those to cache, in
order to be able to look up things like standards levels to check downref
status, etc.

If there is a lot of 4-digit numbers that haven't been seen during the last
24 hours, that is going to take a looong time.

Once idnits' cache is up-to-date, I see reasonable response times.

Now, with idnits due for a total rewrite within the next few months, I'm not
going to fix up the old code, but I'm sorry for the extra trouble this has
caused, and I'll make sure that the rfc state handling and the parsing
avoids this issue in the rewrite.

Best regards,

	Henrik

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 2 Jul 2018 23:29:33 +0200

> On 2 Jul 2018, at 23:05, Henrik Levkowetz <[email-masked]> wrote:
> 
> tries to extract all 4-digit numbers, in case they are RFC numbers

Aha, and in this case they are a gazillion Unicode code points!

😳

   Patrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 3 Jul 2018 00:19:54 +0200

> Aha, and in this case they are a gazillion Unicode code points!

Exactly ,:-}

	Henrik

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 2 Jul 2018 18:26:22 -0400

>>> tries to extract all 4-digit numbers, in case they are RFC numbers

What are you going to do when there are five digit RFC numbers?

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 03 Jul 2018 00:33:01 +0200

> On 3 Jul 2018, at 00:26, Paul Kyzivat <[email-masked]> wrote:
> 

By then the rewrite will be in place.

I wrote the current code around the time of RFC 3300 or so, I think.

    Henrik

> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc