[
https://issues.apache.org/jira/browse/JAMES-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619279#action_12619279
]
Stefano Bagnara commented on JAMES-850:
---------------------------------------
I noticed an issue in testMulti in Hudson too, it was on @d.it domains, so
maybe this time is an issue in the test. I'll monitor more failure to get a
better idea while we investigate on the test5 issue.
Interestingly I run it now on my machine and I reproduced a test5 failure, the
logging was:
-------------
Thread Thread[Remote delivery thread (0),5,main]
- java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
- java.lang.StringBuilder.append(StringBuilder.java:119)
- java.lang.Class.getDeclaredMethod(Class.java:1937)
- java.io.ObjectStreamClass.getInheritableMethod(ObjectStreamClass.java:1349)
- java.io.ObjectStreamClass.access$2200(ObjectStreamClass.java:52)
- java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:450)
- java.security.AccessController.doPrivileged(Native Method)
- java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413)
- java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
- java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1106)
- java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
- java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
- java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
- java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
- java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
- java.util.HashMap.writeObject(HashMap.java:1001)
- sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
-
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
- java.lang.reflect.Method.invoke(Method.java:597)
- java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
- java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)
- java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
- java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
- java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
- org.apache.james.core.MailImpl.cloneSerializableObject(MailImpl.java:614)
- org.apache.james.core.MailImpl.<init>(MailImpl.java:162)
-
org.apache.james.test.mock.james.InMemorySpoolRepository.store(InMemorySpoolRepository.java:150)
-
org.apache.james.transport.remotedeliverytester.TesterMailetConfig$SpoolRepositoryWrapper.store(TesterMailetConfig.java:181)
-
org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:1264)
- java.lang.Thread.run(Thread.java:619)
--------------
So, again, the deliverer thread is stuck in that cloneSerializableObject (the
stack is not the same, but similar, maybe the difference are in JVM
version/platform).
In real world the spoolrepository implementations we use have a real write/read
to disk/jdbc and they probably don't use the "copy" constructor we use in
InMemorySpoolRepository, but this constructor is used in many places in James
code, so if we have an issue there we should better find it even if this won't
hit real world RemoteDelivery but it is more probable it will happen in the
LinearProcessor (spooler), and in the Redirect/Forward mailets tree.
> 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 -
> expected-continuation.txt,
> TEST-org.apache.james.transport.mailets.RemoteDeliveryTest.txt,
> 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]
