OpenEMM Technical Support Forum

We are running OpenEMM 5.5.1. We're sending 100s of thousands of emails a day. But it appears that sometimes when a user generates particularly large content, say a megabyte of html with lots of replacement variables, the xmlback process can take a long time to unpack a block of emails, and this can...

Maybe I'm missing something here. I do have the source tar from: http://sourceforge.net/projects/openemm/files/OpenEMM%20software/OpenEMM%205.5.1/OpenEMM-5.5.1-src.tar.gz/download This does include a build.xml, but not an openemm_build.xml. And that file only references a subset of the libraries tha...

We have started to experience an obscure resin bug that was apparently fixed in version 3.0.14 http://bugs.caucho.com/view.php?id=419 So we would like to update the resin bundled with our OpenEMM 5.5.1 installation to the latest 3.0.27, and I just want to be sure of the process. If I delete all the ...

I don't know if it's been fixed in the official release, but I just removed the 'usedConnections' Hashtable and related code from the WebServiceBase, and it's been working fine ever since. We're still using version 5.5.1.

Thanks -- that will help us manage the disk space on that server. Do we need to stop sendmail or anything to safely remove them?

The var/spool/filter directory of our installation is currently taking up 20GB of disk space. Is it safe to purge these files, or is there a way to configure the system to purge them?

This seems to be related to Bounce Management, which is why I'm asking in this forum.

Thanks!

Thanks for the replies. I'll let you know if I have anything of interest to report back. We'll probably start by converting the same tables as Beck.

Beck, ma, anyone: Is there any reason not to switch all the tables over to InnoDB? One reason I ask is that we have some cleanup jobs to delete old data from the system, and these are causing some contention. Since we keep running into performance issues with table locking, I'm wondering if we're no...

Thanks! It's funny that you should respond when you did -- we had just this week decided to build that same index. We haven't changed the table engine yet, just added the index. The open connections immediately dropped from 130 to 13 and have stayed low. And whereas the mysql process was the top pro...

Has anyone tried replacing the table engine for this or other tables? We've had to bump up the application connection pool and max_connections for MySQL because of all the table locking on this onepixel table. We're seeing more than 100 connections waiting on this table. I was also thinking of just ...

I understand that the commercial version of the software uses Oracle for the database, and I see the various hooks in the code for this. Is anyone using the open version with Oracle and could say what they had to do to make the changeover? Is it as easy as creating the schema and updating the db con...

Well, if it really is *exponential*, then there's something wrong with the code. :) I can see where you might want to have limits like this for your hosted version of the product, but for those of us running our own systems, it doesn't really make sense to me to impose an artificial cap. My bigger c...

It seems to me that what happened was the 5k baseline was filled up with bouncing emails, preventing new emails from getting put into the queue at a high enough frequency to achieve the needed throughput. Once we upped that limit for the queue, there was space for new emails to be put on the queue, ...

We're using the webservices API and scheduling our Mailings for 'now', but I guess since this counts as 'scheduling' rather than 'immediate sending', they're always delayed by up to 15 minutes. This is only really a problem for the previews, where our users want to receive an email themselves to con...

Our solution was to edit the pickdist.py file at the following function: def queueIsFree (self): return len ([_f for _f in os.listdir (self.queue) if _f[:2] == 'qf']) < 5000 We replaced that 5000 with a 20000, to allow OpenEMM to place more emails into the Sendmail queue. We are now sending about 30...