Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Migrating custom Connector from 8.1 to 9.4
Hello again Joakim,
with some help, I could move forward , yay !
So why I ended up doing is make my TerracottaConnector extend LocalConnector and then read from the socket a String (basically the HTTP request forwarded by the Terracotta Server), and pass it to the LocalConnector getResponse().
Then, I retrieve the response, write it to the socket and flush it.
In code terms, it's more or less :

public class TerracottaConnector extends LocalConnector {
  public void handleSocketFromDSO(Socket s, byte[] data) throws IOException {

    PushbackInputStream pis = new PushbackInputStream(s.getInputStream(), data.length);
    pis.unread(data);
    InputStreamReader inputStreamReader = new InputStreamReader(pis);
    BufferedReader bufferedReader = new BufferedReader(inputStreamReader);
    String readLineFromBuffer = bufferedReader.readLine();
    StringWriter writer = new StringWriter();
    do {
      writer.write(readLineFromBuffer);
      writer.write("\r\n");
      readLineFromBuffer = bufferedReader.readLine();
    }
    while (!readLineFromBuffer.equals(""));
    writer.write("\r\n");

    String theString = writer.toString();

    try {
      String response = this.getResponse(theString);
      s.getOutputStream().write(response.getBytes("UTF-8"));
    } catch (Exception e) {
      e.printStackTrace();
    } finally {
      s.getOutputStream().flush();
    } 
  }
}


It's not perfect, since I had to change some servlets (although we don't have many anyway) to specifically close the connection, and prevent jetty to chunk the output :

OutputStream out = response.getOutputStream();
int bytesCopied = IOUtils.copy(documentToSend.newInputStream(), out);
response.setHeader("Connection", "close");
response.setContentLength(bytesCopied);
response.flushBuffer();


But I think that's a start.

To answer your previous questions :

> How do you handle the HTTP persistence layer?
I don't think we do

> Do you have any plans to support HTTP/2?
no

> Do you expect Jetty to handle the HTTP conversation entirely on from the active connection?
> (parsing the request headers + body contents, generating the response headers + body contents)?
Yes, this is what we use Jetty for : the Terracotta Server found out the request is HTTP, it passes the socket to Jetty and expects Jetty to finish dealing with it.

> Is it possible to have a non-HTTP request after the active HTTP request on the same connection?
I don't think so, it's OK if a new connection is opened after the HTTP exchange.

Thanks again for all your help.
I have other parts of the system to migrate, but this one was clearly the most perilous...
I also need to figure out if LocalConnector is the best candidate.

Anthony


On Tue, Mar 20, 2018 at 1:10 PM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
How do you handle the HTTP persistence layer?
Do you have any plans to support HTTP/2?
Do you expect Jetty to handle the HTTP conversation entirely on from the active connection? 
(parsing the request headers + body contents, generating the response headers + body contents)?
Is it possible to have a non-HTTP request after the active HTTP request on the same connection?


Joakim Erdfelt / joakim@xxxxxxxxxxx

On Tue, Mar 20, 2018 at 12:05 PM, Anthony Dahanne <anthony.dahanne@xxxxxxxxx> wrote:
right.
the connection can be ssl, non secured terracotta comm. layer or http 

On Tue, Mar 20, 2018 at 8:47 AM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
Taking a look at your code ...

It appears that you have existing connections, presumable established earlier, outside of Jetty, in a Terracotta specific component (that I cannot locate).

Occasionally(?) a request on that established connection arrives which isn't handled by Terracotta, but is actually a HTTP (style? actual?) request that needs to be handed off to Jetty to process.

Is that right?


Joakim Erdfelt / joakim@xxxxxxxxxxx

On Mon, Mar 19, 2018 at 7:13 PM, Anthony Dahanne <anthony.dahanne@xxxxxxxxx> wrote:
Hey there,
Thanks for your answer !

Welcome to the new world of connectors and web protocols! :-)

Yay ! :-)
 
Is this the same Terracotta that used to be open source?
Yes it is ! And it still is actually !
10.x line : https://github.com/Terracotta-OSS/terracotta-core , not using jetty anymore though :-(

If so, where is the code that implements your old TerracottaConnector?


I'll try your advice out, and keep you updated !
Thanks for your explanations !
Anthony



On Mon, Mar 19, 2018 at 5:27 PM, Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
Welcome to the new world of connectors and web protocols! :-)

Is this the same Terracotta that used to be open source?
If so, where is the code that implements your old TerracottaConnector?

Is that a java.net.Socket I see?
It's important to point out that there are no traditional BIO facilities or support in Jetty 9.
Jetty is 100% async/java.nio now.

You'll first need to implement a java.nio endpoint suitable for Jetty.
Ultimately it will be an implementation of org.eclipse.jetty.io.EndPoint.
But seeing the Socket in your example code snippet, you'll probably want some basic networking support.
So start with implementing a TerracottaEndPoint that extend org.eclipse.jetty.io.ChannelEndPoint

This TerracottaEndPoint will be important regardless of the next steps.

Basic implementation ...

Then try simply extending ServerConnector and providing an implementation of
protected ChannelEndPoint newEndPoint(SocketChannel channel, ManagedSelector selectSet, SelectionKey key) throws IOException
that returns your TerracottaEndPoint instance.

Alternate approach ...

You might want a network that isn't quite a network connector.
If so, you might want to use the code examples found in our UnixSocket support layer.
Note: you'll still need the above mentioned TerracottaEndPoint.





Joakim Erdfelt / joakim@xxxxxxxxxxx

On Mon, Mar 19, 2018 at 3:46 PM, Anthony Dahanne <anthony.dahanne@xxxxxxxxx> wrote:
Hello Jetty experts,
First, I apologize if it's not the appropriate mailing list for this question (I was hesitating with jetty-dev) , but there is my question : what's the preferred path to migrate a custom connector from 8.1 to 9.4 ?
Here's what I used to do : a cusotm connector that could understand HTTP, TC protocol, and SSL

TCServerImpl.this.terracottaConnector = new TerracottaConnector(TCServerImpl.this.configurationSetupManager.getSecurity() != null);
TCServerImpl.this.terracottaConnector.setName(CONNECTOR_NAME_TERRACOTTA);

----
public class TerracottaConnector extends SocketConnector {
  private final boolean secure;
  private boolean shutdown = false;
  public TerracottaConnector(boolean secure) {
    this.secure = secure;
  }

  public void handleSocketFromDSO(Socket s, byte[] data) throws IOException {
    ConnectorEndPoint connection = new ConnectorEndPoint(new SocketWrapper(s, data));
    connection.dispatch();
  }
etc.
}
----

I've read the new architecture document : https://www.eclipse.org/jetty/documentation/9.4.x/architecture.html but I'm still hitting my head on what to use, and if there were examples that are doing what I used to do (even if it's pretty clear from the architecture document that this use case is definitely supported)

I've tried extending the ServerConnector instead, but doing so , I could not find the right API to handle a raw socket and raw bytes (Handlers are are about HTTPRequest, so I guess I should stick to the ServerConnector...)
Anyway, if you have examples with custom ServerConnector, I'd be very thankful if you could point them out !
Thanks in advance !
Anthony

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

Back to the top