one workaround would be to predeclare DEBUG_VERB_1..DEBUG_VERB_6, for instance.
On Sat, Mar 28, 2009 at 5:06 PM, Avinash Lakshman <[email protected]> wrote: > For debugging purposes we dynamic register verb handlers with the servers to > get certain kinds of information that would be of interest. I do not know > how we could do the same with enums. Maybe there is some esoteric way, that > I am not aware of, to achieve this. Basically we stick in an entry to the > map of registered verb handlers where the key is a string. > Avinash > > On Sat, Mar 28, 2009 at 11:47 AM, Jonathan ellis <[email protected]> wrote: > >> My problem is I am severely allergic to boilerplate code. :) But it does >> sound like the thrift idea isn't going to work. >> >> What about the tangential idea of using enums for handler type instead of >> strings? >> >> -Jonathan >> >> >> On Mar 28, 2009, at 12:49 PM, Avinash Lakshman <[email protected]> >> wrote: >> >> Given that we need super control over the serialization process in some >>> conditions and do not any in most other situations I am not sure what is >>> the >>> best solution here. Maybe a hybrid and that would be crazy. Fundamentally >>> I >>> think this is a triviality and this mechanism is really brain dead simple. >>> Your point about tests is very very well taken. In our defense if we had >>> religiously written tests I do not think we would have been where we are >>> w.r.t to where the system is now :). We have a slew of tests that we do >>> have >>> but they are super well written but rather ad-hoc and I do not mean the >>> main() that you see in most other places. >>> Avinash >>> >>> On Sat, Mar 28, 2009 at 10:39 AM, Avinash Lakshman < >>> [email protected]> wrote: >>> >>> For eg Thrift will definitely not help in the messages that we use for >>>> the >>>> membership protocol. Because there we need to control how big the >>>> serialized >>>> messages are - we make sure we serialize a part of the object such that >>>> it >>>> fits into an ethernet MTU packet. We do this so that we don't get bitten >>>> by >>>> UDP fragmentation. I don't think you could do operations like that in >>>> Thrift >>>> based serialization mechanism. We need more control over the >>>> serialization >>>> mechanism. >>>> >>>> So I don't know if this is something that is insanely important in any >>>> capacity in my opinion. I am sure there are bunch of other reasons I can >>>> come up with - we went through this exercise 2 year back. Of course if >>>> you >>>> want to investigate the efficacy I can't stop you from doing so :). >>>> >>>> Avinash >>>> >>>> >>>> On Sat, Mar 28, 2009 at 9:48 AM, Jonathan Ellis <[email protected]> >>>> wrote: >>>> >>>> One point of clarification -- I don't understand why looking up by >>>>> string is better than using an enum, for instance. java will autobox >>>>> enums for use in a hashmap lookup. >>>>> >>>>> On Sat, Mar 28, 2009 at 10:34 AM, Avinash Lakshman >>>>> <[email protected]> wrote: >>>>> >>>>>> Why is it ad-hoc? And it uses a factory pattern and I don't think it >>>>>> >>>>> hard >>>>> >>>>>> once you get a hang of it. Consumers of the system are not even going >>>>>> to >>>>>> know about these details. Personally I am never a fan of fixing >>>>>> anything >>>>>> that is not broken - in this case it has been working really well for >>>>>> >>>>> us. >>>>> >>>>>> This is now just a matter of what one might prefer. Thrift is something >>>>>> >>>>> that >>>>> >>>>>> I would not like to see anywhere apart from the entry point. With >>>>>> >>>>> regards to >>>>> >>>>>> the using the string to lookup the handlers it was done because if you >>>>>> >>>>> don't >>>>> >>>>>> do that then you will have to resort to RPC style instead of message >>>>>> >>>>> passing >>>>> >>>>>> or find the handlers based on the kind of messages i.e if-else >>>>>> >>>>> branching. We >>>>> >>>>>> use non-blocking I/O for all our internal messaging and Thrift using >>>>>> blocking I/O. There is big difference in throughput and also Thrift >>>>>> non-blocking I/O from what I hear is horrendous in performance and >>>>>> stability. My friend you don't have my vote for this :). >>>>>> Avinash >>>>>> >>>>>> On Sat, Mar 28, 2009 at 8:11 AM, Jonathan Ellis <[email protected]> >>>>>> >>>>> wrote: >>>>> >>>>>> >>>>>> we have a Message class that mostly represents a bunch of bytes (but >>>>>>> sometimes does not, which in some cases causes bugs) and a bunch of >>>>>>> other *Message classes that are not Message subclasses but generate >>>>>>> Message objects (so you have the amusingly redundant Message message = >>>>>>> readResponseMessage.makeReadResponseMessage() in places). >>>>>>> >>>>>>> I think we can replace these ad-hoc and tedious-to-write Message >>>>>>> factories with generated thrift code. Thrift is good at this and >>>>>>> efficient (currently our message identifiers are inefficient strings >>>>>>> like "ROW-READ-VERB-HANDLER"). >>>>>>> >>>>>>> Any objections to investigating replacing the hand-coded messages with >>>>>>> thrift? >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >
