Unique copy of DLL

[tony obrien]

Hi,

I have written a Class Library in VB.net which provides Props/Meths to a
caller to hide the uglinesses of a TCP message protocol between a Client
and a Server.

All this works just fine.

Now I am trying to develop a LOAD TESTER app which spawns lotso' threads
each with this capability to bang the server.

The problerm is that the DLL class which worked just fine in a single
instance runs into problems because each version of the client-threads
seems to be reaching into the SAME copy of the DLL.

Everything I've read tells me to wrap the DLL areas that deal with
variables in SyncLocks... but this is NOT what I want... The DLL is NOT
STATELESS and so each new thread needs to have ITS OWN UNIQUE COPY of the
dll and its variables.

So the question is How Do I instantiate the DLL (class) in the thread to
ensure that it gets a NEW UNIQUE COPY running?

BTW, currently NONE of the Class's variables are public (though the
Props/Meths must be.) And the class DOES attempt to create a new copy
using...

Dim myDLLCls as theDLLClass
myDLLCls = New theDLLClass
but this does NOT generate a NEW copy in this thread.

Help !

regards,
tob

[Jon Skeet [C# MVP]]

tony obrien <tob_@_sourceco de-inc.comwrote:

Hi Jon, (I very much appreciate your taking the time and energy to help
me thru this !)

I have been able to at least determine how the problem exhibits itself...
the very bottom has this explanation.

<snip>

Below are some snippets to give you an idea of how this load tester
client operates....(an d yes I have left out gobs of code as to not bore
(overwhelm !) you... but remember this all works as a single instance so
I propose that it is in the 'multithreaded-ness' of it.)

Well, it's still very hard to actually reproduce it without a complete
application. You shouldn't need *very* much code - just enough to
connect to the server and, say, make the server echo whatever the
client writes to it.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[tony obrien]

Jon Skeet [C# MVP] <sk***@pobox.co mwrote in
news:MP******** *************** *@msnews.micros oft.com:

tony obrien <tob_@_sourceco de-inc.comwrote:

>Hi Jon, (I very much appreciate your taking the time and energy to
help me thru this !)

I have been able to at least determine how the problem exhibits
itself... the very bottom has this explanation.

<snip>

>Below are some snippets to give you an idea of how this load tester
client operates....(an d yes I have left out gobs of code as to not
bore (overwhelm !) you... but remember this all works as a single
instance so I propose that it is in the 'multithreaded-ness' of it.)

Well, it's still very hard to actually reproduce it without a complete
application. You shouldn't need *very* much code - just enough to
connect to the server and, say, make the server echo whatever the
client writes to it.

Hi Jon,

Yipee ! I have discovered the error of my ways.

As you originally pointed out it was a matter of "scope".

I was able to discern that there were 3 (helper) classes being brought into
existance outside the scope of the thread trying to communicate... and it
was THEIR data that would occasionally get squashed.

I actually did what you suggested and kept taking parts away until adding
back the "last part" caused the breakage. And this lead me to discover
there were 2 other parts that had a similar issue.

I can now run MANY clients into the server and they all keep themselves
straight (and the server is a blur ;<>)

Thanks and regards,
tob

[Jon Skeet [C# MVP]]

tony obrien <tob_@_sourceco de-inc.comwrote:

Yipee ! I have discovered the error of my ways.

Hooray :)

As you originally pointed out it was a matter of "scope".

I was able to discern that there were 3 (helper) classes being brought into
existance outside the scope of the thread trying to communicate... and it
was THEIR data that would occasionally get squashed.

I actually did what you suggested and kept taking parts away until adding
back the "last part" caused the breakage. And this lead me to discover
there were 2 other parts that had a similar issue.

That's the genius part of me insisting on complete programs - it means
that half the time I don't need to figure out anything myself :)

I can now run MANY clients into the server and they all keep themselves
straight (and the server is a blur ;<>)

Cool. Glad you got it sorted.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too