Jim Spath (j...@pangeamedia.com)

The tar.gz file for my demonstration application appears to be messed
up, sorry about that.  Here's a zip file that is valid:

http://www.filedropper.com/utf16

- Jim

So I know the whole UTF-16 surrogate warning issue has been brought up a
few times on this list, but I don't think anyone has posted a reliable
test case, so I thought I would take a stab at it.  We have over 2700 of 
these warnings in todays error logs, so it'd be nice to get rid of them.

All that's really necessary is to reproduce the problem is to output a
body of the necessary length:

   # 56338 = 0xdc12
   $c->response->body(1 x 56338);

And to run your application under FastCGI.  It will produce the 
following warning every time:

UTF-16 surrogate 0xdc12 at /usr/lib/perl/5.8/IO/Handle.pm line 199.

I've created a minimal Catalyst application to demonstrate the problem
which can be downloaded here:

http://www.filedropper.com/utf16tar

No plugins are used and binmode is not set.

Anyways, hopefully this makes it easier for people to figure out what is
going on.

- Jim

We've gotten some reports in one of our Catalyst applications that users
are "swapping places".  ie, they are suddenly logged in as another user, 
or someone has accessed their account.  I've done some quick looking and 
don't see anything unusual.

I was wondering if it could possibly be session key collisions?  Have 
any of you experienced this?

I'm using the following session plugins:

  Session (0.13)
  Session::Store::Memcached (0.2 current)
  Session::State::Cookie (0.06)

They are not the most current versions, although I don't see anything in
the changelog relating to session collisions.

Also, does anyone have advice on how to institute some debugging to try
to catch these session collisions?  I was thinking of storing their 
username in a separate cookie, and checking this cookie when we load a
session to make sure that they match, similarly to how the
verify_address functionality works.

Thanks!
Jim

Last night we experienced a problem with scriptindex where it spawned
many (80 or so) zombie processes.  This same problem occurred earlier 
this month as well, and also a couple of times in January.  It actually 
spawned hundreds of these processes during these previous occurrences.

Has anyone else experienced anything like this?

scriptindex has generally been quite well behaved for us, we run it
almost constantly, so we're not quite sure what triggers the problem.

Thanks!
Jim

What is the "right" way to check if an action exists before forwarding
to it?

I have found the following code to work for me:

if ($c->dispatcher->get_action_by_path($some_action_path)) {
   $c->forward($some_action_path);
}

Is there a better way?

Thanks!
Jim