Throughput II

[allsorts46]

Today was a long and tiring day, which fits in pretty well with the rest of the week. On Wednesday, we ran the new system at work, which went pretty well in the afternoon. When it got to five, we'd normally switch back to the old system for the evening shift, but we'd had no troubles all day, so called Darius to ask if he'd like to run it for the

Comments

[allsorts46]

Indeed, I chose TCP in the first place because having a reliable stream of bytes seemed a good place to start. However, I've not been able to explain what's going on with this particular connection between two stores - all I know is that connection is dropped briefly but frequently, and I've not seen anything yet be able to handle it gracefully. The ISP refuses to do anything about it and we're not able to change, which is a long story, but basically we're stuck with it.

I've implemented logging of every incoming and outgoing message passing through VmspClient (and it's underlying TcpClient), and intend to run the system again tomorrow. If TCP is working like it should, I should expect to see that the outgoing logs on one side of the connection are identical to the incoming logs on the other side, and the reverse. If that is the case, the problem is entirely mine. If they don't match, some data is being sent out and never arriving, and the sender is unaware of it.

Message queueing was how I was planning to redesign the connection classes. I've already altered the server-side classes to dump incoming messages into a queue, which are then processed on another thread, and the responses placed into an outgoing queue to be send out. It seems to have helped a little, so I intend to do the same on the client side, but really I want to rewrite the lot with this design in mind from the start.

I've looked briefly at remoting, but I don't think that's what I want here. My objects are transmitted as key/value sets, which was done so that clients could request only the keys of an object that they actually need, rather than having to transmit the entire serialised object every time (some can be large). Missing keys are requested in groups of similar meanings if and when they are requested.

The £0 issue does indeed appear to be caused by two requests to manipulate the same object being processed by the server at the same time, causing unpredictable results.

As for using multiple threads for processing, currently, just for experimentation's sake, I am using the thread pool with a limit of eight worker threads. I'll play around with this to see what works best, but my main concern is treating different clients fairly. The server serves different customers of ours on completely separate accounts, and I need to ensure that one customer sending a lot of (relatively) long-running jobs doesn't cause other customers to suffer due to having to wait. I'm thinking I should maintain request queues per-account, rather than global.

It's all been interesting, anyway, I'm learning. Thanks for the feedback, I was rather surprised to receive it - I had no idea anyone with such interests was reading. Who are you?