Re: Attachment memory optimization size as a parameter in axis2.xml

[Manjula Peiris]

On Tue, 2008-02-19 at 11:39 +0530, Manjula Peiris wrote:
> Hi All,
> 
> So I will use MTOMChunkBufferSize .
> 
> And we need to specify the number of buffers in this case. I like
> 
> MTOMChunkBuffers as the parameter name.

I think MTOMMAXChunkBuffers is good.

>  So in the chunking case the
> maximum size of the attachment the system can handle is,
> 
> MTOMChunkBufferSize * MTOMChunkBuffers.
> 
> Default for MTOMChunkBufferSize = 1
> Default for MTOMChunkBuffers = 1000
> 
> So in the default case it can handle 1000MB.
> 
> suggestions please...
> 
> Thanks,
> -Manjula.
> 
> 
> On Tue, 2008-02-19 at 11:23 +0530, Samisa Abeysinghe wrote:
> > Dumindu Pallewela wrote:
> > > On Feb 19, 2008 9:51 AM, Manjula Peiris <[EMAIL PROTECTED]> wrote:
> > >   
> > >> I also think chunkBufferSizeForMTOM makes more sense. Actually I first
> > >> thought about this but felt it is more complex for users. That's why
> > >> suggest attachmentSize. But with a comment meaning of this param can be
> > >> simplified.
> > >> 
> > >
> > > IMHO, a better way to express the same would be *MTOMChunkBufferSize*.
> > >   
> > 
> > Ok, it is shorter. I like it.
> > 
> > Samisa...
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Attachment memory optimization size as a parameter in axis2.xml

[Manjula Peiris]

Hi All,

So I will use MTOMChunkBufferSize .

And we need to specify the number of buffers in this case. I like

MTOMChunkBuffers as the parameter name. So in the chunking case the
maximum size of the attachment the system can handle is,

MTOMChunkBufferSize * MTOMChunkBuffers.

Default for MTOMChunkBufferSize = 1
Default for MTOMChunkBuffers = 1000

So in the default case it can handle 1000MB.

suggestions please...

Thanks,
-Manjula.


On Tue, 2008-02-19 at 11:23 +0530, Samisa Abeysinghe wrote:
> Dumindu Pallewela wrote:
> > On Feb 19, 2008 9:51 AM, Manjula Peiris <[EMAIL PROTECTED]> wrote:
> >   
> >> I also think chunkBufferSizeForMTOM makes more sense. Actually I first
> >> thought about this but felt it is more complex for users. That's why
> >> suggest attachmentSize. But with a comment meaning of this param can be
> >> simplified.
> >> 
> >
> > IMHO, a better way to express the same would be *MTOMChunkBufferSize*.
> >   
> 
> Ok, it is shorter. I like it.
> 
> Samisa...
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Attachment memory optimization size as a parameter in axis2.xml

[Samisa Abeysinghe]

Dumindu Pallewela wrote:

On Feb 19, 2008 9:51 AM, Manjula Peiris <[EMAIL PROTECTED]> wrote:
  

I also think chunkBufferSizeForMTOM makes more sense. Actually I first
thought about this but felt it is more complex for users. That's why
suggest attachmentSize. But with a comment meaning of this param can be
simplified.



IMHO, a better way to express the same would be *MTOMChunkBufferSize*.
  


Ok, it is shorter. I like it.

Samisa...


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Attachment memory optimization size as a parameter in axis2.xml

[Dumindu Pallewela]

On Feb 19, 2008 9:51 AM, Manjula Peiris <[EMAIL PROTECTED]> wrote:
> I also think chunkBufferSizeForMTOM makes more sense. Actually I first
> thought about this but felt it is more complex for users. That's why
> suggest attachmentSize. But with a comment meaning of this param can be
> simplified.

IMHO, a better way to express the same would be *MTOMChunkBufferSize*.

Regards,
Dumindu.


-- 
Dumindu Pallewela
http://blog.dumindu.com
GPG ID: 0x9E131672

WSO2 | "Oxygenating the Web Service Platform" | http://wso2.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Attachment memory optimization size as a parameter in axis2.xml

[Manjula Peiris]

I also think chunkBufferSizeForMTOM makes more sense. Actually I first
thought about this but felt it is more complex for users. That's why
suggest attachmentSize. But with a comment meaning of this param can be
simplified.

Thanks,
-Manjula.

On Mon, 2008-02-18 at 20:24 +0530, Samisa Abeysinghe wrote:
> Senaka Fernando wrote:
> > Hi Samisa,
> >
> > chunkBufferSize4MTOM or chunkBufferSizeForMTOM ? 
> 
> I am OK for the second one.
> 
> Samisa...
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dynamic Adding New Service/Operation to AXIS2C

[Samisa Abeysinghe]

Senaka Fernando wrote:

Hi Mike,

  

It doesn't look like AXIS2C is currently capable of adding new Services
or Operations dynamically. We will be imbedding AXIS2C in our commercial
application, and have additional requirements that are not in the the
current product (We think).



No, we don't support hot deployment.
  


Hot deployment is not supported, but you can add services and operations 
dynamically, using the configuration hierarchy, programatically.

We have done it with WSO2's products and it works.



It appears that AXIS2C reads the potential services it has on startup,
and keeps the service.xml and the DLL that contains the web service
routines in a locked state. We have the need to dynamically add new
services, and operations to an existing service. This can be done by
bringing the server down, and then back up with the new DLL and
service.xml file, but this is not desirable (given that we want to be as
close to 24/7 as possible).



Server restart will take around a minute, so if you set the timeout to
greater than say 2 minutes on your client side, you shouldn't see any
issues.
  


Again, as I mentioned earlier, you can add services and operations 
dynamically, and implement your own message receiver to get the job 
done. This way, you do not need to shut down.


Samisa...


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FW: Question regarding the adjustment of response timeouts

[Senaka Fernando]

Hi Cliff,

We'll look into this before the 1.3.0 release and try to have it fixed
before we release.

Regards,
Senaka

> Hello Dev Team,
>
> I presented this question with regards to using timeouts in the
> axis2-c-user forum. Dimuthu is getting similar results under Linux, and
> suggested that there may be a bug in timeout behaviour. Please see below
> for the details.
>
> Cheers,
> Cliff
>
> -Original Message-
> From: Dimuthu Gamage [mailto:[EMAIL PROTECTED]
> Sent: February 16, 2008 05:23
> To: Apache AXIS C User List
> Subject: Re: [AXIS2C] Question regarding the adjustment of response
> timeouts
>
> Hi,
>
> I too checked it in Linux and got the same result,
>
> Seems we are not using axis2_options_get_timeout_in_milli_seconds
> anywhere.. If this is a bug, should be fixed before the 1.3 release.
>
> Thanks
> Dimuthu
>
> On Feb 16, 2008 1:07 AM, Clifford THOMPSON
> <[EMAIL PROTECTED]> wrote:
>>
>>
>> Hello,
>>
>> I have a question about adjusting the timeout period for web services.
>
>> Our current software dictates that we can have upwards of a 300 second
>
>> delay before a response is sent (we have a large amount of data that
>> needs to be prepared before being sent). Currently, our web service
>> component will timeout after roughly 60 sec (I'm not sure if this is
>> the Axis API, or from the OS). I have tried using some of the timeout
>> functions in the Axis2C API, but they appear to have no effect (if I
>> set the timeout 5 secs and the server takes 10 secs to respond, the
>> client will wait 10 secs for the response). I am assuming that I am
>> using the API incorrectly. We are working under WinXP, and have
> generate portions of our code using the WSDL2C tool.
>> We have chosen to generate synchronous code using WSDL2C (so the
>> eventual call in the generate code will be to
>> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough
>> paraphrase of the code that we have and how I thought the timeout
>> function should be
>> applied:
>>
>> env  = axutil_env_create_all( "MyServiceLog.log",
>>   AXIS2_LOG_LEVEL_TRACE);
>> assert(NULL != env);
>>
>> stub = axis2_stub_create_MyService( env,
>> AXIS2_GETENV("AXIS2C_HOME"),
>>
>> "http://myserver.ca:8080/services/MyService";);
>> assert(NULL != stub);
>>
>>
>> status = axis2_options_set_timeout_in_milli_seconds(
>>  axis2_stub_get_options( stub,
>>  env ),
>>  env,
>>  30);
>> assert(AXIS2_SUCCESS == status);
>>
>> /*  */
>> /* lots of interleaving non-Axis2C code */
>> /*  */
>>
>> responseNode = axis2_stub_op_MyService_MyOperation(
>>   stub,
>>   env,
>>   headerNode1,
>>   headerNode2,
>>   bodyNode);
>> if(NULL !=)
>> {
>> /* process the response */
>> }
>> else
>> {
>>/* log the response error */
>> }
>>
>> Thank you in advance for the help.
>>
>> Cheers,
>> Cliff
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

FW: Question regarding the adjustment of response timeouts

[Clifford THOMPSON]

Hello Dev Team,

I presented this question with regards to using timeouts in the
axis2-c-user forum. Dimuthu is getting similar results under Linux, and
suggested that there may be a bug in timeout behaviour. Please see below
for the details.

Cheers,
Cliff

-Original Message-
From: Dimuthu Gamage [mailto:[EMAIL PROTECTED] 
Sent: February 16, 2008 05:23
To: Apache AXIS C User List
Subject: Re: [AXIS2C] Question regarding the adjustment of response
timeouts

Hi,

I too checked it in Linux and got the same result,

Seems we are not using axis2_options_get_timeout_in_milli_seconds
anywhere.. If this is a bug, should be fixed before the 1.3 release.

Thanks
Dimuthu

On Feb 16, 2008 1:07 AM, Clifford THOMPSON
<[EMAIL PROTECTED]> wrote:
>
>
> Hello,
>
> I have a question about adjusting the timeout period for web services.

> Our current software dictates that we can have upwards of a 300 second

> delay before a response is sent (we have a large amount of data that 
> needs to be prepared before being sent). Currently, our web service 
> component will timeout after roughly 60 sec (I'm not sure if this is 
> the Axis API, or from the OS). I have tried using some of the timeout 
> functions in the Axis2C API, but they appear to have no effect (if I 
> set the timeout 5 secs and the server takes 10 secs to respond, the 
> client will wait 10 secs for the response). I am assuming that I am 
> using the API incorrectly. We are working under WinXP, and have
generate portions of our code using the WSDL2C tool.
> We have chosen to generate synchronous code using WSDL2C (so the 
> eventual call in the generate code will be to 
> "axis2_svc_client_send_receive_with_op_qname"). Here is a rough 
> paraphrase of the code that we have and how I thought the timeout 
> function should be
> applied:
>
> env  = axutil_env_create_all( "MyServiceLog.log",
>   AXIS2_LOG_LEVEL_TRACE);
> assert(NULL != env);
>
> stub = axis2_stub_create_MyService( env,
> AXIS2_GETENV("AXIS2C_HOME"),
>
> "http://myserver.ca:8080/services/MyService";);
> assert(NULL != stub);
>
>
> status = axis2_options_set_timeout_in_milli_seconds(
>  axis2_stub_get_options( stub,
>  env ),
>  env,
>  30);
> assert(AXIS2_SUCCESS == status);
>
> /*  */
> /* lots of interleaving non-Axis2C code */
> /*  */
>
> responseNode = axis2_stub_op_MyService_MyOperation(
>   stub,
>   env,
>   headerNode1,
>   headerNode2,
>   bodyNode);
> if(NULL !=)
> {
> /* process the response */
> }
> else
> {
>/* log the response error */
> }
>
> Thank you in advance for the help.
>
> Cheers,
> Cliff
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dynamic Adding New Service/Operation to AXIS2C

[Senaka Fernando]

Hi Mike,

> It doesn't look like AXIS2C is currently capable of adding new Services
> or Operations dynamically. We will be imbedding AXIS2C in our commercial
> application, and have additional requirements that are not in the the
> current product (We think).

No, we don't support hot deployment.

>
>
>
> It appears that AXIS2C reads the potential services it has on startup,
> and keeps the service.xml and the DLL that contains the web service
> routines in a locked state. We have the need to dynamically add new
> services, and operations to an existing service. This can be done by
> bringing the server down, and then back up with the new DLL and
> service.xml file, but this is not desirable (given that we want to be as
> close to 24/7 as possible).

Server restart will take around a minute, so if you set the timeout to
greater than say 2 minutes on your client side, you shouldn't see any
issues.

>
>
>
> Any suggestions on this request, before I start looking to see what I
> need to do.

If someone could work on hot deployment support for Axis2/C that would be
great.

Regards,
Senaka

>
>
>
> Mike Mckee
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Dynamic Adding New Service/Operation to AXIS2C

[Mike McKee]

It doesn't look like AXIS2C is currently capable of adding new Services
or Operations dynamically. We will be imbedding AXIS2C in our commercial
application, and have additional requirements that are not in the the
current product (We think). 

 

It appears that AXIS2C reads the potential services it has on startup,
and keeps the service.xml and the DLL that contains the web service
routines in a locked state. We have the need to dynamically add new
services, and operations to an existing service. This can be done by
bringing the server down, and then back up with the new DLL and
service.xml file, but this is not desirable (given that we want to be as
close to 24/7 as possible).

 

Any suggestions on this request, before I start looking to see what I
need to do.

 

Mike Mckee

Re: Issue in using 'detach' for cloning

[Sanjaya Ratnaweera]

Samisa Abeysinghe wrote:

Hi Bill, Kasun and others,
   Thank you all for taking time to explain this problem in detail. 
Looking at the ADB use case that Bill has portrayed, I am sure other 
users too would be interested in such a case where they can 'get' form 
one ADB type and 'set' on another ADB type.


   Lets create a branch for this and try to solve the problem. Bill, 
have you already done some work with respect to ref-count? If so we 
can start form that.

 I can think of the following cases that we can try to fix/implement:
   1. Implement the ref-cout shallow copy mechanism proposed by Bill
   2. Try and implement a deep copy version of detach (so that we can 
detach and attach)

   3. Implement a serailize/deserialize based deep copy

I have created a branch for this. Here's the url.

https://svn.apache.org/repos/asf/webservices/axis2/branches/c/axiomfix/

Thanks

   ~sanjaya


I can look into 2 and 3.

Thanks,
Samisa...

[EMAIL PROTECTED] wrote:
Samisa, I can't speak directly to Kasun's use case, but I can 
describe what prompted me to need a tree copy and/or clone method.  
The generated adb stubs return an object of wsdl type any to the app 
as a node tree, detached from the response message.  They also accept 
an object of wsdl type any as a node tree, to be attached to the 
request message.  In each case, the interface has ownership of the 
object, and frees the object when the interface object is freed.  So 
the get accessor method to the object returns a pointer to the object 
tree but does not transfer ownership.  The set accessor method 
accepts a pointer to the object tree and takes ownership of it. 
You are correct that cloning alone would be used in a routing app.  
But imagine that the app receives an object from the service, 
modifies it, and sends the app back to the service.  To be able to 
free the response interface object after processing the response, the 
app needs the ability to copy or clone the object to be able to late 
use it.  After modifying the object, the app would then pass the 
object back to the service in a later request.  If the app needs the 
ability to pass the object to the service while retaining a copy of 
it for later processing, it needs a copy or clone operation again as 
the service will discard the version that was sent when the request 
interface object was freed.  With a copy or a clone one can achieve 
the same result in different ways; a copy that allows one to 
configure what is copied lets the code add what it needs to a reduced 
tree, whereas a clone allows one to later remove or modify what is 
unneeded from the cloned tree. 
Were the generated adb interface different, the requirement for a 
copy would be reduced.  Say the adb interface provided an accessor 
method, get, that transferred ownership of the tree to the client 
app, and that the set method accepted a pointer to the object to be 
passed without freeing the tree when the request interface object was 
freed.  Then these copies would be eliminated, but the free of the 
tree after sending a request would now be the responsibility of the 
client app.  One would need a copy method only if the original object 
was a template for generating multiple objects. 
This may be very application specific, and I don't know how general 
the need is.  I do know that I encountered it, and it sounds like 
Kasun has a very similar requirement.  When I encountered it and 
found no suitable method present, I wrote one that met my needs.  But 
this requirement may be common enough to warrant inclusion. 
I'm pretty sure you are correct, there is little need for this inside 
the SOAP engine.  The need is driven more by the interface to axiom, 
at least with the adb classes.  Kasun's issue with detach losing 
namespace references and the tree becoming invalid arises, of course, 
in the context of the adb classes detaching the object from the SOAP 
response message, and so can arise for anyone using the 
service/client interface even without the adb classes. 
Whether addressing this involves a significant architecture change 
depends on the implementation.  One can implement a copy method with 
options for what is copied using the current interfaces, it just 
requires a bit of research into the intricacies of axiom_node and its 
friends.  A clone by way of serializing and deserializing the 
structure I think uses builder interfaces that are not public and 
would need to be included, but does not involve an architecture 
change.  Certainly a copy-on-write clone algorithm does involve some 
pervasive changes, but such an algorithm has other problems as well, 
already discussed. 
Bill


-Original Message-
From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] Sent: Saturday, 
February 16, 2008 10:33 PM

To: Apache AXIS C Developers List
Subject: Re: Issue in using 'detach' for cloning

Kasun Indrasiri wrote:
 

Hi all,

I think, through out this thread there are various possible 
implementations were di

Re: Attachment memory optimization size as a parameter in axis2.xml

[Samisa Abeysinghe]

Senaka Fernando wrote:

Hi Samisa,

chunkBufferSize4MTOM or chunkBufferSizeForMTOM ? 


I am OK for the second one.

Samisa...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2]Test echo_rest sample ( was : Re: [Axis2]Axis2/C 1.3.0 RC2)

[Dinesh Premalal]

Hi,

Samisa Abeysinghe <[EMAIL PROTECTED]> writes:
>> Devs, Please look into echo_rest sample in the svn head and please
>> let us know your thoughts. If you wait until RC3 that will be too
>> late for me :)
>
> Well, that is the basic idea of an RC, to test and fix ;)

If it is a known issue, we could fix it even before a RC ;) I think ,
it is not worth go for another RC just for fixing echo_rest sample.  

thanks,
Dinesh
-- 
http://nethu.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Attachment memory optimization size as a parameter in axis2.xml

[Senaka Fernando]

Hi Samisa,

chunkBufferSize4MTOM or chunkBufferSizeForMTOM ? I think the second is
better. :) Btw, as you say we need to add a comment saying that the size
is in MB. That's what I emphasized in another reply to this mail.

Regards,
Senaka

> Manjula Peiris wrote:
>> Hi devs,
>>
>> Inside mime_parser when the stream is chunked the data is written in to
>> array of buffers. Currently the size of the buffer is hard coded and
>> using this size we can optimize the memory usage for larger attachments.
>> So I think we can put this size as a parameter in the axis2.xml.
>>
>> For an example a server frequently processing 50 MB attachments
>>
>> 50
>>
>
> How about chunkBufferSize4MTOM as the param name? Using 'attachment' in
> the param name is inconsistent, as othe MTOM related params have MTOM in
> the name. e.g. enableMTOM
>
> Of course, a comment should mention that the given size is assumed to be
> in MB.
>
> Samisa...
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2]Test echo_rest sample ( was : Re: [Axis2]Axis2/C 1.3.0 RC2)

[Samisa Abeysinghe]

Dinesh Premalal wrote:

Hi Senaka,

 Please find my comment in line.


On Feb 18, 2008 7:56 PM, Senaka Fernando <[EMAIL PROTECTED] 
> wrote:


Hi Dinesh,

All of these are fixed on the head.


That's  great  !

> We got issues related to echo_rest samples , both in RC1 and RC2. 
Shall we

> make necessary changes to echo_rest samples and ask developers to give
> their
> feedback before pack it again? Lets try to get no more issues related to
> REST sample in RC3 :)

Devs, Please look into echo_rest sample in the svn head and please let 
us know your thoughts. If you wait until RC3 that will be too late for 
me :)


Well, that is the basic idea of an RC, to test and fix ;)

Samisa...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Axis2]Test echo_rest sample ( was : Re: [Axis2]Axis2/C 1.3.0 RC2)

[Dinesh Premalal]

Hi Senaka,

 Please find my comment in line.


On Feb 18, 2008 7:56 PM, Senaka Fernando <[EMAIL PROTECTED]> wrote:

> Hi Dinesh,
>
> All of these are fixed on the head.


That's  great  !

> We got issues related to echo_rest samples , both in RC1 and RC2. Shall we
> make necessary changes to echo_rest samples and ask developers to give
> their
> feedback before pack it again? Lets try to get no more issues related to
> REST sample in RC3 :)

Devs, Please look into echo_rest sample in the svn head and please let us
know your thoughts. If you wait until RC3 that will be too late for me :)

thanks,
Dinesh
-- 
http://nethu.org/

Re: Attachment memory optimization size as a parameter in axis2.xml

[Samisa Abeysinghe]

Dinesh Premalal wrote:

Hi,
Samisa Abeysinghe <[EMAIL PROTECTED]> writes:
  
50   
  

How about chunkBufferSize4MTOM as the param name? Using 'attachment'
in the param name is inconsistent, as othe MTOM related params have
MTOM in the name. e.g. enableMTOM


Though I'm +1 chunkBufferSize4MTOM feel little uncomfortable with
number 4. Do we use numbers for parameter names in axis2.xml?
  


We can use 'for', then it is 2 more chars long ;)

Samisa...


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Issue in using 'detach' for cloning

[Samisa Abeysinghe]

[EMAIL PROTECTED] wrote:
I noticed in working on changes to axiom_node_detach to ensure that the namespaces remain valid, that most of the uses of axiom_node_detach within Axis are followed immediately by an axiom_node_free_tree.  It seems a shame to incur the overhead of re-declaring the namespaces in the subtree being detached, just to free them all immediately.  
  


I think, semantically, it is correct, you want to delete a sub tree, so 
you detach it and then free it.

What do people think of a new combined method, axiom_node_detach_and_free_tree?
  


Would not this method merely call detach and then free tree?

Or, alternatively, of expanding axiom_node_free_tree to implicitly detach the 
tree if it is attached before freeing it?  (I prefer this choice.)
  


This sounds OK to me. If you want to free a node, and it already has a 
parent, then it makes sense to detach before free. The current 
implementation assumes that the user is done with the node, when free 
tree is called, hence the need for detach and free.


Samisa...


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Attachment memory optimization size as a parameter in axis2.xml

[Dinesh Premalal]

Hi,
Samisa Abeysinghe <[EMAIL PROTECTED]> writes:
>> 50   
>
> How about chunkBufferSize4MTOM as the param name? Using 'attachment'
> in the param name is inconsistent, as othe MTOM related params have
> MTOM in the name. e.g. enableMTOM
Though I'm +1 chunkBufferSize4MTOM feel little uncomfortable with
number 4. Do we use numbers for parameter names in axis2.xml?

thanks,
Dinesh
-- 
http://nethu.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2]Axis2/C 1.3.0 RC2

[Senaka Fernando]

Hi Dinesh,

All of these are fixed on the head.

Regards,
Senaka

> Hi ,
>
> On Feb 18, 2008 11:31 AM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:
>
>> I tested the source zip on Windows:
>>
>> Here are the issues:
>> 1. echo_non_blocking fails. This must be fixed before release IMHO
>> 2. Why do I get all the *.exe.manifest in the deply/bin/samples folder?
>> I do not think they are required when I build form source. Can we please
>> drop all the other files, and leave only the exe files in the
>> deply/bin/samples folder?
>
>
> Is anyone working on these issues right now ? I think we could fix these
> issues with small modifications :)
>
>
>>
>> 3. When I run 'echo_rest.exe -h', I get the help that says I can use
>> -mGET. But when I run with -mGET, it does return me the html with
>> services.
>
>
> We got issues related to echo_rest samples , both in RC1 and RC2. Shall we
> make necessary changes to echo_rest samples and ask developers to give
> their
> feedback before pack it again? Lets try to get no more issues related to
> REST sample in RC3 :)
>
> Thoughts ?
>
> thanks,
> Dinesh
> --
> http://nethu.org/
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2]Axis2/C 1.3.0 RC2

[Senaka Fernando]

Ok, will look into this too.

Regards,
Senaka

> Hi Dimuthu,
>
>
> On Feb 18, 2008 11:48 AM, Dimuthu Gamage <[EMAIL PROTECTED]> wrote:
>
>> Hi Dinesh,
>>
>>
>> Regarding the mail [AXIS2C] Question regarding the adjustment of
>> response timeouts[1],
>>
>> If this issue is there (I found the issue in the SVN, so it should be
>> in the RC2 as well), we should fix it before the release.
>>
>
> Yes, It should be in RC2 as well. Lets try to get it fix for 1.3.0.
>
> thanks,
> Dinesh
>
>
> --
> http://nethu.org/
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2C-991) axiom_soap_header_create_with_parent in soap_header doesn't detach body node

[Senaka Fernando (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Senaka Fernando resolved AXIS2C-991.


Resolution: Fixed

Fixed Issue. Thanks Lukas.

The issue here is the body must always go after the header and the body_node is 
always not the first child but rather is the first element.

Regards,
Senaka

> axiom_soap_header_create_with_parent in soap_header doesn't detach body node
> 
>
> Key: AXIS2C-991
> URL: https://issues.apache.org/jira/browse/AXIS2C-991
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Lukas JOSEFIK
>Assignee: Senaka Fernando
>
> if header is added and between soap envelope and soap body is text node, then 
> is detached this text node, not body node.
> detach first element node instead of first...
> if (axiom_node_get_first_child(parent_node, env))
> {
> .
>   body_node = axiom_node_get_first_child(parent_node, env);
>   if(AXIOM_ELEMENT == axiom_node_get_node_type(body_node, env))
> ..
> }

-- 
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]

Re: [Axis2]Axis2/C 1.3.0 RC2

[Dinesh Premalal]

Hi ,

On Feb 18, 2008 11:31 AM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:

> I tested the source zip on Windows:
>
> Here are the issues:
> 1. echo_non_blocking fails. This must be fixed before release IMHO
> 2. Why do I get all the *.exe.manifest in the deply/bin/samples folder?
> I do not think they are required when I build form source. Can we please
> drop all the other files, and leave only the exe files in the
> deply/bin/samples folder?


Is anyone working on these issues right now ? I think we could fix these
issues with small modifications :)


>
> 3. When I run 'echo_rest.exe -h', I get the help that says I can use
> -mGET. But when I run with -mGET, it does return me the html with
> services.


We got issues related to echo_rest samples , both in RC1 and RC2. Shall we
make necessary changes to echo_rest samples and ask developers to give their
feedback before pack it again? Lets try to get no more issues related to
REST sample in RC3 :)

Thoughts ?

thanks,
Dinesh
-- 
http://nethu.org/

Re: Attachment memory optimization size as a parameter in axis2.xml

[Samisa Abeysinghe]

Manjula Peiris wrote:

Hi devs,

Inside mime_parser when the stream is chunked the data is written in to
array of buffers. Currently the size of the buffer is hard coded and
using this size we can optimize the memory usage for larger attachments.
So I think we can put this size as a parameter in the axis2.xml.

For an example a server frequently processing 50 MB attachments 

50 
  


How about chunkBufferSize4MTOM as the param name? Using 'attachment' in 
the param name is inconsistent, as othe MTOM related params have MTOM in 
the name. e.g. enableMTOM


Of course, a comment should mention that the given size is assumed to be 
in MB.


Samisa...



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces

[Bill Mitchell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Mitchell updated AXIS2C-675:
-

Attachment: diff.txt

> Detach node does not handle namespaces
> --
>
> Key: AXIS2C-675
> URL: https://issues.apache.org/jira/browse/AXIS2C-675
> Project: Axis2-C
>  Issue Type: Bug
>  Components: xml/om
>Reporter: Jamie Lyon
> Attachments: diff.txt
>
>
> When detaching a node from a parent, if the current node or any of it's 
> children have any namespaces declared in it's parent or above, when the node 
> is detached, and the parent freed, any namespace references are lost.

-- 
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]

[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces

[Bill Mitchell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Mitchell updated AXIS2C-675:
-

Attachment: (was: diff.txt)

> Detach node does not handle namespaces
> --
>
> Key: AXIS2C-675
> URL: https://issues.apache.org/jira/browse/AXIS2C-675
> Project: Axis2-C
>  Issue Type: Bug
>  Components: xml/om
>Reporter: Jamie Lyon
> Attachments: diff.txt
>
>
> When detaching a node from a parent, if the current node or any of it's 
> children have any namespaces declared in it's parent or above, when the node 
> is detached, and the parent freed, any namespace references are lost.

-- 
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]

[jira] Assigned: (AXIS2C-991) axiom_soap_header_create_with_parent in soap_header doesn't detach body node

[Senaka Fernando (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Senaka Fernando reassigned AXIS2C-991:
--

Assignee: Senaka Fernando

> axiom_soap_header_create_with_parent in soap_header doesn't detach body node
> 
>
> Key: AXIS2C-991
> URL: https://issues.apache.org/jira/browse/AXIS2C-991
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Lukas JOSEFIK
>Assignee: Senaka Fernando
>
> if header is added and between soap envelope and soap body is text node, then 
> is detached this text node, not body node.
> detach first element node instead of first...
> if (axiom_node_get_first_child(parent_node, env))
> {
> .
>   body_node = axiom_node_get_first_child(parent_node, env);
>   if(AXIOM_ELEMENT == axiom_node_get_node_type(body_node, env))
> ..
> }

-- 
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]

Re: [Axis2]Axis2/C 1.3.0 RC2

[Dinesh Premalal]

Hi Dimuthu,


On Feb 18, 2008 11:48 AM, Dimuthu Gamage <[EMAIL PROTECTED]> wrote:

> Hi Dinesh,
>
>
> Regarding the mail [AXIS2C] Question regarding the adjustment of
> response timeouts[1],
>
> If this issue is there (I found the issue in the SVN, so it should be
> in the RC2 as well), we should fix it before the release.
>

Yes, It should be in RC2 as well. Lets try to get it fix for 1.3.0.

thanks,
Dinesh


-- 
http://nethu.org/

RE: Issue in using 'detach' for cloning

[bmitchell]

I noticed in working on changes to axiom_node_detach to ensure that the 
namespaces remain valid, that most of the uses of axiom_node_detach within Axis 
are followed immediately by an axiom_node_free_tree.  It seems a shame to incur 
the overhead of re-declaring the namespaces in the subtree being detached, just 
to free them all immediately.  

What do people think of a new combined method, axiom_node_detach_and_free_tree?

Or, alternatively, of expanding axiom_node_free_tree to implicitly detach the 
tree if it is attached before freeing it?  (I prefer this choice.)

Either approach would allow the use of an internal detach method that would 
skip the re-declaration of the parent namespaces.  

Thanks,
Bill


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces

[Bill Mitchell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Mitchell updated AXIS2C-675:
-

Attachment: (was: diff.txt)

> Detach node does not handle namespaces
> --
>
> Key: AXIS2C-675
> URL: https://issues.apache.org/jira/browse/AXIS2C-675
> Project: Axis2-C
>  Issue Type: Bug
>  Components: xml/om
>Reporter: Jamie Lyon
> Attachments: diff.txt
>
>
> When detaching a node from a parent, if the current node or any of it's 
> children have any namespaces declared in it's parent or above, when the node 
> is detached, and the parent freed, any namespace references are lost.

-- 
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]

[jira] Updated: (AXIS2C-675) Detach node does not handle namespaces

[Bill Mitchell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Mitchell updated AXIS2C-675:
-

Attachment: diff.txt

> Detach node does not handle namespaces
> --
>
> Key: AXIS2C-675
> URL: https://issues.apache.org/jira/browse/AXIS2C-675
> Project: Axis2-C
>  Issue Type: Bug
>  Components: xml/om
>Reporter: Jamie Lyon
> Attachments: diff.txt
>
>
> When detaching a node from a parent, if the current node or any of it's 
> children have any namespaces declared in it's parent or above, when the node 
> is detached, and the parent freed, any namespace references are lost.

-- 
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]

[jira] Resolved: (AXIS2C-931) ASF policy on cryptographic features

[Glen Daniels (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glen Daniels resolved AXIS2C-931.
-

Resolution: Fixed

All set, forgot to close JIRA.


> ASF policy on cryptographic features
> 
>
> Key: AXIS2C-931
> URL: https://issues.apache.org/jira/browse/AXIS2C-931
> Project: Axis2-C
>  Issue Type: Task
>  Components: documentation
>Affects Versions: Current (Nightly)
> Environment: N/A
>Reporter: Malinda Kaushalye Kapuruge
>Assignee: Glen Daniels
> Fix For: 1.3.0
>
>
> Since Apache Axis2/C is having cryptographic features (for https support), it 
> needs to be listed here[1] according to the ASF policy. Please find more 
> details here[2]. This has to be done by someone having site-dev karma (which 
> includes all of the PMC chairs). 
> [1]http://www.apache.org/licenses/exports/
> [2]http://www.apache.org/dev/crypto.html 

-- 
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]

[jira] Created: (AXIS2C-991) axiom_soap_header_create_with_parent in soap_header doesn't detach body node

[Lukas JOSEFIK (JIRA)]

axiom_soap_header_create_with_parent in soap_header doesn't detach body node


 Key: AXIS2C-991
 URL: https://issues.apache.org/jira/browse/AXIS2C-991
 Project: Axis2-C
  Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Lukas JOSEFIK


if header is added and between soap envelope and soap body is text node, then 
is detached this text node, not body node.
detach first element node instead of first...

if (axiom_node_get_first_child(parent_node, env))
{
.
body_node = axiom_node_get_first_child(parent_node, env);
if(AXIOM_ELEMENT == axiom_node_get_node_type(body_node, env))
..
}



-- 
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]

Re: Attachment memory optimization size as a parameter in axis2.xml

[Senaka Fernando]

Wouldn't it be better to say


50

Otherwise won't it be sort of misleading? Because that seems like the
maximum attachment size rather than the buffer size. Am I missing
something here?

Regards,
Senaka

> Hi devs,
>
> Inside mime_parser when the stream is chunked the data is written in to
> array of buffers. Currently the size of the buffer is hard coded and
> using this size we can optimize the memory usage for larger attachments.
> So I think we can put this size as a parameter in the axis2.xml.
>
> For an example a server frequently processing 50 MB attachments
>
> 50
>
> Thoughts please .
>
> Thanks,
> -Manjula.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Attachment memory optimization size as a parameter in axis2.xml

[Manjula Peiris]

Hi devs,

Inside mime_parser when the stream is chunked the data is written in to
array of buffers. Currently the size of the buffer is hard coded and
using this size we can optimize the memory usage for larger attachments.
So I think we can put this size as a parameter in the axis2.xml.

For an example a server frequently processing 50 MB attachments 

50 

Thoughts please .

Thanks,
-Manjula.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2C-986) axiom_xml_writer_write_empty_element() doesn't behave as expected

[Senaka Fernando (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Senaka Fernando resolved AXIS2C-986.


Resolution: Fixed

Fixed Issue. Thanks Kaushayle for testing this.

> axiom_xml_writer_write_empty_element() doesn't behave as expected
> -
>
> Key: AXIS2C-986
> URL: https://issues.apache.org/jira/browse/AXIS2C-986
> Project: Axis2-C
>  Issue Type: Bug
>  Components: guththila, xml/om, xml/parser
>Reporter: Senaka Fernando
>Assignee: Senaka Fernando
> Fix For: 1.3.0
>
> Attachments: diff.txt
>
>
> axiom_xml_writer_write_empty_element() doesn't behave as expected. This 
> affects both Libxml2 and Guththila parsers.

-- 
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]

[jira] Commented: (AXIS2C-990) echo_blocking_dual sample fails when it runs more than once after server restart

[Dushshantha Chandradasa (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569859#action_12569859
 ] 

Dushshantha Chandradasa commented on AXIS2C-990:


i changed the client as follows:

 if (svc_client)
{
AXIS2_SLEEP(1);
axis2_svc_client_free(svc_client, env);
svc_client = NULL;
AXIS2_SLEEP(1);
}


But then, it segfaults. The ealier error is still unchanged. 


> echo_blocking_dual sample fails when it runs more than once after server 
> restart
> 
>
> Key: AXIS2C-990
> URL: https://issues.apache.org/jira/browse/AXIS2C-990
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: Current (Nightly)
> Environment: Windows 
>Reporter: Dushshantha Chandradasa
> Fix For: 1.3.0
>
>
> echo_blocking_dual sample fails with following error message when I try to 
> run it several times. After I restart the server, it runs once and starts 
> failing again. 
> Received OM : 
> soapenv:Sender v:Value> xmlns:xml="ht
> tp://www.w3.org/XML/1998/namespace">A read attempt(HTTP) for the reply 
> without s
> ending the request

-- 
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]

[jira] Resolved: (AXIS2C-989) echo_non_blocking sample gives a memory corruption failure on Windows.

[Senaka Fernando (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Senaka Fernando resolved AXIS2C-989.


Resolution: Fixed
  Assignee: Senaka Fernando

Changed to older version that didn't have any issues.

> echo_non_blocking sample gives a memory corruption failure on Windows.
> --
>
> Key: AXIS2C-989
> URL: https://issues.apache.org/jira/browse/AXIS2C-989
> Project: Axis2-C
>  Issue Type: Bug
>  Components: samples
>Affects Versions: 1.3.0
> Environment: Windows XP, LibXML
>Reporter: Dushshantha Chandradasa
>Assignee: Senaka Fernando
> Fix For: 1.3.0
>
>
> echo_non_blocking sample gives a memory corruption failure on Windows

-- 
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]

[Fwd: Echo_non_blocking diff]

[Senaka Fernando]

Please test this on WIndowsIndex: samples/user_guide/clients/echo_non_blocking.c
===
--- samples/user_guide/clients/echo_non_blocking.c  (revision 628474)
+++ samples/user_guide/clients/echo_non_blocking.c  (working copy)
@@ -131,11 +131,13 @@
 
 if (!(count < 30))
 {
-printf("\necho client invike FAILED. Counter timed out.\n");
+isComplete = 1;
+printf("\necho client invoke FAILED. Counter timed out.\n");
 }
 
 if (svc_client)
 {
+AXIS2_SLEEP(1);
 axis2_svc_client_free(svc_client, env);
 svc_client = NULL;
 }
@@ -186,7 +188,7 @@
 printf("echo stub invoke FAILED!\n");
 status = AXIS2_FAILURE;
 }
-else
+else if (isComplete != 1)
 {
 axis2_char_t *om_str = NULL;
 om_str = axiom_node_to_string(ret_node, env);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2]Axis2/C 1.3.0 RC2

[Samisa Abeysinghe]

Senaka Fernando wrote:

Hi Samisa,

-mGET will not work unless you edit the services.xml of the echo service.
Should this be a part of "-h"'s message?
  


Yes, otherwise that is misleading.

You can strip *.exe.manifest when you install by changing that embed
manifest option.
  


This should be the default, I guess. Otherwise, it looks cluttered when 
trying to see the samples to be run, specially for new users.


Samisa...


Regards,
Senaka

  

I tested the source zip on Windows:

Here are the issues:
1. echo_non_blocking fails. This must be fixed before release IMHO
2. Why do I get all the *.exe.manifest in the deply/bin/samples folder?
I do not think they are required when I build form source. Can we please
drop all the other files, and leave only the exe files in the
deply/bin/samples folder?
3. When I run 'echo_rest.exe -h', I get the help that says I can use
-mGET. But when I run with -mGET, it does return me the html with
services.

Thanks,
Samisa...


Dinesh Premalal wrote:


Hi Devs,
  I packed an uploaded Axis2/C 1.3.0 RC2 here [1]. Please test
and send your feedback.

thanks,
Dinesh

1. http://people.apache.org/~dinesh/release/1.3.0-RC2/


--
http://nethu.org/


No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.20.5/1279 - Release Date:
2/14/2008 6:35 PM

  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]