rparker wrote:We've recently run into this issue. What is the current state of the client dll with regards to this error?

bump

This post was very old but the only one I found on JRockit. Curious if you ever did your Solaris benchmark.

you still don't support using JRockit?

thanks for the support - helps a great deal

As I study my wireshark throughput I notice that the aggregation always happens on a TCP Retransmission - sometimes aggregating 10 or more messages in one packet.

It looks to me that every once in a while the socket is not properly sending the messages individually and instead packing many messages (up to four so far) into one tcp packet.

So - the client is definitely misbehaving but I'm not sure I can do anything in my code to fix it - I think it's an ...

Each Stress App is handling roughly 1.2 Mbs out and 1 Mbs in.

I am getting some strange messages occasionally -

Using wireshark I traced a set of messages coming from a Stress app running just 2 clients. (this is while I have 1500 clients already running on other machines)

Normal Message from ...

Dropped incoming messages are simply caused by the size of the message, in fact the server discards any message whose length is greater than the size specified in the <MaxMsgLen> setting (config.xml)

right - I have it set to 4kb and the total message size for each message is only 100 or so bytes ...

in case it matters I'm running the server using the wrapper.

it also might be worth mentioning that I'm calling handleInternalRequest on each room xt every 60ms from a game manager class instanced from the zone ext, as a method to call an update tik that sends the outgoing message.

I actually ...

I'm using ver 1.6.5.01 - linux 64 bit server jvm assigned 500 mb of heap - running on a 2.6ghz dual core with plenty of ram.

(the production machine will be substantially more powerful - this machine is for benchmarking and testing the game under load)

The config I'm using

<OutQueueThreads>2 ...

The actual trace output is

[ WARNING ] > Read queue under heavy load (121 msgs)

Is this warning referring to the Incoming queue?

Nope, gameRooms are necessary to group players into separate logic areas of the server. So this is required.

Thats kinda what I thought.

you avoid instantiating all those copies of the same game logic

Is the concern here related to memory or performance?

Great feedback - Thanks!

I'm definitely looking in to the ExecutorService and thread pools. I'm a bit new to Java so I'm handling a learning curve on that as well here.

You might also consider to keep the game logic at Zone Level and govern each game for that Zone in a central place.

This ...

Thanks Lapo,

Ram is no problem and I am using Java so we should be ok there.

If these 10K rooms handle different games it would make sense to have each game played in a different Zone.

Each room will handle the exact same game and as a matter of fact we will likely use more than one server ...

If I use a server instance to run as many of the same game as it can handle.
Lets say for argument sake that each server can handle 20k users and the games are 2 player meaning I'll be running 10k rooms...

Does it matter if all 10k rooms run in the same zone or is it better to break up into many ...