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

Dale Henrichs dale.henrichs at gemtalksystems.com
Tue Jan 21 10:16:02 PST 2014


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 <dario.trussardi at tiscali.it
> 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
> > Glass at lists.gemtalksystems.com
> > http://lists.gemtalksystems.com/mailman/listinfo/glass
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140121/8c1f81cd/attachment.html>


More information about the Glass mailing list