Hi,
When my program is running (sending a stream about each second with
SslHttpCli), I see the memory useage in the taskmanager increasing
continuous.
The SslHttpCli is running in a seperate thread.
FastMM doesn't report any memory leaks, except for a string(20 bytes)
AssumeMultiThreaded is enable in FastMM.
Anyone seen this before ?
PAul

If FastMM doesn't report any leak, then the increase probably result from
memory fragmentation.
It is also possible that memory allocation are done in global objects (I
don't know which one) which a freeed at program exist and nevertheless "eat"
more and more memory.

Paul wrote:
Hi,

When my program is running (sending a stream about each second with
SslHttpCli), I see the memory useage in the taskmanager increasing
continuous.
The SslHttpCli is running in a seperate thread.
FastMM doesn't report any memory leaks, except for a string(20 bytes)
AssumeMultiThreaded is enable in FastMM.
Anyone seen this before ?

Have you run the same application w/o SSL as well? I once tested the
SSL stuff with TSslWsocket against a multi-threading SSL TWSocketServer
over many hours and several million requests/responses with plenty of
concurrent client connections. I couldn't see any obvious memory leak.

BTW: Are you using (Ics)SslThrdLock.pas which is a Must when
running SSL multi-threaded?

Arno Garrels [TeamICS]

PAul

Francois PIETTE wrote:
If FastMM doesn't report any leak, then the increase probably result
from memory fragmentation.

I think FastMM solved the memory-fragmention-problem of the old Delphi
memory manager. That's at least my expierence in applications where
GetMem/FreeMem is called frequently (several thousands calls per second).

Arno Garrels [TeamICS]

It is also possible that memory allocation are done in global objects
(I don't know which one) which a freeed at program exist and
nevertheless "eat" more and more memory.

Paul wrote:
Hi,

When my program is running (sending a stream about each second with
SslHttpCli), I see the memory useage in the taskmanager increasing
continuous.

May be cached SSL sessions are the reason?

Arno Garrels [TeamICS]

The SslHttpCli is running in a seperate thread.
FastMM doesn't report any memory leaks, except for a string(20 bytes)
AssumeMultiThreaded is enable in FastMM.
Anyone seen this before ?

PAul

BTW: Are you using (Ics)SslThrdLock.pas which is a Must when
running SSL multi-threaded?
No, how to use it ?
Paul

Paul wrote:
>BTW: Are you using (Ics)SslThrdLock.pas which is a Must when
>running SSL multi-threaded?
No, how to use it ?
It's described in the unit header.
Arno Garrels [TeamICS]
Paul

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Sunday, 08, 2006 8:49 PM
Subject: Re: [twsocket] Memory leaks

Paul wrote:
BTW: Are you using (Ics)SslThrdLock.pas which is a Must when
running SSL multi-threaded?
>
>
>No, how to use it ?

It's described in the unit header.

Arno Garrels [TeamICS]


>
>
>Paul

I'm using V5 with this application.
I don't have this unit

Paul

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Sunday, 08, 2006 8:49 PM
Subject: Re: [twsocket] Memory leaks

Paul wrote:
BTW: Are you using (Ics)SslThrdLock.pas which is a Must when
running SSL multi-threaded?
>
>
>No, how to use it ?

It's described in the unit header.

Arno Garrels [TeamICS]


>
>
>Paul

Hi Arno,
i don't see any reason why i can't have a clent in the main thread and one
in a seperate thread working together with the dll's.
This would mean that 2 applications wouldn't be able to use the same
SSL-dll's also
Paul

Paul wrote:
I'm using V5 with this application.
I don't have this unit

Then you don't use latest source!
It's included in IcsSslSrcV5g.zip, just downloaded and verified.

Arno Garrels [TeamICS]

Paul

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Sunday, 08, 2006 8:49 PM
Subject: Re: [twsocket] Memory leaks


>Paul wrote:
BTW: Are you using (Ics)SslThrdLock.pas which is a Must
when running SSL multi-threaded?

No, how to use it ?
>
>It's described in the unit header.
>
>
>Arno Garrels [TeamICS]
>
>
>

Paul
>--
>To unsubscribe or change your settings for TWSocket mailing list
>please goto
>Visit our website at http://www.overbyte.be

Paul wrote:
Hi Arno,

i don't see any reason why i can't have a clent in the main thread
and one in a seperate thread working together with the dll's.

This would mean that 2 applications wouldn't be able to use the same
SSL-dll's also

Ssl is thread safe as long as we provide the appropriate locking
callbacks. SSL is a multi-platform library, different S use
different locking methods ;-)

Paul

If FastMM doesn't report any leak, then the increase probably result
from memory fragmentation.

I think FastMM solved the memory-fragmention-problem of the old Delphi
memory manager. That's at least my expierence in applications where
GetMem/FreeMem is called frequently (several thousands calls per second).

FastMM has a much better behaviour than the standard memory allocator prior
to D2006. But this doesn't eliminate fragmentation completely.

Contribute to the SSL Effort. Visit

I see no difference between http and https. so SSL has nothing to do with it

Paul

Message
From: "Arno Garrels" <arno.garrels (AT) gmx (DOT) de>
To: "ICS support mailing" <twsocket (AT) elists (DOT) org>
Sent: Sunday, 08, 2006 8:40 PM
Subject: Re: [twsocket] Memory leaks

Paul wrote:
>Hi,
>
>When my program is running (sending a stream about each second with
>SslHttpCli), I see the memory useage in the taskmanager increasing
>continuous.

May be cached SSL sessions are the reason?

Arno Garrels [TeamICS]


>The SslHttpCli is running in a seperate thread.
>FastMM doesn't report any memory leaks, except for a string(20 bytes)
>AssumeMultiThreaded is enable in FastMM.
>Anyone seen this before ?
>
>PAul

I see no difference between http and https. so SSL has nothing to do with
it

That's a good news. It eliminate the need to investigate for the SSL part.
Have a look at your global dynamic variables and dynamic variables assigned
to forms which have the same timelife as the program.

Contribute to the SSL Effort. Visit

That's a good news. It eliminate the need to investigate for the SSL part.
Have a look at your global dynamic variables and dynamic variables
assigned
to forms which have the same timelife as the program.

Everything is created in runtime.
Basically, I created an object that I can use in a program or in a service.
It's easier to test it as a program.
Streams and bitmaps are created and freed continuously. (5kb to 2Mb)
I never tried it before, but maybe it's possible to reuse a stream instead
of free + recreate.

Paul

That's a good news. It eliminate the need to investigate for the SSL
part.
Have a look at your global dynamic variables and dynamic variables
assigned
to forms which have the same timelife as the program.

Everything is created in runtime.
Basically, I created an object that I can use in a program or in a
service.
It's easier to test it as a program.
Streams and bitmaps are created and freed continuously. (5kb to 2Mb)

If I remember well, FatsMM has a function to dump allocated block list.
Using it, you could see what is filling the memory after some time and
discover your bug.

I never tried it before, but maybe it's possible to reuse a stream instead
of free + recreate.

It is always interesting to reuse objects instead of destroying them and
recreate a fresh copy. But speaking about stream, it depends on the type of
stream. A TFileStream has to be destroyed to close the file.

Contribute to the SSL Effort. Visit

It is always interesting to reuse objects instead of destroying them and
recreate a fresh copy. But speaking about stream, it depends on the type
of
stream. A TFileStream has to be destroyed to close the file.

So as long I'm sending streams with a HttpCli, I don't need to free the
stream in the requestdone event and create them int the Get-Post-Put methods
?
Just create the streams when the component is created and free when
destroying the component?

Paul

10/9/06, Paul <paul.blommaerts (AT) telenet (DOT) bewrote:
It is always interesting to reuse objects instead of destroying them and
recreate a fresh copy. But speaking about stream, it depends on the type
of
stream. A TFileStream has to be destroyed to close the file.

I thought about extending HTTPCli and adding a property,
"CreateMemoryStreams". I use memory streams with HTTPCli and have to
do this for every use. It would be nice it the create/free code was
already done for me with a simple property setting.
-Johnnie Norsworthy

>It is always interesting to reuse objects instead of destroying them
>and
>recreate a fresh copy. But speaking about stream, it depends on the
>type
>of
>stream. A TFileStream has to be destroyed to close the file.
>
I thought about extending HTTPCli and adding a property,
"CreateMemoryStreams". I use memory streams with HTTPCli and have to
do this for every use. It would be nice it the create/free code was
already done for me with a simple property setting.

The best way to do that is not to modify the component but derive a new one
and add the behaviour you like.

10/9/06, Francois PIETTE <francois.piette (AT) skynet (DOT) bewrote:
I thought about extending HTTPCli and adding a property,
"CreateMemoryStreams". I use memory streams with HTTPCli and have to
do this for every use. It would be nice it the create/free code was
already done for me with a simple property setting.

The best way to do that is not to modify the component but derive a new one
and add the behaviour you like.

That's what I am going to do. It's just a handy shortcut for my applications.

When you derive a component from an installed component do you have to
create packages for design-time installation? It would be nice if I
could drop a THHTPCli on a form and then change it to a
THTTPCli_DescendantName in code and be able to access the properties I
added.
-Johnnie Norsworthy

>I thought about extending HTTPCli and adding a property,
>"CreateMemoryStreams". I use memory streams with HTTPCli and have to
>do this for every use. It would be nice it the create/free code was
>already done for me with a simple property setting.
>>
>The best way to do that is not to modify the component but derive a new
>one
>and add the behaviour you like.
>
That's what I am going to do. It's just a handy shortcut for my
applications.

When you derive a component from an installed component do you have to
create packages for design-time installation? It would be nice if I
could drop a THHTPCli on a form and then change it to a
THTTPCli_DescendantName in code and be able to access the properties I
added.

This is only possible if you don't affect anything the IDE will use. Bad
idea IM
It is better to create your own package and put all your components in that
package.

>It is always interesting to reuse objects instead of destroying them and
>recreate a fresh copy. But speaking about stream, it depends on the type
>of
>stream. A TFileStream has to be destroyed to close the file.
>
>
So as long I'm sending streams with a HttpCli, I don't need to free the
stream in the requestdone event and create them int the Get-Post-Put
methods
?
Just create the streams when the component is created and free when
destroying the component?

If the stream behaviour is what you need, I don't see any problem with that.

If the stream behaviour is what you need, I don't see any problem with
that.

What about memory allocation ?

Paul

PS: for all who's concerned about memory leaks :
I've asked Pierre le Riche (author of FastMM) about memory consumption.
The only thing you need to check is the virtual memory.
It's not the standard configuration in the taskmanager, so you need to
enable it first

If the stream behaviour is what you need, I don't see any
problem with that.

What about memory allocation ?

It is better to keep the object created of course. But this doesn't change
anything regarding to what the object optimize the memory it may have
allocated.

Contribute to the SSL Effort. Visit