Zitat von Martijn Brinkers <[email protected]>:

On 12/05/2012 04:35 PM, [email protected] wrote:

Zitat von Martijn Brinkers <[email protected]>:

On 12/05/2012 04:07 PM, [email protected] wrote:
Are you running the gateway virtualized or on real hardware?

This is real Hardware and no memory shortage either. Djigzo was working
as expected at the time it was killed. Today where it was noticed i was
even working in the admin console, so it should be no stall of Djigzo
but more of a false restart trigger.

Strange. I have never seen this problem on my own servers (well at least
not that I know, since it automatically restarts :)

I have checked the Java Wrapper releases notes at:

http://wrapper.tanukisoftware.com/doc/english/release-notes.html

Although 3.4.1 is already old, I did not immediately see a bug fix which
might explain what happens. This looks the closest:

Version 3.5.9:
Fix a problem where the Wrapper was not correctly yielding control back
to its main loop when very large amounts of continuous output was being
logged from the JVM. Introduced in 3.4.0. In versions prior to 3.5.8,
this could have caused the JVM to timeout and restart itself. That
particular issue was resolved but the Wrapper process in 3.5.8 would
still have been unresponsive when this was happening. The Wrapper will
now always yeild back to its main loop after 250 milliseconds of
continuous logging.

You might try to use a newer Java wrapper release to see whether this
fixes the problem. The Java wrapper files are stored in:

/usr/share/djigzo/wrapper

The wrapper tar is extracted to a sub dir and then the following
symlinks link to the required files inside the version specific sub dir:

libwrapper.so --links-to--> wrapper-linux-xx/lib/libwrapper.so
wrapper-djigzo --links-to--> wrapper-linux-xx/bin/wrapper
wrapper.jar --links-to--> wrapper-linux-xx/lib/wrapper.jar

If you want to test with a newer release of Java wrapper, untar the file
and overwrite the symlinks and then restart djigzo.


What kind of wrapper do i need? The Professional, Standard or Community
edition?

The Community edition.

Kind regards,

Martijn

Hm, not the root case. Restarted again with wrapper 3.5.15. Below is the content of /proc/meminfo

MemTotal:        6062812 kB
MemFree:           45060 kB
Buffers:           98080 kB
Cached:          2820224 kB
SwapCached:          448 kB
Active:          3190632 kB
Inactive:        2362944 kB
Active(anon):    2029628 kB
Inactive(anon):   644244 kB
Active(file):    1161004 kB
Inactive(file):  1718700 kB
Unevictable:           4 kB
Mlocked:               0 kB
SwapTotal:       7812088 kB
SwapFree:        7810748 kB
Dirty:              1724 kB
Writeback:             0 kB
AnonPages:       2634840 kB
Mapped:            91544 kB
Shmem:             38588 kB
Slab:             299204 kB
SReclaimable:     263184 kB
SUnreclaim:        36020 kB
KernelStack:        3488 kB
PageTables:        20688 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    10843492 kB
Committed_AS:    3364384 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       33052 kB
VmallocChunk:   34356571308 kB
HardwareCorrupted:     0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       10176 kB
DirectMap2M:     6215680 kB


This is Ubuntu 10.04 LTS x64 with ECC-RAM and no system errors as far as i can tell. Any further idea?
Is the timeout adjustable?

Regards

Andreas


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Users mailing list
[email protected]
http://lists.djigzo.com/lists/listinfo/users

Reply via email to