synchronization missing

[Anjo Krank]

Hi,

two patches:

- ProcessThread now has a name, which makes debugging a bit easier
In my old version I had the name switched to the the current
process during stepping...
- the register/unregister stuff should be synchronized

Another question: it looks to me as if you might run into problems
when you have a slow client? Wouldn't he keep the other processes from
executing?

Cheers, Anjo

diff --git a/MilGraServer/src/com/milgra/server/ProcessGroup.java b/
MilGraServer/src/com/milgra/server/ProcessGroup.java
index ec03432..63adca9 100644
--- a/MilGraServer/src/com/milgra/server/ProcessGroup.java
+++ b/MilGraServer/src/com/milgra/server/ProcessGroup.java
@@ -76,7 +76,7 @@ public class ProcessGroup
for ( int index = 0 ; index < Library.IOTHREAD ; index
++ )
{

- ProcessThread thread = new ProcessThread( );
+ ProcessThread thread = new ProcessThread(nameX
+ "-" + index);

thread.start( );
threads.add( thread );
diff --git a/MilGraServer/src/com/milgra/server/ProcessThread.java b/
MilGraServer/src/com/milgra/server/ProcessThread.java
index fe2ecf2..ff80efd 100644
--- a/MilGraServer/src/com/milgra/server/ProcessThread.java
+++ b/MilGraServer/src/com/milgra/server/ProcessThread.java
@@ -66,11 +66,12 @@ public class ProcessThread extends Thread

/**
* Creates a new ProcessThread instance
+ * @param string
*/

- public ProcessThread ( )
+ public ProcessThread (String nameX)
{
-
+ super(nameX);
// System.out.println( System.currentTimeMillis() + "
ProcessThread.construct " );

count = 0;

diff --git a/MilGraServer/src/com/milgra/server/Server.java b/
MilGraServer/src/com/milgra/server/Server.java
index f88779a..90296f7 100644
--- a/MilGraServer/src/com/milgra/server/Server.java
+++ b/MilGraServer/src/com/milgra/server/Server.java
@@ -122,12 +122,14 @@ public class Server

public static void registerProcess ( OProcess processX ,
String groupX )
{
-
- // System.out.println( System.currentTimeMillis() + "
Server.registerProcess " + processX + " " + groupX );
+ synchronized (pools) {
+
+ // System.out.println( System.currentTimeMillis() + "
Server.registerProcess " + processX + " " + groupX );
+
+ if ( !pools.containsKey( groupX ) )
pools.put( groupX , new ProcessGroup( groupX ) );
+ pools.get( groupX ).addProcess( processX );
+ }

- if ( !pools.containsKey( groupX ) )
pools.put( groupX , new ProcessGroup( groupX ) );
- pools.get( groupX ).addProcess( processX );
-
}

/**
@@ -138,12 +140,12 @@ public class Server

public static void unregisterProcess ( OProcess processX ,
String groupX )
{
-
- // System.out.println( System.currentTimeMillis() + "
Server.unregisterProcess " + processX + " " + groupX );
-
- if ( !pools.containsKey( groupX ) ) return;
- pools.get( groupX ).removeProcess( processX );
-
+ synchronized (pools) {
+ // System.out.println( System.currentTimeMillis() + "
Server.unregisterProcess " + processX + " " + groupX );
+
+ if ( !pools.containsKey( groupX ) ) return;
+ pools.get( groupX ).removeProcess( processX );
+ }
}

[Anjo Krank]

Yeah, I really think so... you'd just need to start a AMF message, but
then not send any more data. This would block the thread in the
decoding queue (I may be wrong of course).

A way around this would to move the processes off of the Process to
the ProcessGroup, have the ProcessGroup also extend Thread and run the
loop over the processes and checkin/out/create ProcessThreads during
the step loop.

Cheers, Anjo

[Milan Toth]

i don't get it, bandwidth shouldn't effect encoding/decoding since i'm
using non-blocking sockets, and if packets can't come in/go out, i
simply queue them.

[Anjo Krank]

As I said, I may be wrong (and I was actually wrong with the AMF
parser, as this works on an already read byte array).

Still, imagine a slow uplink. It would seem to me that either you need
to block as bytes tickle in or collect the incomplete messages... are
you doing that?

And why aren't you simply using the Executor thread pools and skip
your homegrown stuff? Would seem like less work and you'd have some
bytes free to add a complete AMF parser and stlll stay under 64k :P

Cheers, Anjo

[Milan Toth]

> Still, imagine a slow uplink. It would seem to me that either you need
> to block as bytes tickle in or collect the incomplete messages... are
> you doing that?

Yes, i collect avaliable bytes in a bytebuffer every step, and when a
message is complete, i finalize it and pass it to the clientcontroller/
streamcontroller.

> And why aren't you simply using the Executor thread pools and skip
> your homegrown stuff? Would seem like less work and you'd have some
> bytes free to add a complete AMF parser and stlll stay under 64k :P

because i simply didn't know abut it :) i'll check it

Milan