[infinispan-issues] [JBoss JIRA] (ISPN-5357) Hot Rod protocol 3.0
[
https://issues.jboss.org/browse/ISPN-5357?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-5357:
----------------------------------------
Couple of ideas:
* Header and body lengths:
With async clients such as Node-based clients, it could be possible that the buffer with
the data might contain incomplete data. To help coding of such clients, it'd be good
to have both a header size and data size baked into the messages, so that the client can
know if the entire header can be read, and once that's read, whether all the data can
be read. This would make it much easier to figure out if data has to be buffered compared
to current approach which requires at each element read, whether that element has been
read completely.
* Aeron protocol for ideas:
Aeron sends/receives messages and it's
[protocol|https://github.com/real-logic/Aeron/wiki/Protocol-Specification] has some
interesting ideas in how to layer it. Although the message sizes are bigger, the protocol
has been designed with the design principles of SBE, see
[here|https://github.com/real-logic/simple-binary-encoding/wiki/Design-Pri...].
Hot Rod protocol 3.0
--------------------
Key: ISPN-5357
URL: https://issues.jboss.org/browse/ISPN-5357
Project: Infinispan
Issue Type: Enhancement
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 9.0.0.Final
*UPDATE (6/10/2015)*: Hot Rod 3.0 could become a HTTP REST protocol taking advantage of
existing infrastructure to deal with HTTP requests efficiently, and if it was based on
HTTP 2.0, we could have binary data inside of it. Performance should be on par. Text mode
could be available for debug or demos. This essentially would mean REST and Hot Rod would
merge into one.
A binary protocol rethink is needed to take better advantage of CPUs and buffering. This
is based on the ideas of Martin Thompson's Simple Binary Encoding [blog
post|http://mechanical-sympathy.blogspot.cz/2014/05/simple-binary-encoding.html]
In essence, we need to move Hot Rod protocol towards having mostly fixed size fields,
hence getting rid of `vInt` and `vLong` formats which although safe some bytes, they
hinder long stream reading patterns.
An optional part here would be whether to consider using SBE directly, but this JIRA
should be mostly oriented at making sure we have a protocol that can be read fast and
efficiently.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)