Board index » delphi » Indy Components vs Fastnet components, out of resources problem

Indy Components vs Fastnet components, out of resources problem

Is there any serious problems with the Fastnet Components, because many
people seem to favour the Indy ones.

We are useing the NMMsgServ components that receives 263 character text
message about one per second. The PC soon runs out of resources and
eventually the Delphi app hangs. This happens after about 7500 messages.

Is there any buffer build up that needs to be cleared out after every OnMsg
evert run, or maybe some known memory leak? Will this problem go away if I
use Indy equivalent components?

Thanx.

 

Re:Indy Components vs Fastnet components, out of resources problem


Quote
"Christo Botha" <chris...@scsolutions.co.za> wrote in message

news:3b330958_1@dnews...

Quote
> Is there any buffer build up that needs to be cleared out after every
OnMsg
> evert run, or maybe some known memory leak? Will this problem go away if I
> use Indy equivalent components?

Those of us on the Indy team actively try to support the Indy component
suite. Your problem might be present in our component suite too, but I think
you'll find that we're reasonably efficient in addressing bug reports.

Besides, Indy comes with _full_ source. If push comes to shove, you'll be
able to fix the problem yourself! ;-)

--
Rune

Re:Indy Components vs Fastnet components, out of resources problem


Thanx Rune, do you maybe know of any way to overcome this resource draining
problem?

Quote
Rune Moberg <rmob...@arxi.no> wrote in message news:3b331381_1@dnews...
> "Christo Botha" <chris...@scsolutions.co.za> wrote in message
> news:3b330958_1@dnews...
> > Is there any buffer build up that needs to be cleared out after every
> OnMsg
> > evert run, or maybe some known memory leak? Will this problem go away if
I
> > use Indy equivalent components?

> Those of us on the Indy team actively try to support the Indy component
> suite. Your problem might be present in our component suite too, but I
think
> you'll find that we're reasonably efficient in addressing bug reports.

> Besides, Indy comes with _full_ source. If push comes to shove, you'll be
> able to fix the problem yourself! ;-)

> --
> Rune

Re:Indy Components vs Fastnet components, out of resources problem


Quote
"Christo Botha" <chris...@scsolutions.co.za> wrote in message

news:3b331c5b_2@dnews...

Quote
> Thanx Rune, do you maybe know of any way to overcome this resource
draining
> problem?

No.

Try to narrow it down. Create a small test application and see if you're
able to reproduce the problem with as little code as possible. Next report
the issue... (I've only seen negative comments wrt Fastnet's support though,
so you might be better off to switch components for that reason alone,
provided of course that my observation is accurate/representative)

--
Rune

Re:Indy Components vs Fastnet components, out of resources problem


You filed a bug report with Indy with exactly the same problem. Somehow I
doubt that this is a problem with Indy or NM (which is rare in this case
since NM has a lot of bugs). It's probably your application.

Re:Indy Components vs Fastnet components, out of resources problem


I was advised by Indy team member Rune Moberg (see earlier reply) to file a
bug report, because Indy might have the same problem as NM.

At this stage I am desperate and pursue all avenues. My test application on
the receiving end looks like this :

On form create I make the component active and :

procedure TfrmServer.TCPServerExecute(AThread: TIdPeerThread);
begin
  with AThread.Connection do
  begin
    WriteLn('Welcome');
    label1.caption := readln(#10,0);
    application.ProcessMessages;
    Disconnect;
  end;
end;

Which is exactly the Indy Demo program with

 " label1.caption := readln(#10,0);
   application.ProcessMessages;"

added

Can this application cause the heavy use of resources?

Hadi Hariri - Team Indy <hadi...@pbe.com> wrote in message
news:3b3364a4_2@dnews...

Quote
> You filed a bug report with Indy with exactly the same problem. Somehow I
> doubt that this is a problem with Indy or NM (which is rare in this case
> since NM has a lot of bugs). It's probably your application.

Re:Indy Components vs Fastnet components, out of resources problem


Quote
>I was advised by Indy team member Rune Moberg (see earlier reply) to
>file a bug report, because Indy might have the same problem as NM.

I'm not complaining about the bug report, I'm stating that sine your post
refers to NM and the bug report is of Indy, it's very unlikely that this
could be an Indy problem.

Quote
>At this stage I am desperate and pursue all avenues. My test application
>on the receiving end looks like this :

>On form create I make the component active and :

>procedure TfrmServer.TCPServerExecute(AThread: TIdPeerThread);
>begin
>  with AThread.Connection do
>  begin
>    WriteLn('Welcome');
>    label1.caption := readln(#10,0);
>    application.ProcessMessages;
>    Disconnect;
>  end;
>end;

Incorrect. First, you should NOT access any visual components directly from
a thread. You should use Synchronize.

Second, Application.ProcessMessages is not needed there either. This is a
thread. It's executed in the context ofthe thread.

Re:Indy Components vs Fastnet components, out of resources problem


Quote
Christo Botha wrote:
> I was advised by Indy team member Rune Moberg (see earlier reply) to file a
> bug report, because Indy might have the same problem as NM.

I meant file a bugreport if you can reproduce the same issue with Indy.
(and you can?)

Quote
> procedure TfrmServer.TCPServerExecute(AThread: TIdPeerThread);
> begin
>   with AThread.Connection do
>   begin
>     WriteLn('Welcome');
>     label1.caption := readln(#10,0);
>     application.ProcessMessages;
>     Disconnect;
>   end;
> end;

Ok, this runs in the context of the AThread thread. Do not call
Application.ProcessMessages.

--
Rune

Re:Indy Components vs Fastnet components, out of resources problem


I want not, i do not beleve, that in a indy demo, the is a label.caption
inside a a server THREAD. This will chrash, you must do a "syncronize".

regards

Ernst Gerlach
http://www.gerlach-mtl.de/
i...@gerlach-mtl.de

"Christo Botha" <chris...@scsolutions.co.za> schrieb im Newsbeitrag
news:3b3372fc_1@dnews...

Quote
> I was advised by Indy team member Rune Moberg (see earlier reply) to file
a
> bug report, because Indy might have the same problem as NM.

> At this stage I am desperate and pursue all avenues. My test application
on
> the receiving end looks like this :

> On form create I make the component active and :

> procedure TfrmServer.TCPServerExecute(AThread: TIdPeerThread);
> begin
>   with AThread.Connection do
>   begin
>     WriteLn('Welcome');
>     label1.caption := readln(#10,0);
>     application.ProcessMessages;
>     Disconnect;
>   end;
> end;

> Which is exactly the Indy Demo program with

>  " label1.caption := readln(#10,0);
>    application.ProcessMessages;"

> added

> Can this application cause the heavy use of resources?

> Hadi Hariri - Team Indy <hadi...@pbe.com> wrote in message
> news:3b3364a4_2@dnews...
> > You filed a bug report with Indy with exactly the same problem. Somehow
I
> > doubt that this is a problem with Indy or NM (which is rare in this case
> > since NM has a lot of bugs). It's probably your application.

Re:Indy Components vs Fastnet components, out of resources problem


Quote
Ernst Gerlach wrote:
> I want not, i do not beleve, that in a indy demo, the is a label.caption
> inside a a server THREAD. This will chrash, you must do a "syncronize".

FWIW: A workaround would be to use SendMessage instead.

s := 'fubar';
SendMessage(Label1.Handle, WM_SETTEXT, 0, Integer(PChar(s)));
This will make the thread block until the main VCL thread is able to
process the WM_SETTEXT message.

--
Rune

Re:Indy Components vs Fastnet components, out of resources problem


ernst.gerl...@epost.de (Ernst Gerlach) wrote in <3b33ab15_1@dnews>:

Quote
>I want not, i do not beleve, that in a indy demo, the is a label.caption
>inside a a server THREAD. This will chrash, you must do a "syncronize".

There isn't. Take a look at his original post. He says the Indy demo plus:
Quote
> Which is exactly the Indy Demo program with

>  " label1.caption := readln(#10,0);
>    application.ProcessMessages;"

> added

Re:Indy Components vs Fastnet components, out of resources problem


"Hadi Hariri - Team Indy" <hadi...@pbe.com> schrieb im Newsbeitrag
news:3b34447f_1@dnews...
Quote
> ernst.gerl...@epost.de (Ernst Gerlach) wrote in <3b33ab15_1@dnews>:

> >I want not, i do not beleve, that in a indy demo, the is a label.caption
> >inside a a server THREAD. This will chrash, you must do a "syncronize".

> There isn't. Take a look at his original post. He says the Indy demo plus:

> > Which is exactly the Indy Demo program with

> >  " label1.caption := readln(#10,0);
> >    application.ProcessMessages;"

> > added

I know, but Christo pushed the code of a client to a "OnExecute".

Ernst

Re:Indy Components vs Fastnet components, out of resources problem


chris...@scsolutions.co.za (Christo Botha) wrote in <3b330958_1@dnews>:

Quote
>Is there any serious problems with the Fastnet Components, because many
>people seem to favour the Indy ones.

>We are useing the NMMsgServ components that receives 263 character text
>message about one per second. The PC soon runs out of resources and
>eventually the Delphi app hangs. This happens after about 7500 messages.

The NM stuff is VERY buggy and unsupported. Check the "What NM customers
say" link on the Indy page for a good archive.

--
Chad Z. Hower (Kudzu) - http://www.pbe.com/Kudzu/
Current Location: Siberia
      "Programming is an art form that fights back"

Other Threads