[
https://issues.apache.org/jira/browse/JAMES-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619243#action_12619243
]
Stefano Bagnara commented on JAMES-850:
---------------------------------------
This is interesting!
First I noticed there are too many delivery threads: I forgot to destroy the
RemoteDelivery after each test and they was not stopped/disallocated. I
committed a fix for this, but I don't think this was the issue.
Rather I see a weird stack for a delivery thread:
Thread Thread[Remote delivery thread (0),5,main]
STE: sun.reflect.ClassFileAssembler.emitShort(ClassFileAssembler.java:45)
STE:
sun.reflect.ClassFileAssembler.emitConstantPoolClass(ClassFileAssembler.java:96)
STE:
sun.reflect.AccessorGenerator.emitBoxingContantPoolEntries(AccessorGenerator.java:310)
STE:
sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:337)
STE:
sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(MethodAccessorGenerator.java:95)
STE:
sun.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFactory.java:313)
STE:
java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.java:1299)
STE: java.io.ObjectStreamClass.access$1500(ObjectStreamClass.java:52)
STE: java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:420)
STE: java.security.AccessController.doPrivileged(Native Method)
STE: java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:400)
STE: java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:297)
STE: java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1035)
STE: java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
STE: java.util.HashMap.writeObject(HashMap.java:1038)
STE: sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
STE:
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
STE: java.lang.reflect.Method.invoke(Method.java:585)
STE: java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:917)
STE: java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1339)
STE:
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
STE: java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
STE: java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
STE: org.apache.james.core.MailImpl.cloneSerializableObject(MailImpl.java:614)
STE: org.apache.james.core.MailImpl.<init>(MailImpl.java:162)
STE:
org.apache.james.test.mock.james.InMemorySpoolRepository.store(InMemorySpoolRepository.java:150)
STE:
org.apache.james.transport.remotedeliverytester.TesterMailetConfig$SpoolRepositoryWrapper.store(TesterMailetConfig.java:181)
STE:
org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:1264)
STE: java.lang.Thread.run(Thread.java:595)
This could be the one we are investigating, because the
RemoteDelivery.java:1264 is the place where a message has been delayed
(temporary failure) and it is stored to the spool to be further processed, but
it seems to be stuck during a clone operation.
The weird thing is that under a similar circumstance we would have at least 1
mail in the spool and the assertEquals(0, waitEmptySpool(xxxx)) should fail,
instead it fails later on the assertWhole.
I'm confused, ATM...
> RemoteDeliveryTest intermitant failure
> --------------------------------------
>
> Key: JAMES-850
> URL: https://issues.apache.org/jira/browse/JAMES-850
> Project: James
> Issue Type: Test
> Affects Versions: Trunk
> Environment: GNULinux/Gentoo
> % java -version
> java version "1.5.0_16"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_16-b02, mixed mode)
> % cat /proc/cpuinfo
> processor : 0
> vendor_id : AuthenticAMD
> cpu family : 15
> model : 67
> model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
> stepping : 3
> cpu MHz : 1000.000
> cache size : 1024 KB
> physical id : 0
> siblings : 2
> core id : 0
> cpu cores : 2
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm
> 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
> bogomips : 2012.31
> TLB size : 1024 4K pages
> clflush size : 64
> cache_alignment : 64
> address sizes : 40 bits physical, 48 bits virtual
> power management: ts fid vid ttp tm stc
> processor : 1
> vendor_id : AuthenticAMD
> cpu family : 15
> model : 67
> model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
> stepping : 3
> cpu MHz : 1000.000
> cache size : 1024 KB
> physical id : 0
> siblings : 2
> core id : 1
> cpu cores : 2
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm
> 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
> bogomips : 2012.31
> TLB size : 1024 4K pages
> clflush size : 64
> cache_alignment : 64
> address sizes : 40 bits physical, 48 bits virtual
> power management: ts fid vid ttp tm stc
> Reporter: Robert Burrell Donkin
> Priority: Critical
> Attachments:
> TEST-org.apache.james.transport.mailets.RemoteDeliveryTest.txt,
> TEST-org.apache.james.transport.mailets.RemoteDeliveryTest.txt
>
>
> Open to track information related to intermittent failures of this test
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
