Hans,
I might be getting myself into stuff that I really don't understand yet. I'll rephrase my question:
The bottom line is that it is possible that more than one instance of my system will be running on the same machine. With the port set to default each time the system starts, this produces the possibility that someone will start an instance of Hunchentoot and end up in a port conflict. What I really want to do is address this situation in whichever way is simpler and easier, so I tried using HANDLER-BIND and a restart function. It may not be the best solution and I might have taken a wrong turn or missed a sign, so I'd really appreciate it if you could tell me your opinion.
Regards, Raditya Kertiyasa
Hans Hübner wrote:
On Fri, May 30, 2008 at 3:11 PM, Raditya Kertiyasa adit_kerti@yahoo.com wrote:
Hans,
Thanks for the explanation and suggestion. I've never used SVN before, but I'll give it a try. If there are alternative methods such as invoking START-SERVER without creating a new thread on the version I'm using (the one I got from Ubuntu repos), or maybe checking if the port in question is already bind before even invoking START-SERVER, I'm all ears.
The current release version of Hunchentoot does not give you an API to do what you want, sorry. You can hack away at the source code yourself if you really want to.
In the current development version, you can use :THREADED NIL as argument to START-SERVER. This will run the listener and the connection handler in the invoking thread, and conditions will just be signalled through to the caller of START-SERVER. You can do this in a separate thread for each of your servers (and you propably want to, as the call is blocking). :THREADED NIL will also switch off persistent connections by default so that it is possible to server multiple clients, one after the other. This mode will be slower, though, because I/O and request processing will be done in a synchronous fashion (i.e. one after the other).
-Hans
By the way, I think Hunchentoot is great! Thanks Edi and you for making my life easier.
Regards, Raditya Kertiyasa
Hans Hübner wrote:
Hi Raditya,
the problem that you see results from the fact that Hunchentoot sets up the listen socket in a new thread. The handler and restart that you set up around the START-SERVER invocation are not active in that thread.
You may want to have a look at the new development version of Hunchentoot. In this version, both LISTEN-FOR-CONNECTIONS and EXECUTE-LISTENER are generic functions that you could augment with :AROUND methods to handle port conflicts. The new version is not finalized and these generic functions are not yet mentioned in the official API documentation, but if you need to get running quickly, it may be worth a try.
Use "svn co svn://bknr.net/svn/ediware" to check out the development version of Hunchentoot and all required dependencies.
-Hans
On Thu, May 29, 2008 at 11:55 PM, Raditya Kertiyasa adit_kerti@yahoo.com wrote:
Hi everbody,
I'm a Lisp newbie but I need to get my system up and running fast. I'm building a system that might cause multiple Hunchentoot servers to use conflicting ports. I want to handle this with an error handler and I've setup a wrapper function to start Hunchentoot and a restart function:
;; restart function to handle conflicting ports (defun ht-port-conflict-handler (condition) (... do something here to address the conflicting ports ...) (invoke-restart 'ht-port-conflict-handler))
;; Start Hunchentoot Server with error-handling (defun ht-start-with-error-handler () (handler-bind ((simple-error #'ht-port-conflict-handler)) (restart-case (setf *ht-handle* (hunchentoot:start-server :port *ht-port*)) (ht-port-conflict-handler () nil))))
The system should allow users to reconfigure their instance of Hunchentoot without having to invoke the debugger, but when I run this code I always end up in the debugger anyway. Can anybody tell me where I went wrong? Or maybe there's a better solution for my situation?
Regards, Raditya Kertiyasa
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel