Mailing List Archive

Hi Dave,

From what I understand, there is nothing "magical" about the stash,
it's basically a hash reference, used once per request, that is all.

So, I would suggest you look at debugging more the objects you're
storing in the stash, and how they may change during the request cycle.

You would need to supply more code samples/examples.

If you can, start stripping away what's not necessary and still be able
to re-produce the problem, it will most probably highlight the issue by
itself.

Otherwise, reply back with a full working example.

Ideally use something like http://paste.scsys.co.uk to paste your code
snippets, post as much as you can, it's usually the subtle bits you
don't think are important where the actual issue lies.


Rob


On 04/25/2014 08:08 PM, David Trudgian wrote:
> Hi,
>
> I'm observing a frustrating problem where the following happens:
>
> A Catalyst controller retrieves a 'search' object and the related parent 'submission' object from a DBIC schema instance. It puts them into the stash:
>
> $c->model('CPFP')->schema->resultset('Searches')->find($sch_id);
> $c->stash->{search} = $search;
> $c->stash->{submission} = $search->submission;
>
> Now, the relationships here mean it's always the case that $search->submission->sub_id = $submission->sub_id
>
> However, when forwarded to the view (TT2 HTML or Excel Template Plus based), occasionally the search and submission pulled back out of the stash in the template are inconsistent. The following trap in the template will throw an error:
>
> [% IF search.submission.sub_id != submission.sub_id %]
> [% THROW mismatch "Fatal Error SCH-SUB-ID != SUB-ID" %]
> [% END %]
>
> I don't understand how this is possible, given the way the stash values are set in the controller. It occurs infrequently, and I can't find a situation that reproducibly causes it. The app is running under fastcgi on Apache.
>
> Any thoughts on what to look at would be much appreciated. I was considering session crossover as a cause, so ensured there was entropy on the server, set no-cache headers for proxies etc. However, I have now seen this occur on a development machine with only me connected to the app. I don't understand well enough how the stash works in order to know what might affect the consistency like this.
>
> Any help greatly appreciated!
>
> Dave Trudgian
>
>
>
> ________________________________
>
> UT Southwestern Medical Center
> The future of medicine, today.
>
>
> _______________________________________________
> 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/


_______________________________________________
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/

Hi Rob,

Thanks for the input. Yeah, I need to dedicate a bunch of time to looking at this and paring it down to find where the problem occurs. The major headache there is that I use this system heavily every day, and I might see the issue a couple of times a month. I just haven't been able to reproduce it, despite trying to replicate the usage when I have observed it.

If the stash is just a request specific hashref then I must have reassignment/modification of one of the objects somewhere.

Thanks,

DT



-----Original Message-----
From: Robert Brown [mailto:rob@intelcompute.com]
Sent: Friday, April 25, 2014 2:18 PM
To: catalyst@lists.scsys.co.uk
Subject: Re: [Catalyst] Inconsistency when retrieving objects from stash

Hi Dave,

From what I understand, there is nothing "magical" about the stash, it's basically a hash reference, used once per request, that is all.

So, I would suggest you look at debugging more the objects you're storing in the stash, and how they may change during the request cycle.

You would need to supply more code samples/examples.

If you can, start stripping away what's not necessary and still be able to re-produce the problem, it will most probably highlight the issue by itself.

Otherwise, reply back with a full working example.

Ideally use something like http://paste.scsys.co.uk to paste your code snippets, post as much as you can, it's usually the subtle bits you don't think are important where the actual issue lies.


Rob


On 04/25/2014 08:08 PM, David Trudgian wrote:
> Hi,
>
> I'm observing a frustrating problem where the following happens:
>
> A Catalyst controller retrieves a 'search' object and the related parent 'submission' object from a DBIC schema instance. It puts them into the stash:
>
> $c->model('CPFP')->schema->resultset('Searches')->find($sch_id);
> $c->stash->{search} = $search;
> $c->stash->{submission} = $search->submission;
>
> Now, the relationships here mean it's always the case that
> $search->submission->sub_id = $submission->sub_id
>
> However, when forwarded to the view (TT2 HTML or Excel Template Plus based), occasionally the search and submission pulled back out of the stash in the template are inconsistent. The following trap in the template will throw an error:
>
> [% IF search.submission.sub_id != submission.sub_id %]
> [% THROW mismatch "Fatal Error SCH-SUB-ID != SUB-ID" %] [% END %]
>
> I don't understand how this is possible, given the way the stash values are set in the controller. It occurs infrequently, and I can't find a situation that reproducibly causes it. The app is running under fastcgi on Apache.
>
> Any thoughts on what to look at would be much appreciated. I was considering session crossover as a cause, so ensured there was entropy on the server, set no-cache headers for proxies etc. However, I have now seen this occur on a development machine with only me connected to the app. I don't understand well enough how the stash works in order to know what might affect the consistency like this.
>
> Any help greatly appreciated!
>
> Dave Trudgian
>
>
>
> ________________________________
>
> UT Southwestern Medical Center
> The future of medicine, today.
>
>
> _______________________________________________
> 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/


_______________________________________________
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/


_______________________________________________
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/

Yeah these "random" problems are always the worst, you find it
impossible to re-create, which usually just means the issue isn't where
you think it is, because if it was, you'd be able to re-create it easily.

Been there a million times before myself, and it's usually something
simple and obvious, when you find it.




On 04/25/2014 08:41 PM, David Trudgian wrote:
> Hi Rob,
>
> Thanks for the input. Yeah, I need to dedicate a bunch of time to looking at this and paring it down to find where the problem occurs. The major headache there is that I use this system heavily every day, and I might see the issue a couple of times a month. I just haven't been able to reproduce it, despite trying to replicate the usage when I have observed it.
>
> If the stash is just a request specific hashref then I must have reassignment/modification of one of the objects somewhere.
>
> Thanks,
>
> DT
>
>
>
> -----Original Message-----
> From: Robert Brown [mailto:rob@intelcompute.com]
> Sent: Friday, April 25, 2014 2:18 PM
> To: catalyst@lists.scsys.co.uk
> Subject: Re: [Catalyst] Inconsistency when retrieving objects from stash
>
> Hi Dave,
>
> From what I understand, there is nothing "magical" about the stash, it's basically a hash reference, used once per request, that is all.
>
> So, I would suggest you look at debugging more the objects you're storing in the stash, and how they may change during the request cycle.
>
> You would need to supply more code samples/examples.
>
> If you can, start stripping away what's not necessary and still be able to re-produce the problem, it will most probably highlight the issue by itself.
>
> Otherwise, reply back with a full working example.
>
> Ideally use something like http://paste.scsys.co.uk to paste your code snippets, post as much as you can, it's usually the subtle bits you don't think are important where the actual issue lies.
>
>
> Rob
>
>
> On 04/25/2014 08:08 PM, David Trudgian wrote:
>> Hi,
>>
>> I'm observing a frustrating problem where the following happens:
>>
>> A Catalyst controller retrieves a 'search' object and the related parent 'submission' object from a DBIC schema instance. It puts them into the stash:
>>
>> $c->model('CPFP')->schema->resultset('Searches')->find($sch_id);
>> $c->stash->{search} = $search;
>> $c->stash->{submission} = $search->submission;
>>
>> Now, the relationships here mean it's always the case that
>> $search->submission->sub_id = $submission->sub_id
>>
>> However, when forwarded to the view (TT2 HTML or Excel Template Plus based), occasionally the search and submission pulled back out of the stash in the template are inconsistent. The following trap in the template will throw an error:
>>
>> [% IF search.submission.sub_id != submission.sub_id %]
>> [% THROW mismatch "Fatal Error SCH-SUB-ID != SUB-ID" %] [% END %]
>>
>> I don't understand how this is possible, given the way the stash values are set in the controller. It occurs infrequently, and I can't find a situation that reproducibly causes it. The app is running under fastcgi on Apache.
>>
>> Any thoughts on what to look at would be much appreciated. I was considering session crossover as a cause, so ensured there was entropy on the server, set no-cache headers for proxies etc. However, I have now seen this occur on a development machine with only me connected to the app. I don't understand well enough how the stash works in order to know what might affect the consistency like this.
>>
>> Any help greatly appreciated!
>>
>> Dave Trudgian
>>
>>
>>
>> ________________________________
>>
>> UT Southwestern Medical Center
>> The future of medicine, today.
>>
>>
>> _______________________________________________
>> 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/
>
> _______________________________________________
> 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/
>
>
> _______________________________________________
> 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/


_______________________________________________
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/

Hi David,

Not obvious why the problem isn't reproducible, but if you're using a
DBIC::ResultSet directly in TT then it would be worth trying to confirm
that $sub_id is definitely what you think it is (i.e. an integer rather
than an object).

[% USE Dumper %]
[% IF search.submission.sub_id != submission.sub_id %]
<pre>SCH-SUB-ID: [% Dumper.dump( search.submission.sub_id ) %]</pre>
<pre>SUB-ID: [% Dumper.dump( submission.sub_id ) %]</pre>
[% THROW mismatch "Fatal Error SCH-SUB-ID != SUB-ID" %]
[% END %]

As a general rule, I would try and flatten DBIC objects into a simple data
structure in your Controller and take as much business logic as possible
out of your view.

Best,

Ian

--
Dr Ian Sillitoe
Orengo Group, Structural and Molecular Biology
University College London