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 <[email protected]> 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 / [email protected]
>
> On Tue, Mar 20, 2018 at 12:05 PM, Anthony Dahanne <
> [email protected]> 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 <[email protected]>
>> 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 / [email protected]
>>>
>>> On Mon, Mar 19, 2018 at 7:13 PM, Anthony Dahanne <
>>> [email protected]> 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 !
>>>> 4.x line : http://svn.terracotta.org/svn/tc/dso/trunk/
>>>> 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?*
>>>>>
>>>>
>>>> There it is : http://svn.terracotta.org/svn/
>>>> tc/dso/trunk/deploy/src/main/java/com/tc/server/TerracottaCo
>>>> nnector.java
>>>>
>>>> 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 <[email protected]>
>>>> 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.
>>>>>
>>>>> unix socket example code: https://github.com/eclipse/jet
>>>>> ty.project/tree/jetty-9.4.x/jetty-unixsocket/src/main/java/o
>>>>> rg/eclipse/jetty/unixsocket
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Joakim Erdfelt / [email protected]
>>>>>
>>>>> On Mon, Mar 19, 2018 at 3:46 PM, Anthony Dahanne <
>>>>> [email protected]> 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
>>>>>> [email protected]
>>>>>> 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
>>>>> [email protected]
>>>>> 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
>>>> [email protected]
>>>> 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
>>> [email protected]
>>> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
