[Glass] Gem go down when ex retry is manage for aBlock on: do:

Dario,

Yes, trying to do a seaside callback inside the exception is a use case that has not been tested in GemStone, so I am not surpirsed that it causes a nasty problem...

Off the top of my head, I can think of a couple of different approaches:

  - given that it may take time for the print connection to succeed, I'd replace the

    Delay loop with a call to a sevice vm that way the seaside gem is not blocked

    while waiting for the print job to be handled

  - you might be able to successfully trigger a dialog to pop up if you can 

    avoid making the jquery call inside the exception block ... something where you

    set a flag inside the exception block and pop up the dialog for retry in the

    code following the exception might work as well ...

There might be other approaches as well...

Dale

On Tue, Jan 21, 2014 at 8:41 AM, Dario Trussardi <[hidden email]> wrote:

Hi,

> HI,
>
>       i have a code to open tcp/ip connection and send data to relative printer device.
>
>
>       The code work fine into Pharo but i have problem into GLASS.
>
>
>       The code is :
>
>       [TicketBaseTipoCentriCarico newOn: dcmModel dettagli: tfDettagli onPrinter: rfrMaster aPrinterTicket ]
>
>                                                               on: Error do: [:ex |
>

        i remove the jqDialog user action

>                                                                                               self  jqDialog: (DTRCassaDialogConferma openOnException: ex onModel: dcmModel)
>
>                                                                                               title: 'ERRORE STAMPA'.
>

        and add :                         ( Delay forSeconds: 20) wait.

>
>                                                                                       ex retry]
>

        With this code the      ex retry                work fine :    it loop until the connection is ok.


        A this point how i can manage the browser interface to advised the user  of the connection problem and resubmit the printer task ?


The AbstractException class   retry method  is :

        AbstractException       retry
          "When sent within an ANSI handler's handlerBlock ,
           resume execution by sending  #value  to the receiver of the
           #on:do: send which installed the currently active handlerBlock ,
         and using the stack frame of that #on:do: .

          Any ensure: blocks between top of stack and that #on:do: will
         be executed and stack trimmed back before resuming execution.

        Generates an error if sent within a legacy handler's handlerBlock,
        or if stack trim would cross the frame of a C primitive or user action."

        ^self retryUsing: nil

        This             user action             is in conflict with the jqDialog ???

        Thanks for any advise,

                Dario

>
>       A)      The     block :
>
>                        [TicketBaseTipoCentriCarico newOn: dcmModel dettagli: tfDettagli onPrinter: rfrMaster aPrinterTicket ]
>
>
>               open a tcp/ip connection and send data to the printer.
>
>       B) The  on: Error do: [:ex |
>
>                       is define to manage  some connection problem ( for example if the tcp/ip  printer is off )
>
>                       If this happens the   jqDialog is open  to indicate at the user the problem.
>
>
>
>       Now in Pharo when i have a connection problem and the:           ex retry                  is execute   all work fine,
>
>               and the retry  loop with jqDialog  segnalation  until the  connection is ok,  and the ticket is printed.
>
>
>       Into GLASS when i have connection problem and the:         ex retry             is  execute  the relative gem go down
>
>                       and i need soon to restart  the GLASS environment  (All WAFastCGIAdaptor is down )
>
>
>       Thanks for any considerations.
>
>               Dario
>
> P.S. Of course if the connection is ok all works fine in both the environment.
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

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

Ciao, 

Dario,

Yes, trying to do a seaside callback inside the exception is a use case that has not been tested in GemStone, so I am not surpirsed that it causes a nasty problem...

Off the top of my head, I can think of a couple of different approaches:

  - given that it may take time for the print connection to succeed, I'd replace the

    Delay loop with a call to a sevice vm that way the seaside gem is not blocked

    while waiting for the print job to be handled

what service ?

  - you might be able to successfully trigger a dialog to pop up if you can 

    avoid making the jquery call inside the exception block ... something where you

    set a flag inside the exception block and pop up the dialog for retry in the

    code following the exception might work as well ...

How i can open a pop up when exception occured ?

Anyone has an example about it ?

There might be other approaches as well...

I change my code for go out from exception :   ex return: false

and manage a new request .

With this the whileFalse loop ok two times, after the gem go down.

[ stampaok]  whileFalse:[ 

stampaok := true.

 [TicketBaseTipoCentriCarico newOn: dcmModel dettagli: tfDettagli onPrinter: rfrMaster aPrinterTicket ]

 on: Error do: [:ex |

self  jqDialog:  (DTRCassaDialogConferma openOnException: ex onModel: dcmModel)

title: 'ERRORE STAMPA'.

stampaok := false.

ex return: false.

 ]

].

I allegate the relative  WAFast*** .log.

Thanks,

Dario

<WAFastCGIAdaptor_server-9040.log>

<WAFastCGIAdaptor_start-9040.log>

Dale

On Tue, Jan 21, 2014 at 8:41 AM, Dario Trussardi <[hidden email]> wrote:

Hi,

> HI,
>
>       i have a code to open tcp/ip connection and send data to relative printer device.
>
>
>       The code work fine into Pharo but i have problem into GLASS.
>
>
>       The code is :
>
>       [TicketBaseTipoCentriCarico newOn: dcmModel dettagli: tfDettagli onPrinter: rfrMaster aPrinterTicket ]
>
>                                                               on: Error do: [:ex |
>

        i remove the jqDialog user action

>                                                                                               self  jqDialog: (DTRCassaDialogConferma openOnException: ex onModel: dcmModel)
>
>                                                                                               title: 'ERRORE STAMPA'.
>

        and add :                         ( Delay forSeconds: 20) wait.

>
>                                                                                       ex retry]
>

        With this code the      ex retry                work fine :    it loop until the connection is ok.


        A this point how i can manage the browser interface to advised the user  of the connection problem and resubmit the printer task ?


The AbstractException class   retry method  is :

        AbstractException       retry
          "When sent within an ANSI handler's handlerBlock ,
           resume execution by sending  #value  to the receiver of the
           #on:do: send which installed the currently active handlerBlock ,
         and using the stack frame of that #on:do: .

          Any ensure: blocks between top of stack and that #on:do: will
         be executed and stack trimmed back before resuming execution.

        Generates an error if sent within a legacy handler's handlerBlock,
        or if stack trim would cross the frame of a C primitive or user action."

        ^self retryUsing: nil

        This             user action             is in conflict with the jqDialog ???

        Thanks for any advise,

                Dario

>
>       A)      The     block :
>
>                        [TicketBaseTipoCentriCarico newOn: dcmModel dettagli: tfDettagli onPrinter: rfrMaster aPrinterTicket ]
>
>
>               open a tcp/ip connection and send data to the printer.
>
>       B) The  on: Error do: [:ex |
>
>                       is define to manage  some connection problem ( for example if the tcp/ip  printer is off )
>
>                       If this happens the   jqDialog is open  to indicate at the user the problem.
>
>
>
>       Now in Pharo when i have a connection problem and the:           ex retry                  is execute   all work fine,
>
>               and the retry  loop with jqDialog  segnalation  until the  connection is ok,  and the ticket is printed.
>
>
>       Into GLASS when i have connection problem and the:         ex retry             is  execute  the relative gem go down
>
>                       and i need soon to restart  the GLASS environment  (All WAFastCGIAdaptor is down )
>
>
>       Thanks for any considerations.
>
>               Dario
>
> P.S. Of course if the connection is ok all works fine in both the environment.
> _______________________________________________
> 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

On Thu, Jan 23, 2014 at 4:02 AM, Dario Trussardi <[hidden email]> wrote:

The service vm is described here[1]

[1] https://code.google.com/p/glassdb/wiki/ServiceVMExample 

>>
>>>   - you might be able to successfully trigger a dialog to pop up if you can
>>>     avoid making the jquery call inside the exception block ... something where you
>>>     set a flag inside the exception block and pop up the dialog for retry in the
>>>     code following the exception might work as well ...
>>
>>      How i can open a pop up when exception occured ?
>>
>>      Anyone has an example about it ?
>>
>>
>>>
>>> There might be other approaches as well...
>>>

I complete extrapolate the iqDialog from on: do:  exception :

                stampaok:= false.
                erroreTcpIP := false.

                [ stampaok]  whileFalse:[
                        stampaok := true.

                        erroreTcpIP ifTrue:[ self jqDialog: ( DTRCassaDialogConferma openOnException: exRef
                                                                                                                                onModel: dcmModel)
                                                                                title: 'ERRORE STAMPA'. ].

                         [TicketBaseTipoCentriCarico newOn: dcmModel dettagli: tfDettagli onPrinter: rfrMaster aPrinterTicket ]

                                 on: PrinterError do: [:ex |    exRef := ex .
                                                                        erroreTcpIP := true.

                                                                        stampaok := false.
                                                                        ex return: false. ].
                                                                ].

Now the while loop work fine.

I would think that this while loop would be touchy to use in a multi-vm GemStone scenario since http requests would be delivered to a different vm, unless you are using session affinity or a single gem