The first server call hangs if the number of deployed modules is within certain value ranges.
I have a problem calling a server function. It is always only the first call of a client.
This call hangs endlessly. This behavior depends on the number of deployed modules on the server. I already did an investigation and found the following behavior in the class 'EJBClientChannel.java'.
- File EJBClient Channel
case Protocol.MODULE_AVAILABLE: {
int count = StreamUtils.readPackedSignedInt32(message);
final NodeInformation nodeInformation = discoveredNodeRegistry.getNodeInformation(getChannel().getConnection().getRemoteEndpointName());
final EJBModuleIdentifier[] moduleList = new EJBModuleIdentifier[count];
for (int i = 0; i < count; i ++) {
final String appName = message.readUTF();
final String moduleName = message.readUTF();
final String distinctName = message.readUTF();
final EJBModuleIdentifier moduleIdentifier = new EJBModuleIdentifier(appName, moduleName, distinctName);
moduleList[i] = moduleIdentifier;
Logs.INVOCATION.debugf("Received MODULE_AVAILABLE(%x) message for module %s", msg, moduleIdentifier);
}
nodeInformation.addModules(this, moduleList);
finishPart(0b01);
break;
}
The content of variable ‚count‘ marked yello is ‘65492’.
I think this value should contain the number of all deployed modules. In this situation I have deployed 29 EAR files with a total of 84 modules. The correct value for the variable 'count' is therefore 84. When examining the method StreamUtils.readPackedSignedInt32(message) the following behavior is present.
01 public static int readPackedSignedInt32(InputStream is) throws IOException {
02 int t;
03 int res;
04 res = readInt8(is);
05 t = res & 0b0111_1111;
06 if (allAreSet(t, 0b0100_0000)) {
07 // sign-extend first 6 bits
08 t |= 0b1111_1111_1100_0000;
09 }
10 if (allAreSet(res, 0b1000_0000)) {
11 do {
12 res = readInt8(is);
13 t = t << 7 | res & 0b0111_1111;
14 } while (allAreSet(res, 0b1000_0000));
15 }
16 return t;
17 }
The result of line 04 in variable ‘res’ is 84. The statement in line 05 does not change the result.
But the method ‘allAreSet(t, 0b0100_0000)’ in line 06 results ‘true’ so that the statement in line 08 sets the wrong result 65492’.
The Method ‘readInt8’ reads the next byte of data from the input stream. The value byte is returned as an integer in the range 0 to 255. In my case, the content of the first byte is b01010100 (d84).
The method ‘allAreSet’ checks, if is set the bit b01000000 (d64) and returns true for value d84. The comment in line thereafter suggest for me that should check the sign flag of read value? But then the method call in line 06 should be equivalent to line 14: ‘allAreSet(res, 0b1000_0000)’?
It may be that the other method
int count = StreamUtils.readPackedUnsignedInt32(message);
should actually be used. This method checks the value in the described way.
But the most important thing is surely the place in the code that writes this value into the stream. But I didn't find this place.
I'm not a developer for the WILDFLY. Can someone forward this report to a developer who can investigate and fix this bug?
