Return-Path: Delivered-To: apmail-axis-c-user-archive@www.apache.org Received: (qmail 44951 invoked from network); 5 Jul 2010 13:10:58 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 5 Jul 2010 13:10:58 -0000 Received: (qmail 52338 invoked by uid 500); 5 Jul 2010 13:10:58 -0000 Delivered-To: apmail-axis-c-user-archive@axis.apache.org Received: (qmail 52050 invoked by uid 500); 5 Jul 2010 13:10:55 -0000 Mailing-List: contact c-user-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache AXIS C User List" Delivered-To: mailing list c-user@axis.apache.org Received: (qmail 52042 invoked by uid 99); 5 Jul 2010 13:10:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Jul 2010 13:10:54 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of samisa@wso2.com designates 209.85.212.45 as permitted sender) Received: from [209.85.212.45] (HELO mail-vw0-f45.google.com) (209.85.212.45) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Jul 2010 13:10:47 +0000 Received: by vws18 with SMTP id 18so5718120vws.32 for ; Mon, 05 Jul 2010 06:09:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.54.69 with SMTP id p5mr1444854qag.195.1278335364468; Mon, 05 Jul 2010 06:09:24 -0700 (PDT) Received: by 10.224.36.194 with HTTP; Mon, 5 Jul 2010 06:09:24 -0700 (PDT) In-Reply-To: References: <4C11E606.906@gmail.com> <4C123A8B.5020808@gmail.com> <4C1B2C3E.6000308@gmail.com> Date: Mon, 5 Jul 2010 18:39:24 +0530 Message-ID: Subject: Re: AW: transfer limitations From: Samisa Abeysinghe To: Apache AXIS C User List Content-Type: multipart/alternative; boundary=0015175cdee24d90d7048aa3a56e X-Virus-Checked: Checked by ClamAV on apache.org --0015175cdee24d90d7048aa3a56e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If you want to handle large chunks of data, why not use MTOM? Also, there is a data source mode in Axis2/C to stream the chunk through. We use used Axis2/C to send mega bytes nearing giga range and it works for us for MTOM. For service case, I am not sure if it is a good idea to use AXIOM to build = a mega range doc - that means the service design is busted. Samisa... On Mon, Jul 5, 2010 at 6:20 PM, Stadelmann Josef < josef.stadelmann@axa-winterthur.ch> wrote: > Hope this helps you?`! > > > > Yes, how did I strike it out? I am using WSIT from HP to integrate legacy > systems. In short, big (huge) OMElement is arriving at the JAVA side, (co= uld > well contain Bas64 encoded data) it is then serialized to a very large > (huge) xml string; which is then pass to an out-of-process server via som= e > sort of WsiIpcContext (IPC Interprocess Communication Channel); JNI is > involved too. > > > > =85. > > > > When my large data arrives at the C-Legacy Server passed by WSIT ToolKit,= I > get a OpenVMS Descriptor which has a Length Field and a Pointer to the da= ta. > > > > > =85. > > > > And now comes what I did not understand so far but since I try to help yo= u, > I was able to fix my own problem today. > > So what I did not understand is as follow. > > > > My data arrives at WSI$$fktmap() in *pbIndata with a inLen of Bystes set = to > 91344 > > The code you see below is HP-WSIT-generated-code, and it works fine. > > > > The second green code line shows how this data is passed to my own routin= e > fktmap() which is declared as > > =91__int32 fktmap (char * p1, int inLen, dsc_d * p2);=92 > > > > Given that pbInData can be passed further on via a P1 of type char* then > please explain me the problem I am faced with. > > > > 1. In one case when I do > > Unsigned __int16 scnt =3D strlen(P1); > > I get scnt back as 25808 bytes > > BUT > > inLen shows me 91344 > > Why? > > > > 2. When I save P1 in a file, all bytes are there > BUT > When I pass it to > > xml_reader =3D axiom_xml_reader_create_for_memory(env, payload_inp, scnt, > encoding, AXIS2_XML_PARSER_TYPE_BUFFER); > > Then I get the following errors in my log file for one transaction, at > different call levels. > > > > [Mon Jul 5 14:10:28 2010] [error] > DKB3:[SW-PROJEKTE.webservices.axis2.trunk.c.axiom.src.parser]libxml2_read= er_wrapper.c;36(886) > > > expected '>' > > *************** > > -- SEVERITY_ERROR > > *************** > > [Mon Jul 5 14:10:28 2010] [error] > DKB3:[SW-PROJEKTE.webservices.axis2.trunk.c.axiom.src.parser]libxml2_read= er_wrapper.c;36(886) > > > Opening and ending tag mismatch: Fldnam line 0 and F > > *************** > > -- SEVERITY_ERROR > > *************** > > [Mon Jul 5 14:10:28 2010] [error] > DKB3:[SW-PROJEKTE.webservices.axis2.trunk.c.axiom.src.parser]libxml2_read= er_wrapper.c;36(886) > > > Extra content at the end of the document > > *************** > > -- SEVERITY_ERROR > > *************** > > [Mon Jul 5 14:10:28 2010] [error] > DKB3:[SW-PROJEKTE.webservices.axis2.trunk.c.axiom.src.parser]libxml2_read= er_wrapper.c;36(427) > > > error occured in reading xml stream > > [Mon Jul 5 14:10:28 2010] [debug] > DKB3:[SW-PROJEKTE.SPEZSRVW.axawl.spezpla.servers.SPgServer]SPg-legacy.c;1= 00(1593) > > *************** > > > > > > The source of the problem is now fixed; > > > > scnt receiving from strlen(P1) the byte count was of unsigned __int16, to= o > short to keep a value bigger then 65535!!!!! > > > > scnt must be of type unsigned __int32 and only then it is able to keep th= e > number 91344 ! > > > > One can take the calculator and enter 91344 as decimal number, then conve= rt > to hex and subtract 10000 Hex, then convert back to decimal. > > A too short type of an integer maskes out what strlen() returns correctly= . > > > > > > BUT when the proper length of bytes is passed to > axiom_xml_reader_create_for_memory() > > the routine works fine and does not bail out with a -- SEVERITY ERROR > > > > Conclusion of the day! If you work with very long strings (longer then FF= FF > =3D=3D=3D 65535) it is essential that you use > > =93unsigned __int32 OR unsigned __int64 as type for then =93scnt=94 =3D s= trlen(P1)=94 > with P1 pointing to a string longer than 65535 characters. > > > > > > Now back to you: How do you detect that your XML is broken? Which routine > informs you about that? > > > > Sepp > > > > > > /////////////////////////////////////////////////////////// > > // > > // function: WSI$$fktmap > > // > > // > > // > > /////////////////////////////////////////////////////////// > > static unsigned int WSI$$fktmap (unsigned int sessionID, > > *MSGB *pbInData,* > > *int inLen,* > > MSGB **ppbOutData, > > int *pOutLen) > > { > > #ifdef __DEBUG__ > > lib$signal(SS$_DEBUG); > > #endif > > char wsi$ret [4]; > > dsc_sd *wsi$p_dx; > > dsc_a *wsi$arydsc; > > int wsi$pnum =3D 2; > > int wsi$size =3D 0; > > encoder wsi$enc; > > dsc_sd wsi$ret_dx =3D {4, DSC$K_DTYPE_L, DSC$K_CLASS_S, wsi$ret, 0, = 0, > 0}; > > internal_context_t *wsi$context =3D (internal_context_t *) sessionID; > > > > wsi$p_dx =3D (dsc_sd *) pbInData; > > > > // All pointers are converted from relative to absolute addresses > here. > > wsi$p_dx[0].dsc$a_pointer +=3D (int) wsi$p_dx; > > wsi$p_dx[1].dsc$a_pointer +=3D (int) wsi$p_dx; > > > > // Special parameters, such as Floats & Dynamic Strings, are fixup > here. > > wsi$dstr_fix( &wsi$p_dx[1] ); > > > > // Structure parameters are fixed up here. > > > > #pragma names restore // we escape to Spg-Legacy and Axis2 code here > which is compiled AS_IS & SHORTENED > > // user-side function call > > *(__int32 *)wsi$ret_dx.dsc$a_pointer =3D fktmap((char *) > wsi$p_dx[0].dsc$a_pointer, inLen, (dsc_d *) &wsi$p_dx[1]); > > #pragma names save > > #pragma names uppercase, shortened // and back in HP WSIt world go > for UPPERCASE & SHORTENED > > > > // OUT & IN/OUT Floats get converted back to IEEE here. > > // OUT & IN/OUT structures get fixup up here. > > // OUT & IN/OUT strings get fixed up here > > > > // Determine size of output buffer, size of static + dynamic out para= ms > > wsi$size =3D 28 + wsi$p_dx[1].dsc$w_length; > > wsi$context->mem_disp->malloc( wsi$context->mem_disp->cnxid, wsi$size= , > (void **) ppbOutData ); > > wsi$init_encoder( &wsi$enc, *ppbOutData, wsi$pnum ); > > > > // Package up the parameters for returning here. > > wsi$add_param( &wsi$ret_dx, &wsi$enc ); > > wsi$add_param( &wsi$p_dx[1], &wsi$enc ); > > > > // Deallocate any memory used by Dynamic Strings here. > > wsi$dstr_free( &wsi$p_dx[1] ); > > > > // Return here > > *pOutLen =3D wsi$size; > > return error_status_ok; > > } > > > > > > -----Urspr=FCngliche Nachricht----- > Von: Akos Marton [mailto:makos999@gmail.com] > Gesendet: Montag, 5. Juli 2010 11:13 > > An: Apache AXIS C User List > Betreff: Re: AW: transfer limitations > > > > Hi Sepp, > > > > On Mon, Jul 5, 2010 at 9:24 AM, Stadelmann Josef > > wrote: > > > Given you send ALL your XML data into a file and parse it. Does the > parser bail out somewhere? > > I also thought it, but varying the sent amount of data, thus XML is > > not broken at the same point in every case. > > > > > > > > I just have similar situation. There is (in my mind) too much data > delivered; AND - Are you working with some kind of Strings through char*? > > Yes, axis2_char_t*. > > > > > > > > How long can a char* String be? How far does this pointer reach? Writin= g > all my XML data into a file and checking the XML Structure shows a very w= ell > formed XML file; But any attempt to parse it through the > axis2_libxml2_reader_wrapper is a no go and it bails out with various err= ors > toward the end of the files-content.- no I memory. > > I may not got what you mean above about the long of char*. You can > > allocate arbitrary (depends on your OS) amount of space, using a char* > > if you use dynamic memory management. How did you strike it out? > > > > > > > > Pointer size? 16, 32, 64? > > The size of pointer depends on your hardware and operating system, so > > that on 32bit operating system pointer has size of 4bytes. > > > > Now, I'm experimenting and learning how to configure the .Net side > > using WCF-technologies and set it to send data in chunks using MTOM. > > It seems for me, .Net-.Net can communicate with each other very well > > (of course), but needs more portability configuration to make it to be > > able to handle MTOM. > > In spite this we don't understand the reason of broken XMLs. > > > > Akos > > > > > > > > Sepp > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Akos Marton [mailto:makos999@gmail.com] > > > Gesendet: Freitag, 18. Juni 2010 10:20 > > > An: Apache AXIS C User List > > > Betreff: Re: AW: transfer limitations > > > > > > The problem is still not solved, so that any idea and answer is > appreciated. > > > > > > You can read a mail on c-user list about the same problem by Jan-fon, > > > except that he found the same situation on client-side. > > > subject: 'Client to receive large data problem' > > > date: Thu, 25 Feb 2010 11:07:53 GMT > > > > http://mail-archives.apache.org/mod_mbox/axis-c-user/201002.mbox/%3CCC8FF= 067F7F4E54796AFDF21339BA0FC134A94BA@orsmsx505.amr.corp.intel.com%3E > > > > > > Hope it helps, > > > Akos Marton > > > > > > > > > Stadelmann Josef wrote: > > >> Have you setup to send in chunks from CL to SV or do you expect that > more than 4 MB will go at once, within one request object? > > >> Sepp > > >> > > >> -----Urspr=FCngliche Nachricht----- > > >> Von: Akos Marton [mailto:makos999@gmail.com] > > >> Gesendet: Freitag, 11. Juni 2010 15:31 > > >> An: Apache AXIS C User List > > >> Betreff: Re: transfer limitations > > >> > > >> The XML is broken every time at different part. I tried to configure > httpd server with switching out many known size limitation and run axis2c > under this, but it also doesn't send the whole XML. > > >> > > >> The sent data is just broken somewhere. I watched it with tcpdump. > > >> Smaller XMLs can be transferred. > > >> > > >> Well, written a short tester code, which reads the necessary XML from > file and parses, decodes it perfectly, so that the algorithm and code mus= t > do the right. > > >> > > >> Any idea why the sending process is being broken? > > >> > > >> Thanks, > > >> mAkos > > >> > > >> > > >> Akos Marton wrote: > > >>> Hi List, > > >>> > > >>> Is there any limitation about the amount of data in a certain XML-tag= ? > > >>> In case of true, could I increase it somehow? > > >>> For instance ... by the size of 4Megabytes of base64 > > >>> code. The whole XML data does not reach the server (have cut at > > >>> certain part), but a smaller amount of data reaches it fully. > > >>> > > >>> Could be httpd.conf a solution? I do not know how to locate it for > > >>> axis2c binary version. > > >>> > > >>> Thanks, > > >>> mAkos > > >>> > > >>> > > >> > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org > > >> For additional commands, e-mail: c-user-help@axis.apache.org > > >> > > >> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org > > > For additional commands, e-mail: c-user-help@axis.apache.org > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org > > > For additional commands, e-mail: c-user-help@axis.apache.org > > > > > > > > > > > > > > -- > > People seldom notice clothes, if you wear a big smile. > > My grandmother uses Ubuntu, don't you think so?! > > OLVASD: http://www.xkcd.org/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org > > For additional commands, e-mail: c-user-help@axis.apache.org > > > Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org --0015175cdee24d90d7048aa3a56e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If you want to handle large chunks of data, =A0why not use MTOM?

Also, there is a data source mode in Axis2/C to stream the chunk t= hrough.=A0

We use used Axis2/C to send mega bytes = nearing giga range and it works for us for MTOM.=A0

For service case, I am not sure if it is a good idea to= use AXIOM to build a mega range doc - that means the service design is bus= ted.=A0

Samisa...

On Mon, Jul 5, 2010 at 6:20 PM, Stadelmann Josef <josef.stadelmann@axa-wint= erthur.ch> wrote:

Hope this helps you?`!

=A0

Yes, how did I strike it out? I am using WSIT from HP to integrate legacy systems. In short, big (huge) OMElement is= arriving at the JAVA side, (could well contain Bas64 encoded data) it is then serial= ized to a very large (huge) xml string; which is then pass to an out-of-process server via some sort of WsiIpcContext (IPC Interprocess Communication Chann= el); JNI is involved too.

=A0

=85.

=A0

When my large data arrives at the C-Legacy Server passed by WSIT ToolKit, I get a OpenVMS Descriptor which ha= s a Length Field and a Pointer to the data.

=A0

=85.

=A0

And now comes what I did not understand so far but since I try to help you, I was able to fix my own problem today.

So what I did not understand is as follow.

=A0

My data arrives at WSI$$fktmap() in *pbIndata with a inLen of Bystes set to 91344

The code you see below is HP-WSIT-generated-code, and it works fine.

=A0

The second green code line shows how this data is passed to my own routine fktmap() which is declared as<= /p>

=91__int32 fktmap (char * p1, int inLen, dsc_d * p2);=92

=A0

Given that pbInData can be passed further on via a P1 of type char* then please explain me the problem I am f= aced with.

=A0

1.=A0 In one case when I do

Unsigned __int16 scnt =3D strlen(P1);

I get scnt back as 25808 bytes

BUT

inLen shows me 91344

Why?

=A0

2.=A0 When I save P1 in a file, all bytes are there
BUT
When I pass it to

xml_reader =3D axiom_xml_reader_create_for_memory(env, payload_inp, scnt, encoding, AXIS2_XML_PARSER_TYPE_BUFFER);

Then I get the following errors in my log file for one transaction, at different call levels.

=A0

[Mon Jul=A0 5 14:10:28 2010] [error] DKB3:[SW-PROJEKTE.webservices.axis2.trunk.c.axiom.src.parser]libxml2_reader= _wrapper.c;36(886)

=A0 expected '>'

***************

=A0-- SEVERITY_ERROR

***************

[Mon Jul=A0 5 14:10:28 2010] [error] DKB3:[SW-PROJEKTE.webservices.axis2.trunk.c.axiom.src.parser]libxml2_reader= _wrapper.c;36(886)

=A0 Opening and ending tag mismatch: Fldnam line 0 and F

***************

=A0-- SEVERITY_ERROR

***************

[Mon Jul=A0 5 14:10:28 2010] [error] DKB3:[SW-PROJEKTE.webservices.axis2.trunk.c.axiom.src.parser]libxml2_reader= _wrapper.c;36(886)

=A0=A0Extra content at the end of the document

***************

=A0-- SEVERITY_ERROR

***************

[Mon Jul=A0 5 14:10:28 2010] [error] DKB3:[SW-PROJEKTE.webservices.axis2.trunk.c.axiom.src.parser]libxml2_reader= _wrapper.c;36(427)=A0

=A0 error occured in reading xml stream

[Mon Jul=A0 5 14:10:28 2010] [debug] DKB3:[SW-PROJEKTE.SPEZSRVW.axawl.spezpla.servers.SPgServer]SPg-legacy.c;100= (1593)

***************

=A0

=A0

The source of the problem is now fixed;

=A0

scnt receiving from strlen(P1) the byte count was of unsigned __int16, too short to keep a value bigger then 65535!= !!!!

=A0

scnt must be of type unsigned __int32 and only then it is able to keep the number 91344 !

=A0

One can take the calculator and enter 91344 as decimal number, then convert to hex and subtract 10000 Hex, then convert back to decimal.

A too short type of an integer maskes out what strlen() returns correctly.

=A0

=A0

BUT when the proper length of bytes is passed to axiom_xml_reader_create_for_memory()

the routine works fine and does not bail out with a -- SEVERITY ERROR

=A0

Conclusion of the day! If you work with very long strings (longer then FFFF =3D=3D=3D 65535) it is essential that y= ou use

=93unsigned __int32 OR unsigned __int64 as type for then =93scnt=94 =3D strlen(P1)=94 with P1 pointing to a string lon= ger than 65535 characters.

=A0

=A0

Now back to you: How do you detect that your XML is broken? Which routine informs you about that?

=A0

Sepp

=A0

=A0

///////////////////////////////////////////////////= ////////

//

// function: WSI$$fktmap

//

//

//

///////////////////////////////////////////////////= ////////

static unsigned int WSI$$fktmap (unsigned int=A0 sessionID,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MSGB=A0=A0=A0=A0=A0=A0=A0=A0=A0 *pbInData,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 int=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 inLen,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 MSGB=A0=A0=A0=A0=A0=A0=A0=A0=A0 **ppbOutData,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 int=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 *pOutLen)

{

#ifdef __DEBUG__

=A0=A0=A0 lib$signal(SS$_DEBUG);

#endif

=A0=A0=A0 char=A0=A0=A0 wsi$ret [4];

=A0=A0=A0 dsc_sd=A0 *wsi$p_dx;

=A0=A0=A0 dsc_a=A0=A0 *wsi$arydsc;

=A0=A0=A0 int=A0=A0 =A0=A0wsi$pnum =3D 2;

=A0=A0=A0 int=A0=A0=A0=A0 wsi$size =3D 0;

=A0=A0=A0 encoder wsi$enc;

=A0=A0=A0 dsc_sd=A0 wsi$ret_dx =3D {4, DSC$K_DTYPE_L, DSC$K_CLASS_S, wsi$ret, 0, 0, 0};

=A0=A0=A0 internal_cont= ext_t *wsi$context =3D (internal_context_t *) sessionID;

=A0

=A0=A0=A0 wsi$p_dx =3D (dsc_sd *) pbInData;<= /p>

=A0

=A0=A0=A0 // All pointers are converted from relative to absolute addresses here.

=A0=A0=A0 wsi$p_dx[0].dsc$a_pointer +=3D (int) wsi$p_dx;

=A0=A0=A0 wsi$p_dx[1].dsc$a_pointer +=3D (int) wsi$p_dx;

=A0

=A0=A0=A0 // Special parameters, such as Floats & Dynamic Strings, are fixup here.

=A0=A0=A0 wsi$dstr_fix( &wsi$p_dx[1] );<= /p>

=A0

=A0=A0=A0 // Structure parameters are fixed up here.

=A0

#pragma names restore=A0=A0 // we escape to Spg-Legacy and Axis2 code here which is compiled AS_IS & SHORTENED

=A0=A0=A0 // user-side function call

=A0=A0=A0 *(__int32 *)wsi$ret_dx.dsc$a_pointer =3D=A0 fktmap((char *) wsi$p_dx[0].dsc$a_pointer= , inLen, (dsc_d *) &wsi$p_dx[1]);

#pragma names save

#pragma names uppercase, shortened=A0=A0=A0=A0=A0=A0=A0 // and back in HP WSIt world go for UPPERCAS= E & SHORTENED

=A0

=A0=A0=A0 // OUT & IN/OUT Floats get converted back to IEEE here.

=A0=A0=A0 // OUT & IN/OUT structures get fixup up here.

=A0=A0=A0 // OUT & IN/OUT strings get fixed up here

=A0

=A0=A0=A0 // Determine size of output buffer, size of static + dynamic out params

=A0=A0=A0 wsi$size =3D 28 + wsi$p_dx[1].dsc$w_lengt= h;

=A0=A0=A0 wsi$context->mem_disp->malloc( wsi$context->mem_disp->cnxid, wsi$size, (void **) ppbOutData );

=A0=A0=A0 wsi$init_encoder( &wsi$enc, *ppbOutData, wsi$pnum );

=A0

=A0=A0=A0 // Package up the parameters for returning here.

=A0=A0=A0 wsi$add_param( &wsi$ret_dx,=A0 &wsi$enc );

=A0=A0=A0 wsi$add_param( &wsi$p_dx[1], &wsi$enc );

=A0

=A0=A0=A0 // Deallocate any memory used by Dynamic Strings here.

=A0=A0=A0 wsi$dstr_free( &wsi$p_dx[1] );=

=A0

=A0=A0=A0 // Return here

=A0=A0=A0 *pOutLen =3D wsi$size;

=A0=A0=A0 return error_status_ok;

}

=A0

=A0

-----Urspr=FCngliche Nach= richt-----
Von: Akos Marton [mailto:makos999@gmail.com]
Gesendet: Montag, 5. Juli 2010 11:13

An: Apache AXIS C User List
Betreff: Re: AW: transfer limitations

=A0

Hi Sepp,

=A0

On Mon, Jul 5, 2010 at 9:24 AM, Stadelmann Josef

<josef.stadelmann@axa-winterthur.ch> wrote:

> Given you send ALL your XML data into a file and parse it. Does the parser bail out somewhere?

I also thought it, but varying the sent amount of data, thus XML is

not broken at the same point in every case.

=A0

>=A0

> I just have similar situation. There is (in my mind) too much data delivered; AND - Are you working with some kind of Strings through char*?

Yes, axis2_char_t*.

=A0

>=A0

> How long can a char* String be? How far does this pointer reach? Writing all my XML data into a file and checking the XML Structure shows a very well formed XML file; But any attempt to parse it through the axis2_libxml2_reader_wrapper is a no go and it bails out with various errors toward the end of the files-content.- no I =A0memory.

I may not got what you mean above about the long of char*. You can

allocate arbitrary (depends on your OS) amount of space, using a char*

if you use dynamic memory management. How did you strike it out?

=A0

>=A0

> Pointer size? 16, 32, 64?

The size of pointer depends on your hardware and operating system, so

that on 32bit operating system pointer has size of 4bytes.

=A0

Now, I'm experimenting and learning how to configure the .Net side

using WCF-technologies and set it to send data in chunks using MTOM.

It seems for me, .Net-.Net can communicate with each other very well

(of course), but needs more portability configuration to make it to be

able to handle MTOM.

In spite this we don't understand the reason of broken XMLs.

=A0

Akos

=A0

>=A0

> Sepp

>=A0

> -----Urspr=FCngliche Nachricht-----

> Von: Akos Marton [mailto:makos999@gmail.com]

> Gesendet: Freitag, 18. Juni 2010 10:20

> An: Apache AXIS C User List

> Betreff: Re: AW: transfer limitations

>=A0

> The problem is still not solved, so that any idea and answer is appreciated.

>=A0

> You can read a mail on c-user list about the same problem by Jan-fon,

> except that he found the same situation on client-side.

> subject: =A0 =A0 =A0 =A0'Client to receive large data problem'

> date: =A0 =A0 =A0 =A0 =A0 Thu, 25 Feb 2010 11:07:53 GMT

> http://mail-archives.apache.org/mod_mbox/axis-c-user/2= 01002.mbox/%3CCC8FF067F7F4E54796AFDF21339BA0FC134A94BA@orsmsx505.amr.corp.i= ntel.com%3E

>=A0

> Hope it helps,

> Akos Marton

>=A0

>=A0

> Stadelmann Josef wrote:

>> Have you setup to send in chunks from CL to SV or do you expect that more than 4 MB will go at once, within one request object?

>> Sepp

>>=A0

>> -----Urspr=FCngliche Nachricht-----

>> Von: Akos Marton [mailto:makos999@gmail.com]

>> Gesendet: Freitag, 11. Juni 2010 15:31

>> An: Apache AXIS C User List

>> Betreff: Re: transfer limitations

>>=A0

>> The XML is broken every time at different part. I tried to configure httpd server with switching out many known size limita= tion and run axis2c under this, but it also doesn't send the whole XML.

>>=A0

>> The sent data is just broken somewhere. I watched it with tcpdump.

>> Smaller XMLs can be transferred.

>>=A0

>> Well, written a short tester code, which reads the necessary XML from file and parses, decodes it perfectly, so that the algorithm and code must do the right.

>>=A0

>> Any idea why the sending process is being broken?

>>=A0

>> Thanks,

>> mAkos

>>=A0

>>=A0

>> Akos Marton wrote:

>>> Hi List,

>>>=A0

>>> Is there any limitation about the amount of data in a certain XML-tag?

>>> In case of true, could I increase it somehow?

>>> For instance <image> ... </image> by the size of 4Megabytes of base64

>>> code. The whole XML data does not reach the server (have cut at

>>> certain part), but a smaller amount of data reaches it fully.

>>>=A0

>>> Could be httpd.conf a solution? I do not know how to locate it for

>>> axis2c binary version.

>>>=A0

>>> Thanks,

>>> mAkos

>>>=A0

>>>=A0

>>=A0

>>=A0

>>=A0

>> ---------------------------------------------------------------= ------

>> To unsubscribe, e-mail: c-u= ser-unsubscribe@axis.apache.org

>> For additional commands, e-mail: c-user-hel= p@axis.apache.org

>>=A0

>>=A0

>=A0

>=A0

> ---------------------------------------------------------------------

> To unsubscribe, e-mail: c-u= ser-unsubscribe@axis.apache.org

> For additional commands, e-mail: c-user-hel= p@axis.apache.org

>=A0

>=A0

> ---------------------------------------------------------------------

> To unsubscribe, e-mail: c-u= ser-unsubscribe@axis.apache.org

> For additional commands, e-mail: c-user-hel= p@axis.apache.org

>=A0

>=A0

=A0

=A0

=A0

--

People seldom notice clothes, if you wear a big smile.

My grandmother uses Ubuntu, don't you think so?!

OLVASD: http://www.xk= cd.org/

=A0

---------------------------------------------------------------------

To unsubscribe, e-mail: c-u= ser-unsubscribe@axis.apache.org

For additional commands, e-mail: c-user-hel= p@axis.apache.org

=A0

Samisa Abeysinghe
VP Engineer= ing
WSO2 Inc.
http:= //wso2.com
http://wso2.org


--0015175cdee24d90d7048aa3a56e--