A few questions on crashes in weblocks.

[Mackram]

Hey everyone,

so a quick set of questions on a few things that I noticed that do not
seem to make sense and would like someone's input one.

1- After starting a weblocks application say (testweb:start-
testweb :port 3223) all other applications I start are automatically
started at the same port irrespective of the port number I provide. I
am not sure why this is taking place but I checked the start-testweb
and the code is (apply #'start-weblocks args) (start-webapp
'testweb)) which would mean that the port (which is in the args) is
going to the whole weblocks and not just this app. Anyone faced this
or am I missing anything?

2- Attempting to stop any weblocks application results in a drop to
the debugger with the reason being that the variable
HUNCHENTOOT:*ACCEPTOR* is unbound. Note though that the application
does stop being served.

3- Attempting to do (weblocks:reset-session) also throws that the
variable HUNCHENTOOT:*ACCEPTOR* is unbound. As far as i can tell
though the session is not reset.

On the point of sessions can there be a page that is not dependent on
the session so that if an issue takes place the user is not stuck.

Appreciate the feedback that you can provide.

Regards,

Mackram

[Leslie P. Polzer]

Mackram wrote:

> 1- After starting a weblocks application say (testweb:start-
> testweb :port 3223) all other applications I start are automatically
> started at the same port irrespective of the port number I provide. I
> am not sure why this is taking place but I checked the start-testweb
> and the code is (apply #'start-weblocks args) (start-webapp
> 'testweb)) which would mean that the port (which is in the args) is
> going to the whole weblocks and not just this app. Anyone faced this
> or am I missing anything?

There's no support right now for per-webapp ports, although it's
easy to add this using the HOSTNAMES slot of the WEBLOCKS-WEBAPP
class as a guide.

> 2- Attempting to stop any weblocks application results in a drop to
> the debugger with the reason being that the variable
> HUNCHENTOOT:*ACCEPTOR* is unbound. Note though that the application
> does stop being served.

Are you using -stable or -dev?

> 3- Attempting to do (weblocks:reset-session) also throws that the
> variable HUNCHENTOOT:*ACCEPTOR* is unbound. As far as i can tell
> though the session is not reset.

There's no such symbol in -dev. There is RESET-SESSIONS though,
which works fine for me.

> On the point of sessions can there be a page that is not dependent on
> the session so that if an issue takes place the user is not stuck.

You can override HANDLE-HTTP-ERROR for your application.

Leslie

[Mackram]

Hey I am currently using stable (from clbuild) but it sounds like I
should start playing with dev directly :).

Also sorry for the typo it is RESET-SESSIONS but it still does not
work.

Regards,

Mackram

On Jun 24, 11:49 am, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

[Leslie P. Polzer]

On Thu, Jun 25, 2009 at 01:47:26PM -0700, Mackram wrote:
>
> Hey I am currently using stable (from clbuild) but it sounds like I
> should start playing with dev directly :).

Yes, indeed. :)

The next stable release is due very soon (we got delayed a bit this
time), but it's probably better for you to use -dev.

> Also sorry for the typo it is RESET-SESSIONS but it still does not
> work.

I couldn't reproduce this using -dev and I think I fixed that issue
months ago. Should you encounter it on -dev please tell me.