On Wed, Jan 2, 2013 at 2:34 PM, Elliott Clark wrote:
> Removing the versioning altogether seems good. That leads to much less
> coupling between the client and the server.
>
> I would vote to use BlockingInterface (to replace our versioned protocol
> class) everywhere and just write our own rpc/
Removing the versioning altogether seems good. That leads to much less
coupling between the client and the server.
I would vote to use BlockingInterface (to replace our versioned protocol
class) everywhere and just write our own rpc/ipc. Stack walked me through
some of the code that is needed fo
On Thu, Dec 27, 2012 at 7:11 PM, Stack wrote:
> Not knowing much about the recent changes, why don't we go full PB, and
>> define actual rpc methods as services? (as in
>> https://developers.google.com/protocol-buffers/docs/proto#services)
>>
>>
> I thought about it. It has some nice facility t
On Fri, Dec 28, 2012 at 8:59 AM, Stack wrote:
> On Fri, Dec 28, 2012 at 1:31 AM, Devaraj Das wrote:
>
> > Now thinking more about it, if a server implements a method more
> > efficiently, we probably could have new fields in the method argument to
> > indicate the client is willing to accept the
On Fri, Dec 28, 2012 at 1:31 AM, Devaraj Das wrote:
> Now thinking more about it, if a server implements a method more
> efficiently, we probably could have new fields in the method argument to
> indicate the client is willing to accept the new semantics. A new server
> could detect that (by chec
Now thinking more about it, if a server implements a method more
efficiently, we probably could have new fields in the method argument to
indicate the client is willing to accept the new semantics. A new server
could detect that (by checking for existence of such a field), and an old
server would s
On Thu, Dec 27, 2012 at 5:37 PM, Enis Söztutar wrote:
> I think what Devaraj describes is a valid use case, and I am sure we will
> need it a few times. However, I suspect each of these might be unique, and
> we have to deal with how to handle backwards-forwards compat from the
> client different
I think what Devaraj describes is a valid use case, and I am sure we will
need it a few times. However, I suspect each of these might be unique, and
we have to deal with how to handle backwards-forwards compat from the
client differently (image META moving to zk, after 0.96). So we cannot
easily ge
+1 for removing VersionedProtocol and SignatureProtocol
+0 for VersionedService/ProtocolDescriptor
If we do have VersionedService/ProtocolDesscriptor, it will most likely be
used in some
mixed environment (most likely, new client and mixed versions of HBase
servers, since old client doesn't
know a
So, picking up this thread again because I'm working on
https://issues.apache.org/jira/browse/HBASE-6521 "
Address the handling of multiple versions of a protocol"Address the
handling of multiple versions of a protocol", the original question was
two-fold as I read it.
1. Should we keep Versioned
Responses inline..
> On Wed, Aug 1, 2012 at 11:04 AM, Todd Lipcon wrote:
>> One possibility:
>>
>> During the IPC handshake, we could send the full version string /
>> source checksum. Then, have a client-wide map which caches which
>> methods have been found to be supported or not supported for
I like the idea of "getServerCapabilities()" as a bitset.
- Andy
On Wed, Aug 1, 2012 at 11:04 AM, Todd Lipcon wrote:
> One possibility:
>
> During the IPC handshake, we could send the full version string /
> source checksum. Then, have a client-wide map which caches which
> methods have been
One possibility:
During the IPC handshake, we could send the full version string /
source checksum. Then, have a client-wide map which caches which
methods have been found to be supported or not supported for an
individual version. So, we don't need to maintain the mapping
ourselves, but we also w
On Tue, Jul 31, 2012 at 1:47 AM, Devaraj Das wrote:
> Wondering whether we should retain the VersionedProtocol now that we have
> protobuf implementation for most (all?) of the protocols. I think we still
> need the version checks and do them when we need to. Take this case:
> 1. Protocol Foo ha
I looked at TestMultipleProtocolServer.java from hadoop trunk.
It illustrates how VersionedProtocol is used for client to talk to servers
running various versioned protocols.
FYI
On Mon, Jul 30, 2012 at 8:11 PM, Ted Yu wrote:
> If v3 of the method emerges, we might need to retry twice, right ?
If v3 of the method emerges, we might need to retry twice, right ?
Cheers
On Mon, Jul 30, 2012 at 8:09 PM, Jimmy Xiang wrote:
> Another approach is to use the new call at first. If got some
> exception like unknown method, then fall back to the old method.
>
> Thanks,
> Jimmy
>
> On Mon, Jul 3
Another approach is to use the new call at first. If got some
exception like unknown method, then fall back to the old method.
Thanks,
Jimmy
On Mon, Jul 30, 2012 at 5:47 PM, Devaraj Das wrote:
> Wondering whether we should retain the VersionedProtocol now that we have
> protobuf implementation
Wondering whether we should retain the VersionedProtocol now that we have
protobuf implementation for most (all?) of the protocols. I think we still need
the version checks and do them when we need to. Take this case:
1. Protocol Foo has as one of the methods FooMethod(FooMethodRequest).
2. Proto
18 matches
Mail list logo
