pitter patter on the keyboard

Chances are you just changed the port settings in framework/base/config/ofbiz-containers.xml but forgot to update framework/service/config/serviceengine.xml.

Open serviceengine.xml and replace all four instances of “8080″ with the non-secure port you specified in ofbiz-containers.xml.

I just encountered this while making a tar backup on one of my virtual filesystems:

lost page write due to I/O error on xvdb1
end_request: I/O error, dev xvdb1, sector 33707688
Buffer I/O error on device xvdb1, logical block 4213461

Unfortunately, my fs suffered corruption.

Some folks, particularly Ubuntu users with kernel 3.2.x seem to say the answer is adding

barrier=0

to your ext3/ext4 mount options.

In my case I’m pretty sure an OOM error killed something critical to the backend on dom0.

Be sure to check your dom0′s dmesg.

UPDATE Uhh yeah, something actually managed to overflow the dom0′s fs. >.> This is what I was getting in the dom0 dmesg:

loop: Write error at byte offset 17820364800, length 4096.

for which there is very little discussion, but a quick df told me what was going on.

Breathe easy. Smile. You’re probably here because you’ve just run ab and got output something like:

This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking **** (be patient)
Completed 100000 requests
Completed 200000 requests
Completed 300000 requests
Completed 400000 requests
Completed 500000 requests
Completed 600000 requests
Completed 700000 requests
Completed 800000 requests
Completed 900000 requests
Finished 1000000 requests


Server Software:        nginx/1.2.1
Server Hostname:        ****
Server Port:            80

Document Path:          ****
Document Length:        162 bytes

Concurrency Level:      5
Time taken for tests:   9502.884921 seconds
Complete requests:      1000000
Failed requests:        697730
   (Connect: 0, Length: 697730, Exceptions: 0)
Write errors:           0
Total transferred:      279019852 bytes
Total POSTed:           247000494
HTML transferred:       158019731 bytes
Requests per second:    105.23 [#/sec] (mean)
Time per request:       47.514 [ms] (mean)
Time per request:       9.503 [ms] (mean, across all concurrent requests)
Transfer rate:          28.67 [Kbytes/sec] received
                        25.38 kb/s sent
                        54.06 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   15  26.7     13    3183
Processing:     0   31  18.8     29    2319
Waiting:        0   30  15.9     28    1719
Total:          0   46  38.9     42    4333

Percentage of the requests served within a certain time (ms)
  50%     42
  66%     45
  75%     46
  80%     47
  90%     51
  95%     55
  98%    104
  99%    201
 100%   4333 (longest request)

697730 out of 1 million requests failed? No, not really.

ApacheBench expects to be run against something that produces consistent output. Chances are you’ve specified a script that has dynamic output and the length of that output has changed since the first pull.

Let’s have a nice cup of tea :)