Gentlemen --

I'm very thankful for your input! Graham, especially thanks for the
example config. I'm going to try it out this morning, and will
certainly report back with results!


--Stuart

On Tue, Jun 15, 2010 at 5:15 AM, Graham Dumpleton
<[email protected]> wrote:
>
>
> On Jun 15, 10:28 am, lifewithryan <[email protected]> wrote:
>> I always use separate virtualenv instances per project.  That being
>> said, if psycopg2 Indeed has some sort of bug that makes the sharing
>> of environments not work so well (I doubt it)
>
> I wouldn't doubt it at all. The pyscopg2 module for a long time had
> problems with being able to be used in multiple sub interpreters of
> the same process. They eventually fixed this. There could well though
> be other issues, or they have introduced a completely new issue.
>
> The safest thing to do is to use multiple mod_wsgi daemon process
> groups and delegate every WSGI application to a separate daemon
> process group. Also, ensure that WSGI application runs in the main
> interpreter of the process and not a sub interpreter as psycopg may
> well for some things not work properly in sub interpreters, as various
> C extensions are prone to do because they never consider that they
> might be used in sub interpreters.
>
> Thus use something like:
>
>  WSGIDaemonProcess group1
>  WSGIDaemonPprcess group2
>
>  WSGIScriptAlias /app1 /some/path/app1.wsgi process-group=group1
> application-group=%{GLOBAL}
>  WSGIScriptAlias /app2 /some/path/app2.wsgi process-group=group2
> application-group=%{GLOBAL}
>
> Above example configuration expects you are using mod_wsgi 3.X.
>
> Also ensure you are using recent psycopg2 and not some outdated
> version that your specific Linux distribution is packaging up.
>
> Graham
>
>> then try separate
>> virtualenv instances.  However, I'd be willing to bet just using
>> different wsgi process groups/instances would be fine.
>>
>> While I haven't had to run multiple satchmo instances, I have had to
>> run multiple django projects side by side but have always used
>> separate wsgi process groups in my apache config for each virtual
>> host.  (I've also always used separate virtualenv instances for each
>> as well even when they share dependencies since my requirments could
>> change or force an upgrade of any one package at any time.)
>>
>> Sent from my iPod
>>
>> On Jun 14, 2010, at 6:50 PM, Chris Moffitt <[email protected]> wrote:
>>
>>
>>
>> > To be perfectly honest I'm not that familiar with the details of
>> > setting up Apache and multiple hosts.
>>
>> > I was speaking to someone about this very same issue and this is
>> > what they said -
>>
>> > " made each apache VHOST that is running satchmo as as WSGI daemon
>> > process with unique process group and problem went away."
>>
>> > So, I think you're on the right track but can't give you anymore
>> > specific details since that's not my area of expertise.
>>
>> > -Chris
>>
>> > On Mon, Jun 14, 2010 at 5:56 PM, Stuart <[email protected]> wrote:
>> > Well, I still don't have this problem resolved, but I suppose I'm
>> > getting closer all the time.
>>
>> > Today I found an old thread that may very well describe the identical
>> > problem I'm having.
>>
>> >  http://groups.google.com/group/satchmo-users/msg/e78f589100e722f8
>>
>> > Corey Oordt's reply indicates that what I'm up against might be a bug
>> > in psycopg2 that manifests when running multiple django sites on the
>> > same server against the same instance of psycopg2. Corey suggests that
>> > he got around the problem by running mod_wsgi in daemon mode (rather
>> > than default embedded mode, I gather) and using virtualenv. I've been
>> > using virtualenv from the start, but I have both satchmo sites running
>> > out of the same virtualenv. I wonder if what he's describing implies
>> > that each site should have its own virtualenv..? Corey, if you're out
>> > there, I'd be extremely grateful for any additional information.
>>
>> > Also, I'm having a difficult time figuring out how to get mod_wsgi
>> > into daemon mode. It seems that all I really need to do is add
>> > WSGIDaemonProcess and WSGIProcessGroup settings to my httpd.conf, but
>> > I've done that and it doesn't appear to change anything. Need to read
>> > more docs, I reckon.
>>
>> > I have to say, figuring out this error has been the low point of my
>> > django career thus far, and incredibly boring (my love for django is
>> > pretty much untarnished, though). I think I need a django mentor to
>> > teach me things like how track down what's going wrong in situations
>> > like this. The interactions between apache, wsgi, django, psycopg2,
>> > etc are fuzzy to me. Bruce, is this why you run lighttpd+fastcgi?? If
>> > switching would make this problem go away, I'm game and getting gamer
>> > all the time. ;)
>>
>> > --Stuart
>>
>> > On Jun 14, 11:10 am, Stuart Laughlin <[email protected]> wrote:
>> > > Chris, thanks for the response. Good idea about watching the
>> > postgres
>> > > logs; I'm going to look at that right now.
>>
>> > > Caching sounds like a likely culprit to me, too. Do you have any
>> > ideas
>> > > for how I could prove/disprove that? Can I turn off caching
>> > entirely?
>> > > Presently I'm using memcached, in conjunction with the UpdateCache
>> > and
>> > > FetchFromCache middleware.
>>
>> > > Another data point: the thing that seems to distinguish my satchmo
>> > > implementation from 'normal' ones is that I have two sites (two
>> > django
>> > > projects) on my apache server. They are both operating out of the
>> > same
>> > > virtualenv against a single installation of satchmo. I bring it up
>> > > because the 'random' nature of the error feels kind of like a
>> > > threading issue.
>>
>> > > --Stuart
>>
>> > > On Sat, Jun 12, 2010 at 12:11 PM, Chris Moffitt
>> > <[email protected]> wrote:
>> > > > Do you see anything in your postgres logs? Sounds like some sort
>> > of caching
>> > > > issue but I'm guessing.
>>
>> > > > -Chris
>>
>> > > > On Thu, Jun 10, 2010 at 12:29 PM, Stuart Laughlin
>> > <[email protected]>
>> > > > wrote:
>>
>> > > >> I fear I type too much. Let me try this a different way.
>>
>> > > >> I have a template tag (discount_price) that intermittently
>> > breaks --
>> > > >> throws a ProgrammingError with "Error in formatting: couldn't
>> > adapt"
>> > > >> message (debian stable, apache2, mod-wsgi, satchmo 0.9.1.
>> > stable). I
>> > > >> don't know what causes it to happen. Restarting the server
>> > makes the
>> > > >> problem go away. While the problem is happening, I can fire up
>> > the
>> > > >> django shell and invoke the template tag with no problems. It
>> > seems it
>> > > >> must have something to do with the apache process's connection
>> > to the
>> > > >> postgresql database.
>>
>> > > >> Has anyone seen anything like this before?
>>
>> > > >> --Stuart
>>
>> > > >> On Wed, Jun 9, 2010 at 11:31 PM, Stuart Laughlin
>> > <[email protected]>
>> > > >> wrote:
>> > > >> > Hello Everyone --
>>
>> > > >> > I have a recurring intermittent problem that I've been
>> > battling off
>> > > >> > and on for the past few months. The error initially manifests
>> > itself
>> > > >> > as a ProgrammingError in the product template on the bit that
>> > says "{{
>> > > >> > product|discount_price:sale|currency }}". I've been dealing
>> > with it up
>> > > >> > till now by commenting it out, avoiding using the
>> > discount_price
>> > > >> > template tag, etc. Finally I resolved to get to the bottom of
>> > it and
>> > > >> > added some logging to the get_product view. Well, the only
>> > effect that
>> > > >> > had was to move the origin of the error from the template to my
>> > > >> > logging statement in the view (but at least it seems like I
>> > get a
>> > > >> > better stack trace when the error happens in the view!).
>>
>> > > >> > At any rate, I'm looking at my stack trace, and I think I
>> > understand
>> > > >> > what's happening. My logging statement in the get_product()
>> > view
>> > > >> > throws an error when I invoke the discount_price template-tag
>> > method:
>>
>> > > >> >   log.debug("product|discount_price:sale is %s" %
>> > > >> > discount_price(product, best_discount))
>>
>> > > >> > The error appears to actually occur in product/prices.py on
>> > line 14
>> > > >> > here:
>>
>> > > >> >   8.  qty_discounts = product.price_set.exclude(
>> > > >> >   9. expires__isnull=False,
>> > > >> >  10. expires__lt=datetime.date.today()).filter
>> > (quantity__lte=qty)
>> > > >> >  11.
>> > > >> >  12. adjustments = None
>> > > >> >  13.
>> > > >> >  14. if qty_discounts.count() > 0:
>> > > >> >  15. # Get the price with the quantity closest to the one
>> > specified
>> > > >> > without going over
>> > > >> >  16. adjustments = qty_discounts.order_by('price','-quantity',
>> > > >> > 'expires')[0].adjustments(product)
>>
>> > > >> > Line 14 executes the query defined in lines 8-10, and
>> > qty_discounts
>> > > >> > ends up being set to "Error in formatting: can't adapt".
>>
>> > > >> > At the moment I'm getting this error every time I navigate to a
>> > > >> > product (which obviously invokes my get_product view). I
>> > suspect that
>> > > >> > when I restart apache, the error will go away.
>>
>> > > >> > But here's the really odd thing: I can use "manage.py" to
>> > fire up the
>> > > >> > shell and run the discount_price template tag with no
>> > problems, even
>> > > >> > though I'm running it exactly like I am in the logging
>> > statement. So I
>> > > >> > find this very puzzling. Has anyone seen anything like this?
>> > I'm
>> > > >> > really hoping someone can point me in the right direction.
>>
>> > > >> > Oh, and I'm on version 0.9.1 final.
>>
>> > > >> > Full traceback follows my signature.
>>
>> > > >> > Thanks very much!
>>
>> > > >> > --Stuart
>>
>> > > >> > Environment:
>>
>> > > >> > Request Method: GET
>> > > >> > Request URL:
>> > > >> >http://10.10.20.20/vw/product/basic-black-center-console-304734/
>> > > >> > Django Version: 1.1.1
>> > > >> > Python Version: 2.5.2
>> > > >> > Installed Applications:
>> > > >> > ['django.contrib.sites',
>> > > >> >  'satchmo_store.shop',
>> > > >> >  'django.contrib.admin',
>> > > >> >  'django.contrib.auth',
>> > > >> >  'django.contrib.admindocs',
>> > > >> >  'django.contrib.contenttypes',
>> > > >> >  'django.contrib.comments',
>> > > >> >  'django.contrib.sessions',
>> > > >> >  'django.contrib.sitemaps',
>> > > >> >  'registration',
>> > > >> >  'keyedcache',
>> > > >> >  'livesettings',
>> > > >> >  'l10n',
>> > > >> >  'sorl.thumbnail',
>> > > >> >  'satchmo_store.contact',
>> > > >> >  'tax',
>> > > >> >  'tax.modules.no',
>> > > >> >  'tax.modules.area',
>> > > >> >  'tax.modules.percent',
>> > > >> >  'shipping',
>> > > >> >  'product',
>> > > >> >  'product.modules.configurable',
>> > > >> >  'payment',
>> > > >> >  'payment.modules.dummy',
>> > > >> >  'payment.modules.giftcertificate',
>> > > >> >  'satchmo_utils',
>> > > >> >  'app_plugins',
>> > > >> >  'satchmo_ext.productratings',
>> > > >> >  'satchmo_ext.recentlist',
>> > > >> >  'satchmo_ext.upsell',
>> > > >> >  'satchmo_ext.wishlist',
>> > > >> >  'satchel',
>> > > >> >  'south',
>> > > >> >  'ecomm',
>> > > >> >  'filer',
>> > > >> >  'tinymce',
>> > > >> >  'debug_toolbar']
>> > > >> > Installed Middleware:
>> > > >> > ('django.middleware.cache.UpdateCacheMiddleware',
>> > > >> >  'django.middleware.common.CommonMiddleware',
>> > > >> >  'django.contrib.sessions.middleware.SessionMiddleware',
>> > > >> >  'django.middleware.locale.LocaleMiddleware',
>> > > >> >  'django.contrib.auth.middleware.AuthenticationMiddleware',
>> > > >> >  'django.middleware.doc.XViewMiddleware',
>> > > >> >  'threaded_multihost.middleware.ThreadLocalMiddleware',
>> > > >> >  'satchmo_store.shop.SSLMiddleware.SSLRedirect',
>> > > >> >  'debug_toolbar.middleware.DebugToolbarMiddleware',
>> > > >> >  'passion.middleware.FilterPersistMiddleware',
>> > > >> >  'django.middleware.cache.FetchFromCacheMiddleware')
>>
>> > > >> > Traceback:
>> > > >> > File
>>
>> ...
>>
>> read more »
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Satchmo users" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/satchmo-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Satchmo users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/satchmo-users?hl=en.

Reply via email to