Internal https connector & clap protocol deadlock?

[gitblit]

I'm having trouble with the internal 2.1-SNAPSHOT/RC5 https connector combined with the clap protocol - large embedded resources (100k css file) seem to deadlock and are never retrieved - the browser times-out after 1 min and then displays unstyled representation/content. Oddly, the internal http connector works fine. I launch both http & https connectors in the same process - https never/intermittently serves the css, http does.

I'm not sure if this is related to issue-576. I can provide a live example of my issue which can be monitored using Chrome developer tools, if a Restlet dev private-messages me for the urls.

[thboileau]

Hello James, I've tried with a sample css file (500ko) and it works fine for me. Can you provide me a sample test code? (thierry{dot}boileau{at}restlet{dot}com).

[gitblit]

The latest 2.1 snapshot (20120725.141221) is massively unusable for both the http and https internal connectors. Without changing my code (just updating to latest snapshot) both connectors are now hanging and timing out even on Linux where I didn't have any trouble before.

[jlouvel]

Thanks for the feed-back. We are aware of this issue as Thierry is developping on Linux as well. On Windows they work great and even better than before thanks to some bug fixes. We now need to fix the remaining issue affecting Linux before 2.1 RC7. Help welcome (but this is complex non-blocking NIO stuff).

[gitblit]

"On Windows they work great and even better than before". I really want that to be true. Maybe I am using them wrong - but they are equally unusable on Win7/64-bit; perhaps even worse. They never respond. I have no doubt that this is quite complex code. Thanks for taking the time to look at this.

[jlouvel]

Are you doing load tests? Last time I tested them I was able to pass the whole Restlet test suite with them. Maybe there is a regression. I'll check that soon.

[gitblit]

No, my test load is 1 browser and one page request to my app. It does
seem that if you bind the connector to an address it has less trouble.
But it still has trouble even with the one address.

If I run RC5 it processes http fine. Https is hit-or-miss.
If I run SNAPSHOT it (just about) never processes http or https anymore.

[jlouvel]

Thanks for the precision, this must be due to the browser HTTP stack which issue HTTP calls differently. I'll debug this using FF/IE/Chrome on Win7/64 first as it is easier for me.

Cheers,
Jerome

-----Message d'origine-----
De : James Moger [mailto:reply@reply.github.com]
Envoyé : vendredi 27 juillet 2012 23:57
À : Jerome Louvel
Objet : Re: [restlet-framework-java] Internal https connector & clap protocol deadlock? (#620)

No, my test load is 1 browser and one page request to my app. It does seem that if you bind the connector to an address it has less trouble.
But it still has trouble even with the one address.

If I run RC5 it processes http fine. Https is hit-or-miss.
If I run SNAPSHOT it (just about) never processes http or https anymore.

---

Reply to this email directly or view it on GitHub:
#620 (comment)

[jlouvel]

We've made progress on this front over the past few days:

• their was a fix missing in the 2.1 branch compared to the 2.2/master branch that was causing indeed serious issues
• we have fixed an additional blocking issue in both 2.1 and 2.2 branches

There still appears to have HTTPS issues with the internal connectors. We are looking into this next.

[gitblit]

Awesome. I looked over your commit. Big changes. :)

[gitblit]

I confirm the return of usability of http with the August 13 snapshot. Hooray!
I also confirm that https is still problematic.

Assuming you resolve the https issue, how would you categorize the internal connectors for the 2.1 release? Pre-2.1 I think I read Restlet considered them suitable for testing only. But I thought I read somewhere that Restlet will consider the 2.1 connectors production-quality. Do you expect that to be the case or will you still recommend running Jetty underneath?

[jlouvel]

Thanks for following closely this issue. We indeed need to fix remaining HTTPS issues but we are now close.

Regarding stability, we haven't done extensive load tests yet, so we won't recommend 2.1 internal connectors for heavy production load initially. That may change over the 2.1 life cycle with additional bug fixing releases and benchmarks.

[jlouvel]

FYI, I just fixed a regression in the internal NIO connector that will be part of 2.1.1 version.

[jlouvel]

We decided to replace the internal connector and move the still unstable NIO connector to an extension. See changes log:

  - Moved org.restlet.ext.net HTTP/HTTPS/FTP client connectors into the core
    org.restlet module (org.restlet.engine.net package) as the new internal
    client connectors.
  - Moved NIO-based internal connector to new org.restlet.ext.nio extension.
    Marked as "developer preview" state.
  - Added new internal HTTP/HTTPS server connectors based on the 
    com.sun.net.httpserver package available in JDK 6. Issue #381.
  - Moved org.restlet.ext.ssl into core org.restlet.engine.ssl package except
    classes related to the jSSLutils library now part of new org.restlet.ext.jsslutils
    extension and for CertificateAuthenticator class now in org.restlet.security.

This should solve the stability issues that occured with both HTTP and HTTPS server and client internal connectors bundled in org.restlet.jar.

[jlouvel]

I'm setting the milestone to 2.2.0. Once this version is released and marked as the new "stable", 2.1 branch support will be deprecated.

@gitblit it would be great if you could try 2.2 RC1 released tomorrow to ensure that the new internal HTTPS connector solves this issue. It should definitely as it is based on the stable HTTP/HTTPS lightweight server part of JavaSE 6.