... another option would be to have a HashMap<Integer, IVerbHandler> and then registerVerbHandler would put(enum.ordinal(), verbhandler). Then you could inject any int you like as a key.
Personally I think predeclaring some debug enums is a little more readable but my preference is not strong. -Jonathan On Sat, Mar 28, 2009 at 7:15 PM, Jonathan Ellis <[email protected]> wrote: > 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? >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >> >
