Hi Michael,
Sorry, I meant the axis2 log file. Anyway if it doesn't contain any errors,
the probability of this error caused by Axis2/C is very low.
Supun..
On Tue, Aug 19, 2008 at 2:37 PM, Michael Sutter
<[EMAIL PROTECTED]>wrote:
> Hello Supun,
>
> what log file do you mean - the axis.log or the error log of the apache?
> Nevertheless, I don't found the exception in the log files and they contain
> a lot of messages as the log level is set to trace.
> Also I think that the service is running fine with the svn version, maybe
> it was
> a fixed memory leak with the apache module.
>
> Kind regards
> Michael
>
> Supun Kamburugamuva wrote:
>
> Hi Michael,
>
> By looking at your code it seems that it doesn't lead to a memory leak.
> Every time that function is called the object will be created and when the
> function finishes execution the object will be destroyed. I think there is
> another memory leak in your code. But I doubt that your problem is a result
> of a memory leak. Can you please send your log file?
>
> Supun..
>
> On Tue, Aug 19, 2008 at 1:47 PM, Michael Sutter <[EMAIL PROTECTED]
> > wrote:
>
>> Hello Supun,
>>
>> sorry for that. The stack is not created by me. It is the normal program
>> run-time stack from the service and the
>> object is not created as a global variable.
>>
>> The code looks like this:
>> adb_getStatusResponse_t *
>> axis2_skel_DAQStatus_getStatus(const axutil_env_t *env)
>> {
>> try {
>> FdDaq fd_daq;
>> }
>> catch (...) {
>> }
>> return return_node;
>> }
>>
>> where fd_daq is the object.
>>
>> Kind regards
>> Michael
>>
>> Supun Kamburugamuva wrote:
>>
>> Hi Michail,
>>
>> The stack the you mentioned is little bit confusing. Is it the stack in a
>> normal process run-time or a stack that you have created? If it is the stack
>> in a normal program run-time where are you creating your object in the code?
>> Are you creating the object as a global variable?
>>
>> Thanks,
>> Supun..
>>
>> On Tue, Aug 19, 2008 at 1:18 PM, Michael Sutter <
>> [EMAIL PROTECTED]> wrote:
>>
>>> Hello list,
>>>
>>> I have a problem with a Axis2 service and need some input if my service
>>> is developed the right
>>> way. Inside my service I make a call to a external library. So I make a
>>> variable of the object and
>>> put it on the stack. So normally the instance should be destroyed when
>>> the scope is lost. I think
>>> this is done when the execution of the service is finished and the output
>>> is given back to the client.
>>> Am I right?
>>>
>>> By doing this I had a strange problem. The mentioned service is called
>>> every 10 sec to give a state
>>> to the client. First I was running the service in Axis2 version 1.4 and
>>> get about every two hours an
>>> AxisFault: Too many open files. So I think that the destructor of my
>>> variable was not called and that
>>> I have memory leaks. After that I integrated a log message in the
>>> destructor to see, if it is called.
>>> Normally my service is running inside an Apache installation and I never
>>> saw the output of the log
>>> message.
>>>
>>> Nevertheless if I run the service in axis simple server I see the log
>>> output and so I think the implementation
>>> of my service is correct. When running the service inside the axis simple
>>> server I also get AxisFault,
>>> but after about 12 - 14 hours runtime. After searching the mailing list I
>>> found, that there is a memory
>>> leak in the mod_axis apache modul. So I compiled Axis2 from SVN and the
>>> service is running for about
>>> 17 hours without any problem.
>>>
>>> So to my question: Have I done something wrong in the implementation of
>>> my service by putting the instance
>>> on the stack and not explicitly calling the destructor or could it be
>>> that the SVN version fixes the problem?
>>> Nevertheless, why I'm getting the message by running the service inside
>>> the axis simple server, where I
>>> see that the destructor is called?
>>>
>>> Kind regards
>>> Michael
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>> --
>> Software Engineer, WSO2 Inc
>>
>>
>
>
> --
> Software Engineer, WSO2 Inc
>
>
--
Software Engineer, WSO2 Inc
