Re: Securing client to cassandra communication?

[Bjørn Borud <bb...@gmail.com>]

added CC to the dev@thrift.apache.org list

On Tue, Nov 30, 2010 at 3:55 AM, Nate McCall <na...@riptano.com> wrote:

> There was some work done at the thrift level for ssl support recently
> (@jeromatron, do you have the info on this?) which would be helpful.
>

speaking of networking and ssl.  lately I have been implementing a logging
system that uses protobuffers as message envelopes and a framed transport to
stream messages to the log server (*).

I first had a look at Apache Mina, and then had a look at Netty.  Netty
seemed to be the better alternative since it has a somewhat cleaner design
and seems to be more actively worked on.

not only did the code end up being relatively minimal, but it turns out to
be *trivial* to add things like SSL support, compression, other transports
etc.  I am usually very critical to adding dependencies willy-nilly, but
given that, I think that in this case, thrift could actually benefit greatly
from making use of Netty rather than maintaining its own IO code.  you do
get a *lot* for free by using Netty.


(*) yes, I am aware of several log servers that are out there, but the ones
I have looked at are either too complex, too buggy or lack some design
aspects that I want in a log server.  it is likely that I will open source
the log server at some point. (I wrote a log server ~5 years ago that is
still in use at ... some fairly huge web properties.  unfortunately I was
never able to open source it.  besides:  times have changed and there are
some things I'll be doing differently this time around.


-Bjørn

Re: Securing client to cassandra communication?

[Bjørn Borud <bb...@gmail.com>]

On Tue, Nov 30, 2010 at 3:04 PM, Edward Capriolo <ed...@gmail.com>wrote:

> Not trying to critisize your netty decision. One thing I have found
> about netty is has been version incompatasble between releases. We use
> hornetq with netty transports (built in) it was vey frustrating that
> the netty protocol was not compatible between hq 2.0 and 2.1, meaning
> our options were to upgrade all our software and hq at one time, or
> switch to the jms transport which made little sense because we chose
> hq and netty because of how fast and efficient it was via netty.
>

well, netty is an IO library so it has no "protocol" as such, though it does
_provide_ certain codec and handler implementations that you can use.

indeed, I am making use of a couple of the codecs in my application, but the
codecs are so trivial (if you look at the source of the
varint-encoder/decoder and the protobuf-stuff, it isn't really complex or
big at all) that just maintaining my own implementation wouldn't be much of
a problem.  (which I might decide to do now that you have given me a heads
up.  thanks for that! :-) )

hmm, or did you talk about API breakage?

-Bjørn
-- 
Bjørn Borud <bb...@gmail.com>
+47 920 46465

Re: Securing client to cassandra communication?

[Edward Capriolo <ed...@gmail.com>]

On Tuesday, November 30, 2010, Bjørn Borud <bb...@gmail.com> wrote:
> added CC to the dev@thrift.apache.org list
> On Tue, Nov 30, 2010 at 3:55 AM, Nate McCall <na...@riptano.com> wrote:
> There was some work done at the thrift level for ssl support recently (@jeromatron, do you have the info on this?) which would be helpful.
>
> speaking of networking and ssl.  lately I have been implementing a logging system that uses protobuffers as message envelopes and a framed transport to stream messages to the log server (*).
>
> I first had a look at Apache Mina, and then had a look at Netty.  Netty seemed to be the better alternative since it has a somewhat cleaner design and seems to be more actively worked on.
> not only did the code end up being relatively minimal, but it turns out to be *trivial* to add things like SSL support, compression, other transports etc.  I am usually very critical to adding dependencies willy-nilly, but given that, I think that in this case, thrift could actually benefit greatly from making use of Netty rather than maintaining its own IO code.  you do get a *lot* for free by using Netty.
>
>
> (*) yes, I am aware of several log servers that are out there, but the ones I have looked at are either too complex, too buggy or lack some design aspects that I want in a log server.  it is likely that I will open source the log server at some point. (I wrote a log server ~5 years ago that is still in use at ... some fairly huge web properties.  unfortunately I was never able to open source it.  besides:  times have changed and there are some things I'll be doing differently this time around.
>
>
> -Bjørn
>

Not trying to critisize your netty decision. One thing I have found
about netty is has been version incompatasble between releases. We use
hornetq with netty transports (built in) it was vey frustrating that
the netty protocol was not compatible between hq 2.0 and 2.1, meaning
our options were to upgrade all our software and hq at one time, or
switch to the jms transport which made little sense because we chose
hq and netty because of how fast and efficient it was via netty.