[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: New wireformat and client side remoting

[jmesnil]

"timfox" wrote : 
  | Can targetID and callback id be longs (or ints?) too?
  | 
  | I'm thinking that Java guids are pretty long, and we want to keep the packets as small as possible - maybe I'm being over conservative though...
  | 

I went for convenience in the API and using Strings for the IDs makes it possible to use Java 5 UUID and get rid of all the complexity we got from generating our own IDs (as planned by http://jira.jboss.org/jira/browse/JBMESSAGING-1040).

However you're right that it increases the size of the packet by doing so.
Depending on the payload of the packet, it may be negligible... or not.

For now, I'd keep the String ID and flag it as an area of optimization.

anonymous wrote : 
  | Do connect and disconnect really belong on the RemotDispatcher?
  | 

Not really :)
The RemoteDispatcher corresponds to both JBM 1.4.x Dispatcher (register/unregister) & JBoss Remoting Client (connect/disconnect/send).
Given the simplicity of the API, I keep the functions together in a single type but conceptually they belong to 2 different types.
As complexity grows, I'll likely refactor it.

anonymous wrote : 
  | Three different ways to exchange packets - the second way (e.g. send non persistent message) - in fact, non persistent messages can be fire and forget - non blocking request / response is not supported using the JMS API but is very useful for doing stuff over and above JMS which we can expose through the generic interface.
  | 

I'm not sure to follow you: we need to support blocking req/resp for some of our operations (e.g session creation), don't we?

anonymous wrote : 
  | responses via HTTP - is this done by keeping the http connection open and sending responses that way? I can't see it work otherwise without polling.
  | 

That's the way it seems to work: the connection corresponds to a Keep-Alive HTTP connection (kinda...)
I'm still not 100% clear on HTTP support: I'm able to use curl and firefox to send and receive on HTTP & HTTPS but ab is not working for now...

anonymous wrote : 
  | http post: i can see that encoding requests as http params is not always going to work - especially if we have to tunnel through another web server who will limit http params to a max length - can we extend the http codec to do this differently?

The decoding of HTTP post is done by AsyncWeb (a minimal HTTP server implementation on top which should land into MINA trunk) .
Trustin plan to get it integrated for MINA 2.0 (The POST parsing issue is tracked by http://jira.safehaus.org/browse/ASYNCWEB-24[/url])

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104425#4104425

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104425