Hello,
For cookie handling with Hessian, you can take a look at HiveMind Utilities "hiveremoting.caucho" module. The HiveMind related stuff can easily be removed. I have used commons-httpclient to get cookie support (and more). Home page: http://hivetranse.sourceforge.net <http://hivetranse.sourceforge.net/> Cheers Jean-Francois _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mattias Jiderhamn Sent: Tuesday, October 30, 2007 3:10 PM To: Discussion of the Hessian protocol Subject: Re: [Hessian-interest] Session workaround Scott Ferguson wrote (2007-10-30 02:07): On Oct 26, 2007, at 11:43 PM, Mattias Jiderhamn wrote: AFAIK, Hessian does not support any type of sessions spanning several request, in the manner that SOAP APIs like Axis does. Correct. It would be possible to create something like that, but it would complicate the client and server, so it's something we've avoided. It seems to me it might be possible to subclass the HessianProxyFactory and add cookie handling, although I haven't looked into the details yet (such as when the connection is actually opened and read). I realize the key here is to use the correct cookie for each client/thread, probably either by using unique, subclassed proxies for each client or a ThreadLocal in the factory. ... Here is my idea for solving this: ... a unique ID ... will be used as the key in a WeakHashMap. The value of the Map is an object ... that queues the data... until we are ready to commit. There would also be a "reaper queue", that holds a (strong) reference to the data queue object (i.e. List), and a timeout (milliseconds from January 1, 1970). This time out queue has a reaper thread, that will wake up now and then, removing the strong references to the queues that have timed out, and thus letting the garbage collector remove them from the WeakHashMap in case the client is unable to commit the transaction There are a few things you want to change. First, you would need to add the id to each method. (Of course. The example was before session handling was added.) WeakHashMap is normally for things like Class and ClassLoader. You really don't want to use it for String keys. I keep forgetting it's the key of the WeakHashMap that is weak. What I meant was a ReferenceMap (from Apache Commons Collections, http://commons.apache.org/collections/api/org/apache/commons/collections/Ref erenceMap.html) with a weak key and a hard value. The Value of the HashMap will contain your session and also the expires time. Your reaper can walk along the HashMap.entrySet(), look for timeouts of the Value and remove as necessary. The value would look something like the following. My point here was to avoid looping all the entries every time, but rather only loop until the next one is no longer timed out and then sleep. I did a quick test, and it seems to work. Although after realizing that the number of concurrent sessions will probably be very low (normally < 10), I considered changing into something like what you suggested, but have not had time yet. - Should I be using something other than Hessian...? You could actually look at EJB stateful session beans. It's essentially the same model as you're looking at. You can even use Hessian to communicate with them. I have deliberately avoided EJBs as much as I can (did some CMPs years ago), so this may possibly be a dumb question: Would session handling "automatically" be added on top of the Hessian protocol then, without an additional parameter? What would be the benefits compared to pure Hessian with my solution? If you sent multiple JMS messages to some target which would collect them and wait for a commit, you'd still need to create a session to hold all the pending messages, which would be exactly the same issue as you have with Hessian. I don't *have* to send multiple messages. I could send a single message with all the data, since I have it all ready from the beginning. The main reason I was looking at Hessian and multiple requests, was to avoid reading all the binary data into memory, but rather just "stream" it from disk, over HTTP, and down on disk on the other side. /Mattias
_______________________________________________ hessian-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/hessian-interest
