[hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports
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
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
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. 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
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
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
On Fri, May 30, 2008 at 3:47 PM, Raditya Kertiyasa <adit_kerti@yahoo.com> wrote:
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.
Well, all the advice I can give you here is not to compile in a port number but let the user decide if they want to run an http server, and on which port. If what you work on is a shrink-wrapped application (i.e. the user should never see the debugger), consider using the appropriate startup option to your Lisp to disable the debugger. You may also want to look at *DEBUGGER-HOOK* in the CLHS. -Hans
Hans, I've been trying to avoid having to prompt the user for a port, since my system will be communicating to another system via HTTP on an agreed port. But I'll take your advice. Thank you for putting up with my questions. By the way, I've done "svn co svn://bknr.net/svn/ediware". CMIIW, but it downloads the latest Hunchentoot source codes along with any required dependencies. But I can't seem to find Hunchentoot anywhere. Have I missed something? Regards, Raditya Kertiyasa Hans Hübner wrote:
On Fri, May 30, 2008 at 3:47 PM, Raditya Kertiyasa <adit_kerti@yahoo.com> wrote:
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.
Well, all the advice I can give you here is not to compile in a port number but let the user decide if they want to run an http server, and on which port. If what you work on is a shrink-wrapped application (i.e. the user should never see the debugger), consider using the appropriate startup option to your Lisp to disable the debugger. You may also want to look at *DEBUGGER-HOOK* in the CLHS.
-Hans _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Fri, May 30, 2008 at 4:15 PM, Raditya Kertiyasa <adit_kerti@yahoo.com> wrote:
By the way, I've done "svn co svn://bknr.net/svn/ediware". CMIIW, but it downloads the latest Hunchentoot source codes along with any required dependencies. But I can't seem to find Hunchentoot anywhere. Have I missed something?
It should be in the ediware/hunchentoot subdirectory. -Hans
I've got this message: svn: URL 'svn://bknr.net/svn/trunk/thirdparty/flexi-streams-1.0.2' doesn't exist And then when I ls in the ediware subdirectory, this is what I get: /ediware$ ls bordeaux-threads chunga cl-fad cl+ssl drakma cffi cl-base64 cl-ppcre cl-who Regards, Raditya Kertiyasa Hans Hübner wrote:
On Fri, May 30, 2008 at 4:15 PM, Raditya Kertiyasa <adit_kerti@yahoo.com> wrote:
By the way, I've done "svn co svn://bknr.net/svn/ediware". CMIIW, but it downloads the latest Hunchentoot source codes along with any required dependencies. But I can't seem to find Hunchentoot anywhere. Have I missed something?
It should be in the ediware/hunchentoot subdirectory.
-Hans _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Fri, 30 May 2008 21:49:32 +0700, Raditya Kertiyasa <adit_kerti@yahoo.com> wrote:
I've got this message: svn: URL 'svn://bknr.net/svn/trunk/thirdparty/flexi-streams-1.0.2' doesn't exist
Sorry, that's my fault due to an update I did this afternoon. Will fix.
On Fri, 30 May 2008 21:49:32 +0700, Raditya Kertiyasa <adit_kerti@yahoo.com> wrote:
I've got this message: svn: URL 'svn://bknr.net/svn/trunk/thirdparty/flexi-streams-1.0.2' doesn't exist
Should work now, please try again. Sorry for the hiccup.
Sure does. Thanks Edi :) Regards, Raditya Kertiyasa Edi Weitz wrote:
On Fri, 30 May 2008 21:49:32 +0700, Raditya Kertiyasa <adit_kerti@yahoo.com> wrote:
I've got this message: svn: URL 'svn://bknr.net/svn/trunk/thirdparty/flexi-streams-1.0.2' doesn't exist
Should work now, please try again. Sorry for the hiccup. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
participants (3)
-
Edi Weitz -
Hans Hübner -
Raditya Kertiyasa