Smalltalk › Instantiations

Smalltalk sockets - what is the failure rate?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

a62754

Smalltalk sockets - what is the failure rate?

I have a Java socket client talking to a smalltalk socket server. I am running this on Linux.

Java client is coded with test logic - establish client connection from java to smalltalk, send dummy string to server, get dummy string back - close client socket - loop.

After millions of connections and around 7 hours, i got a read timeout on java side.

Don't have any monitoring tools right now to see if gc came in the way or something else. Since java got a read timeout, i assume smalltalk acted weird. Smalltalk send was not a problem since its coded with a timeout of 10s and java read is coded with a timeout of 2 min. Something else in smalltalk came in the way.

Question 1: whats the general expectation here? should it run forever until server space runs out or some other external factor interferes?

Question 2: How do i make this communication reliable? any best practices for fault-tolerance to be coded here?

Question 3: How do i determine state of my smalltalk program - if gc is running or its stuck doing something /etc?

Thanks

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

Louis LaBrunda

Re: Smalltalk sockets - what is the failure rate?

Hi,

I have many VA Smalltalk programs that talk to each other and to other hosts (not running Smalltalk). I use Totally Objects SocketSet (I don't think that matters, I just want to get that out there). I see socket problems all the time. I don't have a number I can state as a failure rate. I use read timeouts of about 30 seconds. Knowing what is going on in my code, I don't see how it could take 30 to reply even if a garbage collection kicked in at the wrong time.

I think the problem my lie in windows socket code. I have no evidence to support this claim but I also have little reason to think windows socket code is perfect.

Maybe you can write the other half (the part Smalltalk does now) in Java so Java is on both side and see what kind of failure rate you get then.

Lou

On Tuesday, May 20, 2014 5:32:07 AM UTC-4, a62754 wrote:

I have a Java socket client talking to a smalltalk socket server. I am running this on Linux.

Java client is coded with test logic - establish client connection from java to smalltalk, send dummy string to server, get dummy string back - close client socket - loop.

After millions of connections and around 7 hours, i got a read timeout on java side.

Don't have any monitoring tools right now to see if gc came in the way or something else. Since java got a read timeout, i assume smalltalk acted weird. Smalltalk send was not a problem since its coded with a timeout of 10s and java read is coded with a timeout of 2 min. Something else in smalltalk came in the way.

Question 1: whats the general expectation here? should it run forever until server space runs out or some other external factor interferes?

Question 2: How do i make this communication reliable? any best practices for fault-tolerance to be coded here?

Question 3: How do i determine state of my smalltalk program - if gc is running or its stuck doing something /etc?

Thanks

a62754

Re: Smalltalk sockets - what is the failure rate?

Thanks for the response.

The Java community also acknowledges socket errors - so guess java to java would also give me some failures.

I was also thinking using jdk 32 bit instead of 64 since ST is 32 bit - so probably something with the 64 but linux socket libraries could be causing some instability.

But it's a good thing to know that others are also facing such problems.

So, how do you code around such things? if communication fails wait for 30s and try again?

Probably after an error, have ST respond to a 'isalive' socket message before giving it the actual work string?

Louis LaBrunda

Re: Smalltalk sockets - what is the failure rate?

Hi,

snip..

So, how do you code around such things? if communication fails wait for 30s and try again?

TCP/IP seems to be good at recovering (silently) from problems on its own if it can. So, if a problem works its way up to my Smalltalk code, I give up on the connection. For the majority of my programs reconnecting (after 30 seconds give or take, to let things calm down) is fine. I log the event and move on.

Lou

Richard Sargent

Re: Smalltalk sockets - what is the failure rate?

Administrator

In reply to this post by a62754

On Tuesday, May 20, 2014 2:32:07 AM UTC-7, a62754 wrote:

Java client is coded with test logic - establish client connection from java to smalltalk, send dummy string to server, get dummy string back - close client socket - loop.

After millions of connections and around 7 hours, i got a read timeout on java side.

<...>

Question 1: whats the general expectation here? should it run forever until server space runs out or some other external factor interferes?

Question 2: How do i make this communication reliable? any best practices for fault-tolerance to be coded here?

Question 3: How do i determine state of my smalltalk program - if gc is running or its stuck doing something /etc?

There are a couple of additional possibilities. But, I am no expert on sockets!

1) Check out the SysInternals suite for monitoring tools. I don't know of any particular tool for monitoring sockets, but those guys wrote a lot of useful tools.
2) The OS will provide only a finite number of sockets, so you do need to know whether it is running out of socket resources. I am no socket expert, so I don't know if it is enough to "close a socket" to actually return the resources to the OS.
3) Run a VA memory monitor. I'm pretty sure it comes with one, but I don't remember where to find it. The ENVY Stats configuration map, perhaps? Monitor VA's memory spaces. Also, SysInternals' Process Explorer is a great tool for seeing what OS processes are doing ... in detail.
4) I seem to recall there is a distinction between a socket and a connection. When a socket accepts a connect request (I'm vague on details!), the OS allocates a connection data structure for that specific conversation. You may not be running out of sockets, per se, but the connection pool, instead.

Beyond this topic, in response to your "best practices" question, one should always assume socket connections and transport layer protocols are "unreliable" or error prone. TCP guarantees the order of delivery, but not delivery itself. So design your application with this in mind.

For example, years ago when I worked at Geico, we implemented a web service-based three tier solution. We ran with a pair of redundant servers and had the client retry failures up to two times, using a round robin algorithm. That worked very well and tolerated dead servers so well that operations weren't aware one server was down, until they took the one good server down for maintenance! :-)