Seeing a problem adding two numbers together (or I've lost my mind)

Question

I have a resource adapter that provides support for an implementation of the (RDP) Reliable Datagram Protocol (RFC 908/1151) that I wrote. I'm having a problem when this is deployed to a SunFire V480 with 4 CPUs running Glassfish 9.1u2 with JDK 1.6.0_05.
Basically what I am seeing is that when I add 1 to a number sometimes it works and sometimes it does not. So I am losing my mind and I am hoping someone here can help me see the errors in my ways.
The protocol uses sequence numbers similar to TCP. So in my code, when I receive a RDP message it need to check to see that the sequence number matches what is expected. Basically an instance of a class that represents a connection maintains the last sequence number seen and the message coming in had better have this sequence number plus 1.
Here is the code that I'm having a problem with:
+if (__LOGPROTO.isLoggable(Level.FINER)) {+
__LOGPROTO.finer("receiveMessage inmsg.seq = " inmsg.getSequenceNumber() + " __rcvcur = " + __rcvcur + " SEQ_PLUS = " + SEQ_PLUS(__rcvcur, 1) + "this = " + this);+
+}+
+if (inmsg.getSequenceNumber() == SEQ_PLUS(__rcvcur, 1)) {+
+if (inmsg.getDataLength() > 0) {+
+// Save the data+
ackMsg = new RDPAckMessage(inmsg);
__rcvdList.add(ackMsg);
+if (__LOGPROTO.isLoggable(Level.FINER)) {+
__LOGPROTO.finer("receiveMessage message queued to user " this);+
+}+
notifyReceivable = true;
+// Signal that there is data available+
__signal.setValue(true);
+}+
__rcvcur = inmsg.getSequenceNumber();
+// Now see if we have any out of order segments that can+
+// be queued to the user+
for (i = 0; i < __rcvrcvdseqno.length; i+) {+
+if (__rcvrcvdseqno != null) {+
if (__rcvrcvdseqno != null && SEQ_EQ(__rcvrcvdseqno.getSequenceNumber(),
+SEQ_PLUS(__rcvcur, 1))) {+
+__rcvcur = __rcvrcvdseqno] 0) {+
+// Move over to the received list+
ackMsg = new RDPAckMessage(__rcvrcvdseqno);
+if (__LOGPROTO.isLoggable(Level.FINER)) {+
__LOGPROTO.finer("receiveMessage ood message queued to user " this);+
+}+
__rcvdList.add(ackMsg);
notifyReceivable = true;
+// Signal that there is data available+
__signal.setValue(true);
+}+
__rcvrcvdseqno = null;
+}+
+}+
+}+
+} else {+
+if (__LOGPROTO.isLoggable(Level.FINER)) {+
__LOGPROTO.finer("xxx receiveMessage inmsg.seq = " inmsg.getSequenceNumber() + " __rcvcur = " + __rcvcur + " SEQ_PLUS = " + SEQ_PLUS(__rcvcur, 1) + "this = " + this);+
+}+
I have a couple of log messages that I put in to help try to figure out what in the heck is going on. The first prints out the message sequence number, the last sequence number that was known (__rcvcur), and the result of a method called SEQ_PLUS which passes in "__rcvcur" and '1".
Here is the SEQ_PLUS code:
+private long SEQ_PLUS(+
+long x,+
+long y) {+
+long z = (x + y) % 0x100000000L;+
+return z;+
+}+
Basically what I am seeing is that SEQ_PLUS is correctly adding 1 to "__rcvcur" on one call and then not adding 1 in the next.
Here is the log messages that occur. Note that "this" is the same in all of the log messages, that the thread is the same in all log messages, but in one instance SEQ_PLUS works and another it does not.
+[#|2008-09-23T11:04:49.580-0400|FINER|sun-appserver9.1|com.canoga.lib.io.rdp.RDPConnection.msg|_ThreadID=30;_ThreadName=RDPConnectionEngineUDP;ClassName=com.can+
+oga.java.io.rdp.RDPConnection;MethodName=receiveMessage;_RequestID=e6876cf2-0fb9-4de3-938a-484eee9a2b7a;|receving msg[<ACK> from=1024 to=1787 datalen=5 seq=16839 ack=1355376372] by RDPConnection(com.canoga.java.io.rdp.RDPConnection@125f069):/172.16.142.16|#]+
+[#|2008-09-23T11:04:49.581-0400|FINER|sun-appserver9.1|com.canoga.lib.io.rdp.RDPConnection.proto|_ThreadID=30;_ThreadName=RDPConnectionEngineUDP;ClassName=com.c+
+anoga.java.io.rdp.RDPConnection;MethodName=receiveMessage;_RequestID=e6876cf2-0fb9-4de3-938a-484eee9a2b7a;|receiveMessage inmsg.seq = 16839 __rcvcur = 16838 SEQ_PLUS = 16839this = RDPConnection(com.canoga.java.io.rdp.RDPConnection@125f069):/172.16.142.16|#]+
+[#|2008-09-23T11:04:49.581-0400|FINER|sun-appserver9.1|com.canoga.lib.io.rdp.RDPConnection.proto|_ThreadID=30;_ThreadName=RDPConnectionEngineUDP;ClassName=com.c+
+anoga.java.io.rdp.RDPConnection;MethodName=receiveMessage;_RequestID=e6876cf2-0fb9-4de3-938a-484eee9a2b7a;|xxx receiveMessage inmsg.seq = 16839 __rcvcur = 16838 SEQ_PLUS = 16838this = RDPConnection(com.canoga.java.io.rdp.RDPConnection@125f069):/172.16.142.16|#]+
I am at a loss as to how this could occur. I'm hoping some bright mind can see what I cannot.
Any help will be greatly appreciated.
Brett

Answer 1

Actually the nested code in the follow up is a SCCE:
                            if (__LOGPROTO.isLoggable(Level.FINER)) {
                                __LOGPROTO.finer("xxx receiveMessage inmsg.seq = " + inmsg.getSequenceNumber() + " __rcvcur = " + __rcvcur + " SEQ_PLUS = " + SEQ_PLUS(__rcvcur, 1L) + "this = " + this);
                                long x = __rcvcur;
                                long y = 1;
                                long z = (x + y) % 0x100000000L;
                                __LOGPROTO.finer("xxx x is " + x + " y is " + y + " z is " + z);
                            }There is nothing in this snippet that should allow "y" to be anything other than the value '1" which it is initialized to, no matter how many threads, cpu's, etc there may be since "x, y, and z" are stack local variables and "y' is never assigned to after it is initialized. The output of the log message shows however that sometimes it is different:
[#|2008-09-23T12:15:38.505-0400|FINER|sun-appserver9.1|com.canoga.lib.io.rdp.RDPConnection.proto|_ThreadID=28;_ThreadName=RDPConnectionEngineUDP;ClassName=com.c
anoga.java.io.rdp.RDPConnection;MethodName=receiveMessage;_RequestID=77189b23-d5ff-49c3-8194-662f468bbe66;|xxx x is 16838   is 4294967296 z is 16838|#]This code is within a very large Java EE application running under the Glassfish application server. The problem manifests itself about
about 1 of every 4 starts of the application server and I have only seen it occur on Solaris on my V480 server.
So if someone can explain how "y" becomes "4294967296" I would very thankful.