Anomalous red5 server response after client shared object request

[GoogleCodeExporter]

What steps will reproduce the problem?

public class RTMPClientTelepresencia00 extends RTMPClient ... {
synchronized public void resultReceived(IPendingServiceCall call) {
    Object result = call.getResult();
    if (result instanceof ObjectMap) {
        obj = getSharedObject("mySOString", false);
        iconn = this.getConnection();
        obj.connect(iconn);
        obj.addSharedObjectListener(this);
    }
}

public void onSharedObjectClear(ISharedObjectBase so) {
    obj.beginUpdate(iconn);
    obj.setAttribute("AAAA", "BBBB");
    obj.endUpdate();
}

public void onSharedObjectUpdate(ISharedObjectBase so, String key, Object 
value) {
    System.out.println("onSharedObjectUpdate: key = " + key + "value = " + value.toString());
}

What is the expected output? What do you see instead?

I think I should expect a CLIENT_UPDATE_DATA response from the server like 
BaseRTMPClientHandler - Received SO request: SharedObjectMessage: mySOString { 
SOEvent(CLIENT_UPDATE_DATA, null, {AAAA=BBBB}) }

Instead, I get
BaseRTMPClientHandler - Received SO request: SharedObjectMessage: mySOString { 
SOEvent(CLIENT_UPDATE_ATTRIBUTE, AAAA, null) } 

Which triggers an exception:
20:55:51.619 [NioProcessor-2] ERROR o.r.server.net.rtmp.BaseRTMPHandler - 
Exception
java.lang.NullPointerException
    at java.util.concurrent.ConcurrentHashMap.put(Unknown Source) [na:1.6.0_24]
    at org.red5.server.so.ClientSharedObject.dispatchEvent(ClientSharedObject.java) [bin/:na]

Because of the invocation of

case CLIENT_UPDATE_ATTRIBUTE:
    attributes.put(event.getKey(), event.getValue());

With .getValue() being null.

An identical response comes from Wowza 2.2.3, so I guess I'm having the problem 
when encoding the client shared object.

What version of the product are you using? On what operating system?
SVN checkout r4204 Windows 7

Please provide any additional information below.

Encoded RTMP packet:

43 00 00 00 00 00 2A 13 00 0A 6D 79 53 4F 53 74 72 69 6E 67 00 00 00
01 00 00 00 00 00 00 00 00 03 00 00 00 0D 00 04 41 41 41 41 02 00 04
42 42 42 42

Decoded RTMP packet:

43 00 00 00 00 00 23 13 00 0A 6D 79 53 4F 53 74 72 69 6E 67 00 00 00
02 00 00 00 00 00 00 00 00 05 00 00 00 06 00 04 41 41 41 41 (note 42 42 42 42 
missing).

Expanded source code:

public class RTMPClientTelepresencia00 extends RTMPClient implements
IPendingServiceCallback, ISharedObjectListener {

       private IClientSharedObject obj;
       private IConnection iconn;

       public RTMPClientTelepresencia00() {
               this.connect("localhost", 1935, "basicSO", this);
       }

       synchronized public void resultReceived(IPendingServiceCall call) {
               Object result = call.getResult();
               if (result instanceof ObjectMap) {
                       obj = getSharedObject("mySOString", false);
                       iconn = this.getConnection();
                       obj.connect(iconn);
                       obj.addSharedObjectListener(this);
               }
       }

       public void onSharedObjectClear(ISharedObjectBase so) {
               obj.beginUpdate(iconn);
               obj.setAttribute("AAAA", "BBBB");
               obj.endUpdate();
   }

public void onSharedObjectUpdate(ISharedObjectBase so, String key, Object 
value) {
    System.out.println("onSharedObjectUpdate: key = " + key + "value = " + value.toString());
}

Original issue reported on code.google.com by juan...@gmail.com on 25 Mar 2011 at 3:30

[GoogleCodeExporter]

Original comment by mondain on 24 Jul 2011 at 3:57

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by mondain on 20 Oct 2011 at 5:29

• Added labels: Component-RTMPClient

[GoogleCodeExporter]

Original comment by mondain on 24 Oct 2011 at 4:45

• Added labels: Component-SharedObjects

[GoogleCodeExporter]

The response is sent correctly by Red5. The client requests changing the 
property "AAAA" to value "BBBB".
Red5 confirms this change by sending CLIENT_UPDATE_ATTRIBUTE to this client 
(which already knows the new value to set) and sending CLIENT_UPDATE_DATA to 
all other clients (that don't know about the new value yet).

Original comment by joachim.bauch@gmail.com on 11 Jan 2012 at 2:37

[GoogleCodeExporter]

Fixed / verified by Joachim

Original comment by mondain on 15 Jan 2012 at 5:07

• Changed state: Fixed