axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Husted (JIRA)" <>
Subject [jira] Updated: (AXIS-2084) Dime attachements: Type_Length of the final record chunk must be zero
Date Thu, 21 Jul 2005 21:23:50 GMT
     [ ]

Brian Husted updated AXIS-2084:

    Attachment: DimeBodyPartDiff_2.txt


I ran into this problem as well.  I have attached a patch that resolves this problem.  Before
the recently commited patch all of the header fields were being sent on every record, to include
the TYPE_T which per the DIME spec is not correct.  The problem you are currently facing is
related to the TYPE_T, TYPE_LENGTH, and TYPE not being sent on the MB DIME record (the first

The attached patch has enabled our .NET partners to pull attachments from our Axis server
at sizes ranging from 5 - 100MB (using 10MB chunks).  Sizes greater than 100MB are most likely
possible we just haven't tested.   However, we still have the same problem when trying to
submit attachments from the Axis client to the Axis Server.  Therefore, I was waiting to release
this patch until I could resolve the prior issue that I posted.   Given Tom's note, I have
went ahead an included the new patch DimeBodyPartDiff_2.txt (diff from cvs).  In addition,
I am still working to correct the Axis client to Server issue; so expect another patch in
the next two weeks.


> Dime attachements: Type_Length of the final record chunk must be zero
> ---------------------------------------------------------------------
>          Key: AXIS-2084
>          URL:
>      Project: Apache Axis
>         Type: Bug
>   Components: Serialization/Deserialization
>     Versions: 1.2, 1.2.1
>  Environment: Microsoft XP
>     Reporter: Coralia Silvana Popa
>     Assignee: Davanum Srinivas
>  Attachments:, DimeBodyPartDiff.txt, DimeBodyPartDiff_2.txt,,
> Large files sent as DIME attachments are not correct serialized. Seems that the 
> When reading a series of chunked records, the parser assumes that the first record without
the CF flag is the final record in the chunk; in this case, it's the last record in my sample.
The record type is specified only in the first record chunk, and all remaining chunks must
have the TYPE_T field and all remaining header fields (except for the DATA_LENGTH field) set
to zero.
> Seems that Type_Length (and maybe other header fields) is not set to 0 for the last chunk.
The code work correct when there is only one chunck.
> The problem is in class: org.apache.axis.attachments.DimeBodyPart, in method void send(
os, byte position, DynamicContentDataHandler dh, final long maxchunk)
> I suggest the following code the fix this problem:
> void send( os, byte position, DynamicContentDataHandler dh,
>             final long maxchunk)
>             throws {
>     		BufferedInputStream in = new BufferedInputStream(dh.getInputStream());
>     		final int myChunkSize = dh.getChunkSize();
>     		byte[] buffer1 = new byte[myChunkSize]; 
>     		byte[] buffer2 = new byte[myChunkSize]; 
>     		int bytesRead1 = 0 , bytesRead2 = 0;
>     		bytesRead1 =;
>     		if(bytesRead1 < 0) {
>                 sendHeader(os, position, 0, (byte) 0);
>                 os.write(pad, 0, dimePadding(0));
>                 return;
>     		}
> 		byte chunknext = 0;
>     		do {
>     			bytesRead2 =;
>     			if(bytesRead2 < 0) {
>     				//last not set the chunk bit.
>     				//buffer1 contains the last chunked record!
>     				sendChunk(os, position, buffer1, 0, bytesRead1, chunknext);
>     				break;
>     			}
>     			sendChunk(os, position, buffer1, 0, bytesRead1,(byte) (CHUNK | chunknext) );
> 			chunknext = CHUNK_NEXT;
>     			//now that we have written out buffer1, copy buffer2 into to buffer1
>     			System.arraycopy(buffer2,0,buffer1,0,myChunkSize);
>     			bytesRead1 = bytesRead2;
>     		}while(bytesRead2 > 0);
>     }

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message