I found it very early and I judge it is becuase hunchentoot1 made a big step: from 0.15.8 to 1.0.12, it uses a new class acceptor which I do not comprehensive it very much. So I skip this problem for I can say sayonara to slime. I think it just waste my time: it takes time to run slime.
However Murphy's law came, I found my data was mixed when I modify data in the course of exiting and entering slime. I first suspect the algorithm of modification, sigh, it is waste of time again, It is just due to close-store is not called. I believe this work could be done in stop-weblocks which I ignore. I have to debug stop-weblocks and discover it enter a endless loop when to shutdown a one-thread-per-connection-taskmaster object, I do not know why but I redefine the shutdown method, not to waiting the process natural dies but kill it by sb-thread:terminate-thread.
It works and It is obvious I need check this problem after the state of hunchentoot and Weblocks development are stable.3
1. Weblocks is based on hunchentoot.
2. It is very pity hunchentoot 1.0 does not support \*catch-error-p\*, it is said it just absent for a little time.
3. Maybe it is my configuration' wrong, but it does not make sense now.
Yes, the behaviour of either Taskmaster's SHUTDOWN or ACCEPTOR's STOP is weird. This should be fixed in Hunchentoot. Perhaps you can ensure that some solution is found...
ReplyDelete