[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