james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefano Bagnara (JIRA)" <server-...@james.apache.org>
Subject [jira] Commented: (JAMES-850) RemoteDeliveryTest intermitant failure
Date Sat, 02 Aug 2008 16:03:44 GMT

    [ 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message