Multiple GS sessions in Polycephaly drone
Locked
 
|
Hello, I'm looking for some diagnostic advice. Our Seaside application runs in VW, using several images, each with several GS sessions. One 'dispatcher' image communicates to each application image with OpenTalk for status and control, and redirects initial logins. All works fine. I wanted a simpler way to manage this multi-image setup, so I wrote a version that uses Polycephaly. All works: each drone is able to log in to GemStone and serve a Seaside interface on
its own port. Our web server setup allows for multiple shared GS sessions, and it works fine in the separate image configuration. It also works fine if I spawn a DebugMachine instead of a ViritualMachine. However, if I use a VirutalMachine, logging in the second GS session locks up the Seaside interface and I get an 'Connection can not reopen!' on the ExternalWriteStream for that drone. Any suggestions on how to diagnose this? It's probably a unique mix of Polycephaly and GS; it would be cool to hear of another setup. FWIW: I have... GbsConfiguration current confirm: false. GbsConfiguration current verbose: false. Thanks for any help, Bob Nemec HTS Engineering _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Bob Nemec
|
Re: Multiple GS sessions in Polycephaly drone
|
|
Have you tried using Poly2 instead? There's issues in Poly1 of stdout getting reused by other interfaces accidentally and breaking the poly communication. Besides that, I'm not sure - debug just keeps things headful, so if there's some code that needs the system to be headful and it's not when you run it in normal mode, perhaps that's the problem. Michael On 31/05/2013, at 12:25 AM, [hidden email] wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Michael, Using Polycephaly2 fixed the problem, Thank you, Bob From: Michael Lucas-Smith <[hidden email]> To: [hidden email] Cc: "[hidden email]" <[hidden email]>; "[hidden email]" <[hidden email]> Sent: Thursday, May 30, 2013 10:59:48 AM Subject: Re: [vwnc] Multiple GS sessions in Polycephaly drone Have you tried using Poly2 instead? There's issues in Poly1 of stdout getting reused by other interfaces accidentally and breaking the poly communication. Besides that, I'm not sure
- debug just keeps things headful, so if there's some code that needs the system to be headful and it's not when you run it in normal mode, perhaps that's the problem. Michael On 31/05/2013, at 12:25 AM, [hidden email] wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Bob Nemec
|
Re: [GemStone-Smalltalk] Multiple GS sessions in Polycephaly drone
|
|
In reply to this post by Bob Nemec
Hi Bob, Suspect a deadlock with two semaphores acquired in a different sequence by two processes. I’ve found and avoided several of these over the years. I recall at
least one would happen with code that is also used during debugging. A trick for diagnosing is to have a background process that does a “GbsConfiguration dumpAllProcessStacks” every 30 seconds or so. All process stacks get written
to a file that you can review. Review the most recent file after you notice a hang. Look for two processes each holding a semaphore and waiting on the semaphore held by the other. If the GBS version you use still has bugs like mentioned above then this trick
may not work very well for you, but it is the approach that I use once the tools are fixed to allow it. “logging in the second GS session locks up the Seaside interface” You might want to refactor your code so that a background process handling requests is separate from the process that handles UI events. If the background process
needs to do something UI related then have that happen within a #uiEventFor: block. It may be that Polycephaly is already giving you the UI separation but that your code needs #uiEventFor: for when a background process does something that involves a UI change.
“It's probably a unique mix of Polycephaly and GS; it would be cool to hear
of another setup.” This is probably overkill for your needs, but… If you have a multiple-producers-but-one-consumer situation then you might think along the lines of a request-queue approach where a queue in VW is serviced
in a background process that waits on a semaphore signal. You might think of it like an RcQueue for VW. An add to the queue would #signal the semaphore. The processing of each request involves a semaphore #wait. The queue acts to isolate and sequence the processing
of requests in a uniform manner through GS. There are many ways you might want to notify when a request has been processed. You may need to protect code from changes in the queue collection (usually done with a second semaphore or a queue design like the EsQueue
that you’d remember from VAST). Paul Baumann From: [hidden email] [mailto:[hidden email]]
On Behalf Of [hidden email] Hello, I'm looking for some diagnostic advice. Our Seaside application runs in VW, using several images, each with several GS sessions. One 'dispatcher'
image communicates to each application image with OpenTalk for status and control, and redirects initial logins. All works fine. I wanted a simpler way to manage this multi-image setup, so I wrote a version that uses Polycephaly. All works: each drone is able to log in to GemStone and serve
a Seaside interface on its own port. Our web server setup allows for multiple shared GS sessions, and it works fine in the separate image configuration. It also works fine if I spawn a DebugMachine
instead of a ViritualMachine. However, if I use a VirutalMachine, logging in the second GS session locks up the Seaside interface and I get an 'Connection can not reopen!' on the ExternalWriteStream for that drone. Any suggestions on how to diagnose this? It's probably a unique mix of Polycephaly and GS; it would be cool to hear of another setup. FWIW: I have... GbsConfiguration current confirm: false. GbsConfiguration current verbose: false. Thanks for any help, Bob Nemec HTS Engineering This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
| Free forum by Nabble | Edit this page |