[Glass] a better concurrency issue debugging strategy?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Glass] a better concurrency issue debugging strategy?

Paul DeBruicker
Hi -

From a Seaside button click I'm starting telephone calls with a request to a remote server.  That remote server then POSTs a reply to my server and I reply with the call instructions.  Works great in Pharo.   But in Gemstone, I think that because I'm being clever and attempting to get the POSTs handled in their own gem, its not working.  My strategy for debugging things is to have a mix of GemTools and tODE images running where I start a blocking server in one image and then initiate the call from another image.  

One problem I have is that I don't really have any idea when/where things are breaking down while handling the POST.  Errors aren't popping up in GemTools or in the object log.   The other is restarting the tests means force quitting one or more of the images and then getting things set back up.  



Is there a better way?

thanks

Paul
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] a better concurrency issue debugging strategy?

Johan Brichau-3
Hi Paul,

I’m not sure I can follow 100%.
When you say that the errors are not popping up in GemTools or the Object log, you mean there is still an error occurring when you receive the POST?

Maybe it’s worth giving a bit more info on the setup and the actual tests. I don’t know if I can help, but I can try.

Johan

On 01 Feb 2014, at 18:12, Paul DeBruicker <[hidden email]> wrote:

> Hi -
>
> From a Seaside button click I'm starting telephone calls with a request to a remote server.  That remote server then POSTs a reply to my server and I reply with the call instructions.  Works great in Pharo.   But in Gemstone, I think that because I'm being clever and attempting to get the POSTs handled in their own gem, its not working.  My strategy for debugging things is to have a mix of GemTools and tODE images running where I start a blocking server in one image and then initiate the call from another image.  
>
> One problem I have is that I don't really have any idea when/where things are breaking down while handling the POST.  Errors aren't popping up in GemTools or in the object log.   The other is restarting the tests means force quitting one or more of the images and then getting things set back up.  
>
>
>
> Is there a better way?
>
> thanks
>
> Paul
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] a better concurrency issue debugging strategy?

Paul DeBruicker
Hi Johan,

Thanks for following up. The prior email was more from a "why did I ever start programming computers in the first place, I could've been _____" kind of place.  

The "errors not popping" up problem was because I forgot that Zinc, when not in debugging mode, swallows the errors and sends them as 500 responses. So I've switched debugging mode on in the Zinc server and am getting errors in the object log and GemTools.  


The next problem was ZnServer>>managedServers contained some servers which would not be gc'd after sending #stop and #unregister but had no other reference outside themselves.  For those I made a method to nil out the delegate, close the socket, and nil out the process, then unregistering worked.  I'm not sure why the Zinc servers would get into that state in the first place.  But I'll keep an eye out.  And maybe we should add that method I made to the Gemstone port of Zinc.  


The actual issue with the phone calls is I don't think I have my transactions committing at the right spots in the call initiating gem and call responding gem because the responding gem only has partial information about the call when the 3rd party reaches out to it to get the call data and so sends bad data to the 3rd party.  Maybe the responding gem needs an abort prior to looking up the call it should be making from an RcIdentityBag.  I'm not sure.  

At this point I'm just going to write up a script that starts the gems (e.g runSeasideGems style), runs the test, logs a ton of stuff, and kills them. I do think it'd be nice to have a class/script where you give it two blocks and it executes them in different gems without having the UI block.  



Paul



Johan Brichau-3 wrote
Hi Paul,

I’m not sure I can follow 100%.
When you say that the errors are not popping up in GemTools or the Object log, you mean there is still an error occurring when you receive the POST?

Maybe it’s worth giving a bit more info on the setup and the actual tests. I don’t know if I can help, but I can try.

Johan

On 01 Feb 2014, at 18:12, Paul DeBruicker <[hidden email]> wrote:

> Hi -
>
> From a Seaside button click I'm starting telephone calls with a request to a remote server.  That remote server then POSTs a reply to my server and I reply with the call instructions.  Works great in Pharo.   But in Gemstone, I think that because I'm being clever and attempting to get the POSTs handled in their own gem, its not working.  My strategy for debugging things is to have a mix of GemTools and tODE images running where I start a blocking server in one image and then initiate the call from another image.  
>
> One problem I have is that I don't really have any idea when/where things are breaking down while handling the POST.  Errors aren't popping up in GemTools or in the object log.   The other is restarting the tests means force quitting one or more of the images and then getting things set back up.  
>
>
>
> Is there a better way?
>
> thanks
>
> Paul
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] a better concurrency issue debugging strategy?

Dale Henrichs-3
Paul,

I agree that it should be possible to get to the point where you can keep the gui alive and run things on the gem ... perhaps we should get together and try out a few things with tODE some afternoon ... it takes some client-side monkey business, but we might be able to figure some things out ...


On Sun, Feb 2, 2014 at 7:16 AM, Paul DeBruicker <[hidden email]> wrote:
Hi Johan,

Thanks for following up. The prior email was more from a "why did I ever
start programming computers in the first place, I could've been _____" kind
of place.

The "errors not popping" up problem was because I forgot that Zinc, when not
in debugging mode, swallows the errors and sends them as 500 responses. So
I've switched debugging mode on in the Zinc server and am getting errors in
the object log and GemTools.


The next problem was ZnServer>>managedServers contained some servers which
would not be gc'd after sending #stop and #unregister but had no other
reference outside themselves.  For those I made a method to nil out the
delegate, close the socket, and nil out the process, then unregistering
worked.  I'm not sure why the Zinc servers would get into that state in the
first place.  But I'll keep an eye out.  And maybe we should add that method
I made to the Gemstone port of Zinc.


The actual issue with the phone calls is I don't think I have my
transactions committing at the right spots in the call initiating gem and
call responding gem because the responding gem only has partial information
about the call when the 3rd party reaches out to it to get the call data and
so sends bad data to the 3rd party.  Maybe the responding gem needs an abort
prior to looking up the call it should be making from an RcIdentityBag.  I'm
not sure.

At this point I'm just going to write up a script that starts the gems (e.g
runSeasideGems style), runs the test, logs a ton of stuff, and kills them. I
do think it'd be nice to have a class/script where you give it two blocks
and it executes them in different gems without having the UI block.



Paul




Johan Brichau-3 wrote
> Hi Paul,
>
> I’m not sure I can follow 100%.
> When you say that the errors are not popping up in GemTools or the Object
> log, you mean there is still an error occurring when you receive the POST?
>
> Maybe it’s worth giving a bit more info on the setup and the actual tests.
> I don’t know if I can help, but I can try.
>
> Johan
>
> On 01 Feb 2014, at 18:12, Paul DeBruicker &lt;

> pdebruic@

> &gt; wrote:
>
>> Hi -
>>
>> From a Seaside button click I'm starting telephone calls with a request
>> to a remote server.  That remote server then POSTs a reply to my server
>> and I reply with the call instructions.  Works great in Pharo.   But in
>> Gemstone, I think that because I'm being clever and attempting to get the
>> POSTs handled in their own gem, its not working.  My strategy for
>> debugging things is to have a mix of GemTools and tODE images running
>> where I start a blocking server in one image and then initiate the call
>> from another image.
>>
>> One problem I have is that I don't really have any idea when/where things
>> are breaking down while handling the POST.  Errors aren't popping up in
>> GemTools or in the object log.   The other is restarting the tests means
>> force quitting one or more of the images and then getting things set back
>> up.
>>
>>
>>
>> Is there a better way?
>>
>> thanks
>>
>> Paul
>> _______________________________________________
>> Glass mailing list
>>

> Glass@.gemtalksystems

>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
> _______________________________________________
> Glass mailing list

> Glass@.gemtalksystems

> http://lists.gemtalksystems.com/mailman/listinfo/glass





--
View this message in context: http://forum.world.st/Glass-a-better-concurrency-issue-debugging-strategy-tp4740865p4741020.html
Sent from the GLASS mailing list archive at Nabble.com.
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass