MoonPoint Support Logo


Shop Amazon Warehouse Deals - Deep Discounts on Open-box and Used ProductsAmazon Warehouse Deals

Advanced Search
Sun Mon Tue Wed Thu Fri Sat

Mon, Apr 28, 2008 9:08 pm

Configuring Microsoft Exchange to Use a Smart Host

If a Microsoft Exchange server doesn't have a PTR record, other email servers may reject email from the Exchange server when they are unable to perform a reverse lookup on the IP address for the Exchange server. A workaround for this problem is to use a "smart host" to route outgoing email from the Exchange server.

[ More Info ]

[/network/email/exchange] permanent link

Sun, Apr 27, 2008 8:30 pm

Store.Exe Consuming Excessive Memory

On a Microsoft Exchange 2003 server, I've found Task Manager reporting high memory utilization. When I sort the running processes by memory utilization in the Task Manager (click on the Performance tab then click on the Processes column header to sort them), I see store.exe consuming over 500 MB. This is happening at the moment on a Sunday evening when few of the systems in the domain even have Outlook open to check email. The CPU utilization is low, less than 10% at the moment when I am seeing the 500 MB memory usage.

I've been seeing memory utilization jumping up to high values a lot lately. Rebooting the system resolves the problem, but I don't want to be rebooting the Exchange server every day. I can also reduce the memory utilization by selecting Run and typing services.msc to bring up the services list, I can then right-click on Microsoft Exchange Information Store and stop the service and then restart it. I then see store.exe using about 20 MB of memory when I check its utilization with the Windows Task Manager

The Microsoft Exchange Information Store service manages the Microsoft Exchange Information Store, which includes mailbox stores and public folder stores. If the service is stopped, mailbox stores and public folder stores on the computer become unavailable, so it needs to be restarted immediately after stopping it.


  1. Store.exe High Memory Utilization
    August 10, 2005
    Tech Support, Manuals & Troubleshooting for Consumers
  2. Memory leak in Store.exe - pub1.edb GIGANTIC
    Server Watch Forums

[/network/email/exchange] permanent link

Sat, Apr 26, 2008 10:18 pm

Blosxom Calendar Plugin on 64-bit System

I found that the Calendar plugin for Blosxom stopped working when I moved my blog from a 32-bit Redhat Linux system to a 64-bit CentOS Linux system. Nothing would appear within the blog. When I checked the error log for the website, I saw the following:
[Sat Apr 26 21:53:00 2008] [error] [client] calendar debug 1:
start() called, enabled
[Sat Apr 26 21:53:00 2008] [error] [client] calendar debug 1:
filter() called
[Sat Apr 26 21:53:00 2008] [error] [client] Byte order is not
compatible at ../../lib/ (autosplit into
../../lib/auto/Storable/ line 331, <DATA> line 32, at
/home/jsmith/www/blosxom/plugins/calendar line 322
[Sat Apr 26 21:53:00 2008] [error] [client] Premature end of
script headers: blosxom

At [ic] HELP !FreeBSD 5.3 Box With newest version of perl storable problem , I saw the following:

You appear to have a perl configured to use 64 bit integers in its scalar
variables.  If you have existing data written with an earlier version of
Storable which this version of Storable refuses to load with a

   Byte order is not compatible

error, then please read the section "64 bit data in perl 5.6.0 and 5.6.1"
in the Storable documentation for instructions on how to read your data.

(You can find the documentation at the end of in POD format)

That revealed that the problem was linked to the fact that I am now using a 64-bit operating system.

I decided to see if an upgrade Storable module was available.

# cpan upgrade Storable

/usr/lib/perl5/5.8.8/CPAN/ initialized.

CPAN is the world-wide archive of perl resources. It consists of about
100 sites that all replicate the same contents all around the globe.
Many countries have at least one CPAN site already. The resources
found on CPAN are easily accessible with the module. If you
want to use, you have to configure it properly.

If you do not want to enter a dialog now, you can answer 'no' to this
question and I'll try to autoconfigure. (Note: you can revisit this
dialog anytime later by typing 'o conf init' at the cpan prompt.)

Are you ready for manual configuration? [yes]

I entered "no" to the prompt regarding whether I was ready for manual configuration, which resulted in the autoconfigure process proceeding.

I then checked Storable again.

# cpan Storable
CPAN: Storable loaded ok
Going to read /root/.cpan/Metadata
  Database was generated on Sat, 26 Apr 2008 17:29:46 GMT
Storable is up to date.

I checked the version of the module with perlmodver. The version was 2.18.

But the problem still remained. Taking a look at the code in the calendar plugin, I realized it was reading a file, .calendar.cache in the plugins/state directory. I had not noticed the file previously, because I had checked the directory's contents only with ls. I saw it with ls -a. The calendar plugin reads the contents of that file. I had copied the file from the old 32-bit system to the new 64-bit system when I copied the plugins directory and its subdirectores. When I deleted the .calendar.cache file from the state directory and then tried accessing the blog again, the calendar plugin recreated it, but this time it was in the proper 64-bit format that the module was expecting, so I was now able to view the blog with the calendar functionality now working.

Further information on the issue can be found near the end of the file (look in /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/

Perl 5.6.x introduced the ability to optional configure the perl interpreter to use C's C<long long> type to allow scalars to store 64 bit integers on 32 bit systems. However, due to the way the Perl configuration system generated the C configuration files on non-Windows platforms, and the way Storable generates its header, nothing in the Storable file header reflected whether the perl writing was using 32 or 64 bit integers, despite the fact that Storable was storing some data differently in the file. Hence Storable running on perl with 64 bit integers will read the header from a file written by a 32 bit perl, not realise that the data is actually in a subtly incompatible format, and then go horribly wrong (possibly crashing) if it encountered a stored integer. This is a design failure.

Storable has now been changed to write out and read in a file header with information about the size of integers. It's impossible to detect whether an old file being read in was written with 32 or 64 bit integers (they have the same header) so it's impossible to automatically switch to a correct backwards compatibility mode. Hence this Storable defaults to the new, correct behaviour.

What this means is that if you have data written by Storable 1.x running on perl 5.6.0 or 5.6.1 configured with 64 bit integers on Unix or Linux then by default this Storable will refuse to read it, giving the error I<Byte order is not compatible>. If you have such data then you you should set C<$Storable::interwork_56_64bit> to a true value to make this Storable read and write files with the old header. You should also migrate your data, or any older perl you are communicating with, to this current version of Storable.

If you don't have data written with specific configuration of perl described above, then you do not and should not do anything. Don't set the flag - not only will Storable on an identically configured perl refuse to load them, but Storable a differently configured perl will load them believing them to be correct for it, and then may well fail or crash part way through reading them.

[/network/web/blogging/blosxom] permanent link

Valid HTML 4.01 Transitional

Privacy Policy   Contact

Blosxom logo