Re: [Catalyst] Apache2::RequestIO::read problem

2008-07-29 Thread Bill Moseley
On Tue, Jul 29, 2008 at 12:07:31AM -0500, Chris Dolan wrote:
 
 [error] Caught exception in engine Apache2::RequestIO::read: (104)  
 Connection reset by peer at /home/foo/perl/lib/perl5/site_perl/5.8.8/ 
 Catalyst/Engine/Apache.pm line 187
 [Mon Jul 28 16:14:36 2008] [error] [client xxx.xxx.xxx.xxx] File does  
 not exist: /home/foo/MyApp/root/student, referer: http://example.com/ 
 student
 
 I think the connection reset part is a client disconnecting  
 prematurely, but what disturbs me is the second error.  I have a lib/ 
 MyApp/Controller/Student.pm which should be receiving requests to  
 http://example.com/student, but instead I see those requests  
 redirected to my static folder (.../root/...).  This does not happen  
 normally -- plenty of hits are going through to /student as expected.

I see these, too.  I've not been too worried, and I've been assuming
that Apache is just falling back to the default handler for some
reason.

There's a little info to be found with Google -- mostly others asking
the same question.

It would be nice to have these fail in a cleaner way (as far as the
logs go, at least).

-- 
Bill Moseley
[EMAIL PROTECTED]
Sent from my iMutt


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Apache2::RequestIO::read problem

2008-07-29 Thread Andrew Rodland
On Tuesday 29 July 2008 12:07:31 am Chris Dolan wrote:
 [error] Caught exception in engine Apache2::RequestIO::read: (104)
 Connection reset by peer at /home/foo/perl/lib/perl5/site_perl/5.8.8/
 Catalyst/Engine/Apache.pm line 187
 [Mon Jul 28 16:14:36 2008] [error] [client xxx.xxx.xxx.xxx] File does
 not exist: /home/foo/MyApp/root/student, referer: http://example.com/
 student
 [snip]
 I'm seeing the problem with URLs other than just /
 student too, but all of these problems are infrequent and only after
 reset connections.  I have not been able to reproduce the problem
 with my own web browser.

I've seen more-or-less the same thing using C::P::Server::XMLRPC when it gets 
some data it really doesn't like. I don't understand it any more than you do 
but it seems harmless enough. As Bill Moseley said it seems that something is 
failing in a way that makes apache retry with the default-handler. Makes no 
sense to me, but it does fit hte bill.

Andrew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Squatting::On::Catalyst

2008-07-29 Thread Matt S Trout
On Mon, Jul 28, 2008 at 09:36:44PM -0700, John Beppu wrote:
 On Mon, Jul 28, 2008 at 2:40 PM, Matt S Trout [EMAIL PROTECTED]wrote:
 
  On Mon, Jul 28, 2008 at 08:27:27AM -0700, John Beppu wrote:
 
 
   Imagine if you could install a blog, a wiki, a forum, or a store just as
   easily.
 
  Yeah, we'll be doing that for arbitrary Catalyst components for 5.80,
  I hope. This is still really cool, mind.
 
 
 Good luck w/ that.  I don't know the guts of Catalyst too well, but I have a
 feeling it could be tricky.

Most interesting features are at least somewhat tricky.

Anyway, non-tricky code is boring to write :)

 In the meantime, please have a look at the HTTP::Engine project so that
  you can share HTTP code with other frameworks, and consider joining the
  catalyst-dev list since we're planning to kick off a project to see about
  sharing dispatchers with other projects as well.
 
 
 HTTP::Engine was exactly what I needed when I started the project.  I'm glad
 I know about it, now.

Please do pop onto irc.perl.org#http-engine if you need to suggest anything
to the devs - they're very happy to hear wishlist stuff from potential users.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL

2008-07-29 Thread Tobias Kremer
Quoting Matt S Trout [EMAIL PROTECTED]:
 On Mon, Jul 28, 2008 at 01:03:52PM +0200, Tobias Kremer wrote:
  Is there anything speaking against wrapping line 52 of the DBIC backend
  class with an eval to trap this duplicate error and ignore it silently
  (or just warn about it) except the fact that it's trying to fix something
  that probably should be the database's task?
 Don't see why not.

Cool :)

 The interesting question i how we make a test for it.
 Mm ... ah. How about a debugcb sub that checks for the SELECT and does the
 insert in the background so the row's there when the DBIC-driven INSERT
 happens?

I have a working test case now which involves a custom debugobj with a query_end
method that injects an INSERT after the SELECT for the flash happened. debugcb()
didn't work for me. I suppose it's called _before_ the SELECT is executed.

However, I'm unsure how to detect if the error really was a duplicate entry
error or something else.

  die $@ if $@  $@ !~ /duplicate/i;

This doesn't work because different DBs throw different errors.

Any thoughts?

--Tobias

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL

2008-07-29 Thread Nigel Metheringham


On 29 Jul 2008, at 12:30, Tobias Kremer wrote:

The short time window between the find() and create() calls of the
find_or_create() method indeed is the problem. It sounds like this  
window
should be too small to ever happen but in reality it happens very  
often in our
(and other's) applications. I can force the problem by hammering  
reload in my

browser.



Run the find_or_create within a transaction.  You could even extend
find_or_create to package it within a transaction if you wanted.

Nigel.
--
[ Nigel Metheringham [EMAIL PROTECTED] ]
[ - Comments in this message are my own and not ITO opinion/policy - ]


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Squatting::On::Catalyst

2008-07-29 Thread Daniel McBrearty
my 0.05 (possibly a bit OT) :

I looked previously at a few ways of adding forums etc to the site
using 3rd party code, indeed there are many possibilites (some perl,
some not)

The thing that was always a sticker for me was getting some kind of
logical integration, ie:

1. letting users keep existing member and login creds
2. being able to cross ref to other parts of the site eg. for a
certain node, easily have a discussion link, and the reverse link
from the forum

I haven't yet seen a way to do this that looks easier than doing it
from scratch (well, lets say some heavy porting of existing db
structures and code from existing stuff ...)

IMO getting these kind of features right are where the real meat is.
Looking at the summary, I guess that's not what the focus of this
project is, so if this is post is basically just noise, please forgive
that.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Squatting::On::Catalyst

2008-07-29 Thread Chisel Wright
On Tue, Jul 29, 2008 at 02:21:10PM +0200, Daniel McBrearty wrote:
 1. letting users keep existing member and login creds
 2. being able to cross ref to other parts of the site eg. for a
 certain node, easily have a discussion link, and the reverse link
 from the forum

If you ever think of a good way of doing this, please let me know!

-- 
Chisel Wright
e: [EMAIL PROTECTED]
w: http://www.herlpacker.co.uk/

  What do you call a chav in a box?
  Innit.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Squatting::On::Catalyst

2008-07-29 Thread Daniel McBrearty
I've been meaning to dig into the everything2 code (which powers
perlmonks I think, amongst other things ..) and see how they do the
cross ref stuff. They seem to have a pretty nice node abstraction
which is the core of the problem, I think.

the membership stuff relies on a common API, I guess. Doesn't claco
have a project that addresses that?

On Tue, Jul 29, 2008 at 3:08 PM, Chisel Wright [EMAIL PROTECTED] wrote:
 On Tue, Jul 29, 2008 at 02:21:10PM +0200, Daniel McBrearty wrote:
 1. letting users keep existing member and login creds
 2. being able to cross ref to other parts of the site eg. for a
 certain node, easily have a discussion link, and the reverse link
 from the forum

 If you ever think of a good way of doing this, please let me know!

 --
 Chisel Wright
 e: [EMAIL PROTECTED]
 w: http://www.herlpacker.co.uk/

  What do you call a chav in a box?
  Innit.

 ___
 List: Catalyst@lists.scsys.co.uk
 Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
 Dev site: http://dev.catalyst.perl.org/




-- 
There's an infinite supply of time, we just don't have it all yet.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL

2008-07-29 Thread Daniel Westermann-Clark
On 2008-07-28 22:33:44 +0100, Matt S Trout wrote:
  Is there anything speaking against wrapping line 52 of the DBIC
  backend class with an eval to trap this duplicate error and ignore
  it silently (or just warn about it) except the fact that it's
  trying to fix something that probably should be the database's
  task?
 
 Don't see why not.

Store::DBIC was intended as a drop-in replacement for Store::DBI, for
when you want to use the rest of what DBIx::Class gives you in terms
of tracking tables, etc.  I'd like to keep their behavior in sync, if
possible.

Currently the method which Store::DBIC uses to find the session and
flash rows is very similar to that in Store::DBI, and I believe that
Store::DBI has the same race condition.  Store::DBI may be fast
enough by using direct DBI that it hasn't cropped up.

For Store::DBIC, I think we should consider instead:

(1) updating the docs to discourage usage of MyISAM and other non-ACID
setups

(2) wrapping each find_or_create call in a transaction to be sure that
these race conditions don't happen on real databases

(3) making the backend (i.e. delegate) configurable for people who
can't use transactions, implementing the alternate functionality

However, the last point makes me feel like we're doing something that
DBIx::Class normally abstracts.

-- 
Daniel Westermann-Clark

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Squatting::On::Catalyst

2008-07-29 Thread John Beppu
On Tue, Jul 29, 2008 at 5:21 AM, Daniel McBrearty [EMAIL PROTECTED]
 wrote:

 my 0.05 (possibly a bit OT) :


Off-topic or not, I think these are interesting and valid questions.


 I looked previously at a few ways of adding forums etc to the site
 using 3rd party code, indeed there are many possibilites (some perl,
 some not)

 The thing that was always a sticker for me was getting some kind of
 logical integration, ie:

 1. letting users keep existing member and login creds


Now that composition and embedding of web apps is becoming a reality, we
have to start anticipating needs like this.  For example, the documentation
for an app that's built to be embedded could state that:

   - It expects a user object to be in its session's u key.
   - The app will expect to be able to call the -name method on this user
   object.  (Some apps may want more...  others less...  this is just a
   hypothetical example.)
   - If that key is undef, the app will assume the current session is not in
   a logged in state.

 I think being up-front about login policy would be enough to share users
across multiple web apps joined together as one cohesive unit.

2. being able to cross ref to other parts of the site eg. for a
 certain node, easily have a discussion link, and the reverse link
 from the forum


I haven't thought about this problem much at all.  My initial thought is
that (again) the app that's going to be embedded would have to be written to
anticipate this kind of need.  Perhaps the app-to-be-embedded could provide
a configuration option for the embedder to fill in with an appropriate
value. This option would control how links would be generated in key
portions of the app.

I haven't yet seen a way to do this that looks easier than doing it
 from scratch (well, lets say some heavy porting of existing db
 structures and code from existing stuff ...)

 IMO getting these kind of features right are where the real meat is.
 Looking at the summary, I guess that's not what the focus of this
 project is, so if this is post is basically just noise, please forgive
 that.


No need for apologies.

The questions that you bring up have definitely crossed my mind.  It's true
that my work so far does not address these questions at all, but at the same
time, this kind of work is a sort of prerequisite for these questions.  (You
couldn't even ask questions about mixing sites together cohesively if you
couldn't mix them together at all, right?)


--beppu
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/