[Glass] a better concurrency issue debugging strategy?

[Johan Brichau]

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 <pdebruic at gmail.com> 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 at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass