Debugging a multiple process system ... ?

If one has a multi process Gemstone system answering request with http/http/ws/wss I would find it very nice to set this system into a debugging state.

And from my IDE I connect dynamically to that running process which has thrown an exception and pops up a debugger.

Has anyone thought about such a system ?

Marten

Marten,

Did you know that you should be able to open a debugger on a continuation - it is possible with tODE and GemTools. I think that most folks find this a reasonable solution.

With tODE you can set remote breakpoints and arrange to have a continuation snapped off at that point for later debugging.

Back in the very early days, I had a debugger pop up in GemTools from a remote gem that you were allowed to debug and then proceed from, but it seems that continuation-based debugging pretty much satisfies the need to debug remote sessions.

You can arrange for a Seaside-based debugger to come up in the browser when you hit an error, but I don't think this is the route you are thinking of.

If one has a multi process Gemstone system answering request with http/http/ws/wss I would find it very nice to set this system into a debugging state.

And from my IDE I connect dynamically to that running process which has thrown an exception and pops up a debugger.

Has anyone thought about such a system ?

Marten

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

Hmm,

honestly I simply do not understand how this works :-(((((

If I have an exception within my REST API calls I normally have to abort the transaction, so that nothing has changed ...  therefore how can I save a continuation into the database ??

Its a shame I know, but I simply do not get it ...

Mariano Martinez Peck via Glass <[hidden email]> hat am 22. Januar 2018 um 13:05 geschrieben:

On Sun, Jan 21, 2018 at 1:35 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Marten,

Did you know that you should be able to open a debugger on a continuation - it is possible with tODE and GemTools. I think that most folks find this a reasonable solution.

 

That's what I do. I do it at Seaside error handler as well as in some other error handlers (like background jobs).

What I do is basically:

-----

[ self codeThatCouldTriggerErrorAndIWantToSaveAContinuationForLaterDebugging ]

on: Error do: [ :ex |  

    FaSmalltalkPlatform current saveExceptionContinuation: exception.

]

----

FaGemStonePlatform class >> saveExceptionContinuation: anException

  | continuation action |

  GRPlatform current canDebugInteractively

    ifTrue: [ anException pass ].

  GRPlatform current

    logError: anException description

    title: 'Continuation saved to object log'.

  action := [ :cont | 

  continuation := cont.

  #'create' ] callCC.

  action == #'create'

    ifTrue: [ 

      | logEntry |

      logEntry := WAObjectLogEntry

        error: anException description

        continuation: continuation. "the continuation is not resumable"

      logEntry resumeContinuation.

      logEntry addToLog.

      ^ continuation ].

  action == #'debug'

    ifTrue: [ self halt ]

That uses Grease which I would expect you have it loaded. WAObjectLogEntry is from Seaside but it's a very stupid subclass. so if you are not using Seaside you could just copy that class and give it whatever name and put it in your code. 

Once the continuation has been created and stored in the ObjectLog all you have to do is to connect with tODE and open a debugger on it.

BTW, be sure to cleanup the object log as continuations are heavy:  http://ws.stfx.eu/2LSEXBAMZT23

 

--

Mariano
http://marianopeck.wordpress.com

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

Do you have the implementation of #canDebugInteractively ?

Marten

Mariano Martinez Peck <[hidden email]> hat am 22. Januar 2018 um 19:30 geschrieben:

On Mon, Jan 22, 2018 at 3:14 PM, Marten Feldtmann via Glass <[hidden email]> wrote:

Hmm,

honestly I simply do not understand how this works :-(((((

If I have an exception within my REST API calls I normally have to abort the transaction, so that nothing has changed ...  therefore how can I save a continuation into the database ??

Its a shame I know, but I simply do not get it ...

It's not a shame. I think the word "continuation" has been confusing since several years already. And I think its confusing because of its association with Seaside and the back button etc. 

Let's talk about what it is for GemStone (well, at least what I understand from it):

When an exception is signaled, and you read to an exception handler, from the exception you can get the signaler context, right? That means that somehow you have access the the stack that triggered that error (stack of method context instances).  As far as I understand, the # callCC does something *like* a deep copy of the stack. Its not a full 100% deep copy as you might end up copying the whole extent. I guess there is a treshold somewhere. 

Once the continuation has been created (imageine you now have a kind of a deep copy of the stack), then you are able to persist it as any other persistent object. The object log is just one persistent object that makes it easy to store this but it could be anywhere. 

Then, you can simply open a debugger on a persisted continuation. 

So... I imagine you can do something like this:

[ 

 " Your rest code here" 

 ]

on: Error do: [ :ex |  

   System abortTransaction. 

Sytem beginTransaction.

    FaSmalltalkPlatform current saveExceptionContinuation: ex.

System commitTransaction. 

]

Hope this is clearer...if not let me know. And maybe GemStone people may have something to correct from what I said.

Best,

 

 

Mariano Martinez Peck via Glass < [hidden email]> hat am 22. Januar 2018 um 13:05 geschrieben:

On Sun, Jan 21, 2018 at 1:35 PM, Dale Henrichs via Glass < [hidden email]> wrote:

Marten,

Did you know that you should be able to open a debugger on a continuation - it is possible with tODE and GemTools. I think that most folks find this a reasonable solution.

 

That's what I do. I do it at Seaside error handler as well as in some other error handlers (like background jobs).

What I do is basically:

-----

[ self codeThatCouldTriggerErrorAndIW antToSaveAContinuationForLater Debugging ]

on: Error do: [ :ex |  

    FaSmalltalkPlatform current saveExceptionContinuation: exception.

]

----

FaGemStonePlatform class >> saveExceptionContinuation: anException

  | continuation action |

  GRPlatform current canDebugInteractively

    ifTrue: [ anException pass ].

  GRPlatform current

    logError: anException description

    title: 'Continuation saved to object log'.

  action := [ :cont | 

  continuation := cont.

  #'create' ] callCC.

  action == #'create'

    ifTrue: [ 

      | logEntry |

      logEntry := WAObjectLogEntry

        error: anException description

        continuation: continuation. "the continuation is not resumable"

      logEntry resumeContinuation.

      logEntry addToLog.

      ^ continuation ].

  action == #'debug'

    ifTrue: [ self halt ]

That uses Grease which I would expect you have it loaded. WAObjectLogEntry is from Seaside but it's a very stupid subclass. so if you are not using Seaside you could just copy that class and give it whatever name and put it in your code. 

Once the continuation has been created and stored in the ObjectLog all you have to do is to connect with tODE and open a debugger on it.

BTW, be sure to cleanup the object log as continuations are heavy:  http://ws.stfx.eu/2LSEXBAMZT23

 

--

Mariano
http://marianopeck.wordpress.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

--

Mariano
http://marianopeck.wordpress.com

https://github.com/SeasideSt/Seaside/blob/master/repository/Seaside-GemStone-Environment.package/GRGemStonePlatform.extension/instance/canDebugInteractively.st

Do you have the implementation of #canDebugInteractively ?

Marten

Mariano Martinez Peck [hidden email] hat am 22. Januar 2018 um 19:30 geschrieben:

On Mon, Jan 22, 2018 at 3:14 PM, Marten Feldtmann via Glass <[hidden email]> wrote:

Hmm,

honestly I simply do not understand how this works :-(((((

If I have an exception within my REST API calls I normally have to abort the transaction, so that nothing has changed ...  therefore how can I save a continuation into the database ??

Its a shame I know, but I simply do not get it ...

It's not a shame. I think the word "continuation" has been confusing since several years already. And I think its confusing because of its association with Seaside and the back button etc. 

Let's talk about what it is for GemStone (well, at least what I understand from it):

When an exception is signaled, and you read to an exception handler, from the exception you can get the signaler context, right? That means that somehow you have access the the stack that triggered that error (stack of method context instances).  As far as I understand, the # callCC does something *like* a deep copy of the stack. Its not a full 100% deep copy as you might end up copying the whole extent. I guess there is a treshold somewhere. 

Once the continuation has been created (imageine you now have a kind of a deep copy of the stack), then you are able to persist it as any other persistent object. The object log is just one persistent object that makes it easy to store this but it could be anywhere. 

Then, you can simply open a debugger on a persisted continuation. 

So... I imagine you can do something like this:

[ 

 " Your rest code here" 

 ]

on: Error do: [ :ex |  

   System abortTransaction. 

Sytem beginTransaction.

    FaSmalltalkPlatform current saveExceptionContinuation: ex.

System commitTransaction. 

]

Hope this is clearer...if not let me know. And maybe GemStone people may have something to correct from what I said.

Best,

 

 

Mariano Martinez Peck via Glass < [hidden email]> hat am 22. Januar 2018 um 13:05 geschrieben:

On Sun, Jan 21, 2018 at 1:35 PM, Dale Henrichs via Glass < [hidden email]> wrote:

Marten,

Did you know that you should be able to open a debugger on a continuation - it is possible with tODE and GemTools. I think that most folks find this a reasonable solution.

 

That's what I do. I do it at Seaside error handler as well as in some other error handlers (like background jobs).

What I do is basically:

-----

[ self codeThatCouldTriggerErrorAndIW antToSaveAContinuationForLater Debugging ]

on: Error do: [ :ex |  

    FaSmalltalkPlatform current saveExceptionContinuation: exception.

]

----

FaGemStonePlatform class >> saveExceptionContinuation: anException

  | continuation action |

  GRPlatform current canDebugInteractively

    ifTrue: [ anException pass ].

  GRPlatform current

    logError: anException description

    title: 'Continuation saved to object log'.

  action := [ :cont | 

  continuation := cont.

  #'create' ] callCC.

  action == #'create'

    ifTrue: [ 

      | logEntry |

      logEntry := WAObjectLogEntry

        error: anException description

        continuation: continuation. "the continuation is not resumable"

      logEntry resumeContinuation.

      logEntry addToLog.

      ^ continuation ].

  action == #'debug'

    ifTrue: [ self halt ]

That uses Grease which I would expect you have it loaded. WAObjectLogEntry is from Seaside but it's a very stupid subclass. so if you are not using Seaside you could just copy that class and give it whatever name and put it in your code. 

Once the continuation has been created and stored in the ObjectLog all you have to do is to connect with tODE and open a debugger on it.

BTW, be sure to cleanup the object log as continuations are heavy:  http://ws.stfx.eu/2LSEXBAMZT23

 

--

Mariano
http://marianopeck.wordpress.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

--

Mariano
http://marianopeck.wordpress.com

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

Thank you to all answers ...

Marten

Dale Henrichs via Glass <[hidden email]> hat am 23. Januar 2018 um 00:07 geschrieben:

https://github.com/SeasideSt/Seaside/blob/master/repository/Seaside-GemStone-Environment.package/GRGemStonePlatform.extension/instance/canDebugInteractively.st

On 01/22/2018 12:54 PM, Marten Feldtmann via Glass wrote:

Do you have the implementation of #canDebugInteractively ?

Marten

Mariano Martinez Peck [hidden email] hat am 22. Januar 2018 um 19:30 geschrieben:

On Mon, Jan 22, 2018 at 3:14 PM, Marten Feldtmann via Glass < [hidden email]> wrote:

Hmm,

honestly I simply do not understand how this works :-(((((

If I have an exception within my REST API calls I normally have to abort the transaction, so that nothing has changed ...  therefore how can I save a continuation into the database ??

Its a shame I know, but I simply do not get it ...

It's not a shame. I think the word "continuation" has been confusing since several years already. And I think its confusing because of its association with Seaside and the back button etc. 

Let's talk about what it is for GemStone (well, at least what I understand from it):

When an exception is signaled, and you read to an exception handler, from the exception you can get the signaler context, right? That means that somehow you have access the the stack that triggered that error (stack of method context instances).  As far as I understand, the # callCC does something *like* a deep copy of the stack. Its not a full 100% deep copy as you might end up copying the whole extent. I guess there is a treshold somewhere. 

Once the continuation has been created (imageine you now have a kind of a deep copy of the stack), then you are able to persist it as any other persistent object. The object log is just one persistent object that makes it easy to store this but it could be anywhere. 

Then, you can simply open a debugger on a persisted continuation. 

So... I imagine you can do something like this:

[ 

 " Your rest code here" 

 ]

on: Error do: [ :ex |  

   System abortTransaction. 

Sytem beginTransaction.

    FaSmalltalkPlatform current saveExceptionContinuation: ex.

System commitTransaction. 

]

Hope this is clearer...if not let me know. And maybe GemStone people may have something to correct from what I said.

Best,

 

 

Mariano Martinez Peck via Glass < [hidden email]> hat am 22. Januar 2018 um 13:05 geschrieben:

On Sun, Jan 21, 2018 at 1:35 PM, Dale Henrichs via Glass < [hidden email]> wrote:

Marten,

Did you know that you should be able to open a debugger on a continuation - it is possible with tODE and GemTools. I think that most folks find this a reasonable solution.

 

That's what I do. I do it at Seaside error handler as well as in some other error handlers (like background jobs).

What I do is basically:

-----

[ self codeThatCouldTriggerErrorAndIW antToSaveAContinuationForLater Debugging ]

on: Error do: [ :ex |  

    FaSmalltalkPlatform current saveExceptionContinuation: exception.

]

----

FaGemStonePlatform class >> saveExceptionContinuation: anException

  | continuation action |

  GRPlatform current canDebugInteractively

    ifTrue: [ anException pass ].

  GRPlatform current

    logError: anException description

    title: 'Continuation saved to object log'.

  action := [ :cont | 

  continuation := cont.

  #'create' ] callCC.

  action == #'create'

    ifTrue: [ 

      | logEntry |

      logEntry := WAObjectLogEntry

        error: anException description

        continuation: continuation. "the continuation is not resumable"

      logEntry resumeContinuation.

      logEntry addToLog.

      ^ continuation ].

  action == #'debug'

    ifTrue: [ self halt ]

That uses Grease which I would expect you have it loaded. WAObjectLogEntry is from Seaside but it's a very stupid subclass. so if you are not using Seaside you could just copy that class and give it whatever name and put it in your code. 

Once the continuation has been created and stored in the ObjectLog all you have to do is to connect with tODE and open a debugger on it.

BTW, be sure to cleanup the object log as continuations are heavy:  http://ws.stfx.eu/2LSEXBAMZT23

 

--

Mariano
http://marianopeck.wordpress.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

--

Mariano
http://marianopeck.wordpress.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

Yes, I implemented it in our production code and it has shown already how useful it is.

Marten

Mariano Martinez Peck <[hidden email]> hat am 23. Januar 2018 um 13:30 geschrieben:

On Tue, Jan 23, 2018 at 5:33 AM, Marten Feldtmann via Glass <[hidden email]> wrote:

Thank you to all answers ...

No problem. Just let us know if it worked ;)

 

 

Dale Henrichs via Glass < [hidden email]> hat am 23. Januar 2018 um 00:07 geschrieben:

https://github.com/SeasideSt/Seaside/blob/master/repository/Seaside-GemStone-Environment.package/GRGemStonePlatform.extension/instance/canDebugInteractively.st

On 01/22/2018 12:54 PM, Marten Feldtmann via Glass wrote:

Do you have the implementation of #canDebugInteractively ?

Marten

Mariano Martinez Peck [hidden email] hat am 22. Januar 2018 um 19:30 geschrieben:

On Mon, Jan 22, 2018 at 3:14 PM, Marten Feldtmann via Glass < [hidden email] > wrote:

Hmm,

honestly I simply do not understand how this works :-(((((

If I have an exception within my REST API calls I normally have to abort the transaction, so that nothing has changed ...  therefore how can I save a continuation into the database ??

Its a shame I know, but I simply do not get it ...

It's not a shame. I think the word "continuation" has been confusing since several years already. And I think its confusing because of its association with Seaside and the back button etc. 

Let's talk about what it is for GemStone (well, at least what I understand from it):

When an exception is signaled, and you read to an exception handler, from the exception you can get the signaler context, right? That means that somehow you have access the the stack that triggered that error (stack of method context instances).  As far as I understand, the # callCC does something *like* a deep copy of the stack. Its not a full 100% deep copy as you might end up copying the whole extent. I guess there is a treshold somewhere. 

Once the continuation has been created (imageine you now have a kind of a deep copy of the stack), then you are able to persist it as any other persistent object. The object log is just one persistent object that makes it easy to store this but it could be anywhere. 

Then, you can simply open a debugger on a persisted continuation. 

So... I imagine you can do something like this:

[ 

 " Your rest code here" 

 ]

on: Error do: [ :ex |  

   System abortTransaction. 

Sytem beginTransaction.

    FaSmalltalkPlatform current saveExceptionContinuation: ex.

System commitTransaction. 

]

Hope this is clearer...if not let me know. And maybe GemStone people may have something to correct from what I said.

Best,

 

 

Mariano Martinez Peck via Glass < [hidden email] > hat am 22. Januar 2018 um 13:05 geschrieben:

On Sun, Jan 21, 2018 at 1:35 PM, Dale Henrichs via Glass < [hidden email] > wrote:

Marten,

Did you know that you should be able to open a debugger on a continuation - it is possible with tODE and GemTools. I think that most folks find this a reasonable solution.

 

That's what I do. I do it at Seaside error handler as well as in some other error handlers (like background jobs).

What I do is basically:

-----

[ self codeThatCouldTriggerErrorAndIW antToSaveAContinuationForLater Debugging ]

on: Error do: [ :ex |  

    FaSmalltalkPlatform current saveExceptionContinuation: exception.

]

----

FaGemStonePlatform class >> saveExceptionContinuation: anException

  | continuation action |

  GRPlatform current canDebugInteractively

    ifTrue: [ anException pass ].

  GRPlatform current

    logError: anException description

    title: 'Continuation saved to object log'.

  action := [ :cont | 

  continuation := cont.

  #'create' ] callCC.

  action == #'create'

    ifTrue: [ 

      | logEntry |

      logEntry := WAObjectLogEntry

        error: anException description

        continuation: continuation. "the continuation is not resumable"

      logEntry resumeContinuation.

      logEntry addToLog.

      ^ continuation ].

  action == #'debug'

    ifTrue: [ self halt ]

That uses Grease which I would expect you have it loaded. WAObjectLogEntry is from Seaside but it's a very stupid subclass. so if you are not using Seaside you could just copy that class and give it whatever name and put it in your code. 

Once the continuation has been created and stored in the ObjectLog all you have to do is to connect with tODE and open a debugger on it.

BTW, be sure to cleanup the object log as continuations are heavy:  http://ws.stfx.eu/2LSEXBAMZT23

 

--

Mariano
http://marianopeck.wordpress.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

--

Mariano
http://marianopeck.wordpress.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

 

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

--

Mariano
http://marianopeck.wordpress.com

Hey,

I actually removed the code from our production code ... I got strange errors with external references and this broke my application

Marten

Mariano Martinez Peck <[hidden email]> hat am 23. Januar 2018 um 13:30 geschrieben:

On Tue, Jan 23, 2018 at 5:33 AM, Marten Feldtmann via Glass <[hidden email]> wrote:

Thank you to all answers ...

No problem. Just let us know if it worked ;)

 

 

Dale Henrichs via Glass < [hidden email]> hat am 23. Januar 2018 um 00:07 geschrieben:

https://github.com/SeasideSt/Seaside/blob/master/repository/Seaside-GemStone-Environment.package/GRGemStonePlatform.extension/instance/canDebugInteractively.st

On 01/22/2018 12:54 PM, Marten Feldtmann via Glass wrote:

Do you have the implementation of #canDebugInteractively ?

Marten

Mariano Martinez Peck [hidden email] hat am 22. Januar 2018 um 19:30 geschrieben:

On Mon, Jan 22, 2018 at 3:14 PM, Marten Feldtmann via Glass < [hidden email] > wrote:

Hmm,

honestly I simply do not understand how this works :-(((((

If I have an exception within my REST API calls I normally have to abort the transaction, so that nothing has changed ...  therefore how can I save a continuation into the database ??

Its a shame I know, but I simply do not get it ...

It's not a shame. I think the word "continuation" has been confusing since several years already. And I think its confusing because of its association with Seaside and the back button etc. 

Let's talk about what it is for GemStone (well, at least what I understand from it):

When an exception is signaled, and you read to an exception handler, from the exception you can get the signaler context, right? That means that somehow you have access the the stack that triggered that error (stack of method context instances).  As far as I understand, the # callCC does something *like* a deep copy of the stack. Its not a full 100% deep copy as you might end up copying the whole extent. I guess there is a treshold somewhere. 

Once the continuation has been created (imageine you now have a kind of a deep copy of the stack), then you are able to persist it as any other persistent object. The object log is just one persistent object that makes it easy to store this but it could be anywhere. 

Then, you can simply open a debugger on a persisted continuation. 

So... I imagine you can do something like this:

[ 

 " Your rest code here" 

 ]

on: Error do: [ :ex |  

   System abortTransaction. 

Sytem beginTransaction.

    FaSmalltalkPlatform current saveExceptionContinuation: ex.

System commitTransaction. 

]

Hope this is clearer...if not let me know. And maybe GemStone people may have something to correct from what I said.

Best,

 

 

Mariano Martinez Peck via Glass < [hidden email] > hat am 22. Januar 2018 um 13:05 geschrieben:

On Sun, Jan 21, 2018 at 1:35 PM, Dale Henrichs via Glass < [hidden email] > wrote:

Marten,

Did you know that you should be able to open a debugger on a continuation - it is possible with tODE and GemTools. I think that most folks find this a reasonable solution.

 

That's what I do. I do it at Seaside error handler as well as in some other error handlers (like background jobs).

What I do is basically:

-----

[ self codeThatCouldTriggerErrorAndIW antToSaveAContinuationForLater Debugging ]

on: Error do: [ :ex |  

    FaSmalltalkPlatform current saveExceptionContinuation: exception.

]

----

FaGemStonePlatform class >> saveExceptionContinuation: anException

  | continuation action |

  GRPlatform current canDebugInteractively

    ifTrue: [ anException pass ].

  GRPlatform current

    logError: anException description

    title: 'Continuation saved to object log'.

  action := [ :cont | 

  continuation := cont.

  #'create' ] callCC.

  action == #'create'

    ifTrue: [ 

      | logEntry |

      logEntry := WAObjectLogEntry

        error: anException description

        continuation: continuation. "the continuation is not resumable"

      logEntry resumeContinuation.

      logEntry addToLog.

      ^ continuation ].

  action == #'debug'

    ifTrue: [ self halt ]

That uses Grease which I would expect you have it loaded. WAObjectLogEntry is from Seaside but it's a very stupid subclass. so if you are not using Seaside you could just copy that class and give it whatever name and put it in your code. 

Once the continuation has been created and stored in the ObjectLog all you have to do is to connect with tODE and open a debugger on it.

BTW, be sure to cleanup the object log as continuations are heavy:  http://ws.stfx.eu/2LSEXBAMZT23

 

--

Mariano
http://marianopeck.wordpress.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

--

Mariano
http://marianopeck.wordpress.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

 

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

--

Mariano
http://marianopeck.wordpress.com

Marten,

If you supply some stacks for the strange errors it is possible that we could diagnose and fix the issue ...

Dale

Hey,

I actually removed the code from our production code ... I got strange errors with external references and this broke my application

Marten

Mariano Martinez Peck [hidden email] hat am 23. Januar 2018 um 13:30 geschrieben:

On Tue, Jan 23, 2018 at 5:33 AM, Marten Feldtmann via Glass <[hidden email]> wrote:

Thank you to all answers ...

No problem. Just let us know if it worked ;)

 

 

Dale Henrichs via Glass < [hidden email]> hat am 23. Januar 2018 um 00:07 geschrieben:

https://github.com/SeasideSt/Seaside/blob/master/repository/Seaside-GemStone-Environment.package/GRGemStonePlatform.extension/instance/canDebugInteractively.st

On 01/22/2018 12:54 PM, Marten Feldtmann via Glass wrote:

Do you have the implementation of #canDebugInteractively ?

Marten

Mariano Martinez Peck [hidden email] hat am 22. Januar 2018 um 19:30 geschrieben:

On Mon, Jan 22, 2018 at 3:14 PM, Marten Feldtmann via Glass < [hidden email] > wrote:

Hmm,

honestly I simply do not understand how this works :-(((((

If I have an exception within my REST API calls I normally have to abort the transaction, so that nothing has changed ...  therefore how can I save a continuation into the database ??

Its a shame I know, but I simply do not get it ...

It's not a shame. I think the word "continuation" has been confusing since several years already. And I think its confusing because of its association with Seaside and the back button etc. 

Let's talk about what it is for GemStone (well, at least what I understand from it):

When an exception is signaled, and you read to an exception handler, from the exception you can get the signaler context, right? That means that somehow you have access the the stack that triggered that error (stack of method context instances).  As far as I understand, the # callCC does something *like* a deep copy of the stack. Its not a full 100% deep copy as you might end up copying the whole extent. I guess there is a treshold somewhere. 

Once the continuation has been created (imageine you now have a kind of a deep copy of the stack), then you are able to persist it as any other persistent object. The object log is just one persistent object that makes it easy to store this but it could be anywhere. 

Then, you can simply open a debugger on a persisted continuation. 

So... I imagine you can do something like this:

[ 

 " Your rest code here" 

 ]

on: Error do: [ :ex |  

   System abortTransaction. 

Sytem beginTransaction.

    FaSmalltalkPlatform current saveExceptionContinuation: ex.

System commitTransaction. 

]

Hope this is clearer...if not let me know. And maybe GemStone people may have something to correct from what I said.

Best,

 

 

Mariano Martinez Peck via Glass < [hidden email] > hat am 22. Januar 2018 um 13:05 geschrieben:

On Sun, Jan 21, 2018 at 1:35 PM, Dale Henrichs via Glass < [hidden email] > wrote:

Marten,

Did you know that you should be able to open a debugger on a continuation - it is possible with tODE and GemTools. I think that most folks find this a reasonable solution.

 

That's what I do. I do it at Seaside error handler as well as in some other error handlers (like background jobs).

What I do is basically:

-----

[ self codeThatCouldTriggerErrorAndIW antToSaveAContinuationForLater Debugging ]

on: Error do: [ :ex |  

    FaSmalltalkPlatform current saveExceptionContinuation: exception.

]

----

FaGemStonePlatform class >> saveExceptionContinuation: anException

  | continuation action |

  GRPlatform current canDebugInteractively

    ifTrue: [ anException pass ].

  GRPlatform current

    logError: anException description

    title: 'Continuation saved to object log'.

  action := [ :cont | 

  continuation := cont.

  #'create' ] callCC.

  action == #'create'

    ifTrue: [ 

      | logEntry |

      logEntry := WAObjectLogEntry

        error: anException description

        continuation: continuation. "the continuation is not resumable"

      logEntry resumeContinuation.

      logEntry addToLog.

      ^ continuation ].

  action == #'debug'

    ifTrue: [ self halt ]

That uses Grease which I would expect you have it loaded. WAObjectLogEntry is from Seaside but it's a very stupid subclass. so if you are not using Seaside you could just copy that class and give it whatever name and put it in your code. 

Once the continuation has been created and stored in the ObjectLog all you have to do is to connect with tODE and open a debugger on it.

BTW, be sure to cleanup the object log as continuations are heavy:  http://ws.stfx.eu/2LSEXBAMZT23

 

--

Mariano
http://marianopeck.wordpress.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

--

Mariano
http://marianopeck.wordpress.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

 

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

--

Mariano
http://marianopeck.wordpress.com

I lost the content of external memory pointers ... have no stack traces

Marten

Dale Henrichs <[hidden email]> hat am 15. März 2018 um 15:18 geschrieben:

Marten,

If you supply some stacks for the strange errors it is possible that we could diagnose and fix the issue ...

Dale

On 03/15/2018 01:09 AM, Marten Feldtmann wrote:

Hey,

I actually removed the code from our production code ... I got strange errors with external references and this broke my application

Marten

Mariano Martinez Peck [hidden email] hat am 23. Januar 2018 um 13:30 geschrieben:

On Tue, Jan 23, 2018 at 5:33 AM, Marten Feldtmann via Glass < [hidden email]> wrote:

Thank you to all answers ...

No problem. Just let us know if it worked ;)

 

 

Dale Henrichs via Glass < [hidden email]> hat am 23. Januar 2018 um 00:07 geschrieben:

https://github.com/SeasideSt/Seaside/blob/master/repository/Seaside-GemStone-Environment.package/GRGemStonePlatform.extension/instance/canDebugInteractively.st

On 01/22/2018 12:54 PM, Marten Feldtmann via Glass wrote:

Do you have the implementation of #canDebugInteractively ?

Marten

Mariano Martinez Peck [hidden email] hat am 22. Januar 2018 um 19:30 geschrieben:

On Mon, Jan 22, 2018 at 3:14 PM, Marten Feldtmann via Glass < [hidden email] > wrote:

Hmm,

honestly I simply do not understand how this works :-(((((

If I have an exception within my REST API calls I normally have to abort the transaction, so that nothing has changed ...  therefore how can I save a continuation into the database ??

Its a shame I know, but I simply do not get it ...

It's not a shame. I think the word "continuation" has been confusing since several years already. And I think its confusing because of its association with Seaside and the back button etc. 

Let's talk about what it is for GemStone (well, at least what I understand from it):

When an exception is signaled, and you read to an exception handler, from the exception you can get the signaler context, right? That means that somehow you have access the the stack that triggered that error (stack of method context instances).  As far as I understand, the # callCC does something *like* a deep copy of the stack. Its not a full 100% deep copy as you might end up copying the whole extent. I guess there is a treshold somewhere. 

Once the continuation has been created (imageine you now have a kind of a deep copy of the stack), then you are able to persist it as any other persistent object. The object log is just one persistent object that makes it easy to store this but it could be anywhere. 

Then, you can simply open a debugger on a persisted continuation. 

So... I imagine you can do something like this:

[ 

 " Your rest code here" 

 ]

on: Error do: [ :ex |  

   System abortTransaction. 

Sytem beginTransaction.

    FaSmalltalkPlatform current saveExceptionContinuation: ex.

System commitTransaction. 

]

Hope this is clearer...if not let me know. And maybe GemStone people may have something to correct from what I said.

Best,

 

 

Mariano Martinez Peck via Glass < [hidden email] > hat am 22. Januar 2018 um 13:05 geschrieben:

On Sun, Jan 21, 2018 at 1:35 PM, Dale Henrichs via Glass < [hidden email] > wrote:

Marten,

Did you know that you should be able to open a debugger on a continuation - it is possible with tODE and GemTools. I think that most folks find this a reasonable solution.

 

That's what I do. I do it at Seaside error handler as well as in some other error handlers (like background jobs).

What I do is basically:

-----

[ self codeThatCouldTriggerErrorAndIW antToSaveAContinuationForLater Debugging ]

on: Error do: [ :ex |  

    FaSmalltalkPlatform current saveExceptionContinuation: exception.

]

----

FaGemStonePlatform class >> saveExceptionContinuation: anException

  | continuation action |

  GRPlatform current canDebugInteractively

    ifTrue: [ anException pass ].

  GRPlatform current

    logError: anException description

    title: 'Continuation saved to object log'.

  action := [ :cont | 

  continuation := cont.

  #'create' ] callCC.

  action == #'create'

    ifTrue: [ 

      | logEntry |

      logEntry := WAObjectLogEntry

        error: anException description

        continuation: continuation. "the continuation is not resumable"

      logEntry resumeContinuation.

      logEntry addToLog.

      ^ continuation ].

  action == #'debug'

    ifTrue: [ self halt ]

That uses Grease which I would expect you have it loaded. WAObjectLogEntry is from Seaside but it's a very stupid subclass. so if you are not using Seaside you could just copy that class and give it whatever name and put it in your code. 

Once the continuation has been created and stored in the ObjectLog all you have to do is to connect with tODE and open a debugger on it.

BTW, be sure to cleanup the object log as continuations are heavy:  http://ws.stfx.eu/2LSEXBAMZT23

 

--

Mariano
http://marianopeck.wordpress.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

--

Mariano
http://marianopeck.wordpress.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

 

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

--

Mariano
http://marianopeck.wordpress.com