[vwnc] Anyone running VW 7.6+ on FreeBSD using Linux compatabilty mode?

I'm having some issues with my Linux based VW image on the latest
version of FreeBSD 7.1 stable.. It comes up OK and appears to run OK but
I'm getting hangs when trying to get my Seaside/Glorp web-app going --
likely related to talking to the postgres database via sockets.. It
starts doing something and then goes out to lunch.. VW still responds OK
and I can poke around OK.. I just looked in the Process monitor and see
1 of the following pair for each "retry" I do in the browser (Firefox) :

Opentalk.RemoteRequest>>dispatchFor:
Seaside.WAProcessMonitor>>critical.:ifError:

Now, the image I'm using was put together on a Linux box (FedoraCore6)..
Should I start over from scratch and
re-install VW altogether?  Hmm.. I guess I don't have any other ideas..
I'll try that for now..

Let me know if you can think of any other reasons or suggestions!

-- Rick

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

When I wanted a OpenBSD ( close cousin to FreeBSD)  install of VWST, I
found the release install
ISO CD Image would not start, so I ended up doing a full install
under Linux ( SuSe I think) and *before* installing any packages
or any local changes, I dumped the *complete* directory hierarchy  eg :
vwst7.6/./.. to a cd, then reloaded onto the OpenBSD partition. Not just
the image, but every thing that was installed.

vwst ran OK under OpenBSD from that point.

Hope this helps.



On Wed, 25 Mar 2009 23:56:48 -0700
Rick Flower <[hidden email]> wrote:


--
Cheers,
Brett
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

brett wrote: Thanks.. I know what the problem is -- or more to the point I know where
the problem is.. Apparently the
semaphores work differently under FreeBSD than what was done for Linux.

Below is a stack-dump from one of several of the stuck processes -- all
are stuck in the
same spot :

Name: Seaside.WAProcessMonitor>>critical:ifError:  Priority: 67
Semaphore>>waitIfCurtailedSignal
Semaphore>>critical:
MGConnectionPool class>>lookupConnectionForUser:password:server:database:
MGConnectionPool class>>nextValidConnectionForUser:password:server:database:
MGConnectionPool class>>withUser:password:server:database:in:
MyScrip.MSWCommon_Session>>during:
MyScrip.MSWCommon_Session>>doesNotUnderstand:
optimized [] in MyScrip.MSWCommon_Session>>refreshOrganizationList
BlockClosure>>on:do:
MyScrip.MSWCommon_Session>>refreshOrganizationList
MyScrip.MSWCommon_Session>>organizationList
MyScrip.MSWMenu_NotLoggedIn_Login>>renderLoginFormOn:

Below is the code used to create the Semaphores which was ported from
some code
originally written by Ramon Leon (original name is MGConnectionPool) for
use
w/ Glorp+Seaside under Squeak.  I tailored it a little but it works fine
in Linux and
also MacOSX -- but not FreeBSD (using Linux compat mode)..  In this
case, the first
taker of the semaphore gets stuck in the critical: method below instead
of being allowed
to run -- of course all others coming in behind do the same thing.

------------------------------
Values of the Semaphore member data if it helps anyone :

excessSignals: 0
firstLink : a Process in Semaphore>>waitIfCurtailedSignal
lastLink  : a Process in Semaphore>>waitIfCurtailedSignal
------------------------------


lookupConnectionForUser: aUser password: aPassword server: aServer
database: aDatabase
   | key pool |
   ^ lock
      critical: [key := self
                  makeKeyUser: aUser
                  password: aPassword
                  server: aServer
                  database: aDatabase.
         pool := connectionPools
                  at: key
                  ifAbsentPut: [OrderedCollection new].
         pool
            isEmpty ifTrue: [pool add: (self
                     newLoginForUser: aUser
                     password: aPassword
                     server: aServer
                     database: aDatabase)
                     -&gt; (Chronos.Timepoint now)].
         pool removeFirst]

returnConnection: aConnection forKey: aKey
    lock
        critical: [aConnection value: (Chronos.Timepoint now) .
            (connectionPools at: aKey)
                add: aConnection]</body>


resetPool
    lock := Semaphore forMutualExclusion.
    connectionPools := Dictionary new.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Just a quick followup.. I was able to unstick my stuck semaphore by
issuing a "signal" on the object and
magically all of my database operations started moving along.. I'm not
really sure why it initially got
stuck but will need to keep an eye on things to ensure it doesn't happen
again..

-- Rick


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Rick, just a side thought here.  If any semaphore is being used as an
argument to setSem:forWrite:, make sure something like this doesn't happen.

something setSem: semaphoreA forWrite: aBoolean
...
something setSem: semaphoreB forWrite: theSameBoolean


If this happens, then semaphoreA may get "kicked out" of the semaphore
registry.  As a result, semaphoreB may be signalled, but semaphoreA
won't.  Also, there could be a moment in time where semaphoreA is
signalled but the active process immediately forgets about semaphoreA
because now it's paying attention to semaphoreB.

This may not apply to you exactly, but I thought I'd mention it anyway.  
For example, a while ago I noticed the Postgresql driver doing this.  At
least on Windows, this is clearly visible on the assert VM because the
assertion failure that is there to note that a semaphore gets kicked out
notes the event in the assert VM console.  I have not checked the
Postgresql driver recently, so maybe this is fixed already.

Andres.


Rick Flower wrote: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc