Win2008 gets rid of an explicit limit. X64 doesn't suffer from it pretty
resources are allocated for the requests. If a system receives large number
The described problem was really neither Outlook's nor Exchange's. It just
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
See below...
On Sat, 5 Dec 2009 09:45:04 -0800, "Alexander Grigoriev"
<alegr@earthlink.net> wrote:
For what it's worth, even microsoft managed (of course) to get it wrong in
their server.sys.
See, for example, KB 297019. When outlook PST files are located on a
remote
server over a slow WAN link, and many users are accessing the files at
once,
the server may run out of paged pool, or hang.
****
It does seem strange. Paged pool is limited only by the size of the
pagefile.sys file for
paging, and that normally expands as needed.
Also, it would be unusual for many users to access a single .pst file; the
article talks
about multiple users accessing multiple .pst files.
It also appears to not be an Outlook problem, but an Exchange problem.
Exchange is one of
those mysterious programs whose purpose is unknown and unknowable; all the
documentation I
can find tells me (a) it is cool and (b) how to install and configure it,
but nobody tells
me why I would ever care about it. I went to several Exchange
presentations at different
PDCs, but nobody would tell me what Exchange did (although they could tell
me in great
detail what various switches did during the install). I've put it in the
same category as
SAP (did you ever see a SAP ad? It tells you that it will make your
business run better,
but never says what the product is or does!)
The article does discuss running out of *non*-paged pool, which is
somewhat more
believable, but since the non-paged-pool limit is very high, it is
unlikely it would
happen in small sites. The article suggests that the problem arises only
for
"enterprise-wide" attempts at the solution, suggesting issues of scale.
Note that it does
not involve a single server, but instead involves using a file server
using
remote-file-access commands; the OP is suggesting using a different model
entirely, a
server *process*. This is quite different than the KB article describes.
****
This tells that most likely, server.sys does NOT limit or throttle total
amount of data pending for transmission, thus, when it gets a lot of
requests at once, it will try to queue excessive amount of data, possibly
exceeding available memory.
****
Note that server.sys is not going to be the program involved in the OP's
problem, and that
the exhaustion of non-paged pool is caused by the kernel, and in
particular, kernel work
items created in response to low-level file requests. The OP is not doing
it this way,
and therefore server.sys does not appear to be involved in the discussion
at all.
joe
****
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:dhrkh5p6tqr1fae6sqrm0rcetdra025r17@4ax.com...
See below...
On Fri, 04 Dec 2009 22:49:52 -0600, TomChapman <TomChapman12@gmail.com>
wrote:
I have written a client/server application set using TCP as the link.
Normally only a few packets are exchanged every minute. One thing the
client does is ask the server for a specific database record. The server
retrieves the record and sends it back to the client. In some odd cases
the client may all-of-a-sudden realize that it needs thousands of these
records.
The obvious method is to send one request wait for the return data and
then send the next request. That would work. However...
I'm thinking I'd get faster results for the client if I tried to stay
ahead by sending requests early so there were a few queued at the server
or in transit.
****
Yes, this sounds like a good idea
****
I don't know the bast way to do this. How do I know when to send a new
request. An individual client does not know what load the server is
under. It may vary.
****
Then the requests will simply wait at the server until it gets around to
them. I don't
see a problem here.
****
I'm thinking I need some kind of counter. What is the best approach
here? How should I tackle this throttling problem.
****
You could limit the number of outstanding requests from any given
client,
but as you point
out, that's a simple counter. But I'd be inclined to a more
laissez-faire
approach (free
market) and just dump out all the requests; if the server is running
slow,
they take
longer to process, but so what? You're going to need them anyway, so
just
queue them up
and let the server deal with the issue.
joe
****
----------
Question 2:
In many of my programs I seem to spend more time handling errors and
what-ifs then I do with nominal situation code. I'm use to thinking
about what-ifs.
So in the case where I am sending thousands of request-for-data
messages. In the perfect world, the server would correctly respond and I
would receive 100% of the responses. But I always worry about what-ifs.
Specifically in this case, what if something goes wrong somewhere and I
never get a response. If I'm queuing multiple requests and using some
kind of counter, the counter might get out-of-wack if a packet
here-or-there was never responded to. How do I handle this situation?
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm