The rpc parameter has DirectByteBuffer, causing the server jvm to crash

[greatle]

• SOFARPC version: 6.5.6，其他版本也同样
• JVM version : oracle jdk1.8

• OS version : windows10

  1. 定义一个简单测试接口，其中一个方法中有参数Bytebuffer类型 public interface TestService { void addParams(String name, ByteBuffer buffer); .... }
  2. 简单实现一个服务，启动该服务端： ServerConfig serverConfig = new ServerConfig() .setProtocol("bolt") .setPort(9697) .setDaemon(false); ProviderConfig providerConfig = new ProviderConfig() .setInterfaceId(TestService.class.getName()) .setRef(new TestServiceImpl()) .setServer(serverConfig); providerConfig.export();

  3. 实现一个简单客户端，直连服务端，调用接口 ConsumerConfig consumerConfig = new ConsumerConfig() .setInterfaceId(TestService.class.getName()) .setProtocol("bolt") .setDirectUrl("bolt://127.0.0.1:9697"); TestService testService = consumerConfig.refer();

     ByteBuffer bb = ByteBuffer.allocateDirect(100); // -------- bb.putInt(1000); bb.flip(); testService.addParams("test", bb);

     调用testService.addParams("test", bb) 后，直接导致服务端的JVM崩溃退出。如果ByteBuffer.allocateDirect(100)替换为ByteBuffer.allocate(100)没有问题。

[sofastack-bot[bot]]

Hi @greatle, we detect non-English characters in the issue. This comment is an auto translation by @sofastack-robot to help other users to understand this issue.

We encourage you to describe your issue in English which is more friendly to other users.

-SOFARPC version: 6.5.6, other versions are the same-JVM version (eg java -version): oracle jdb1.8-OS version (eguname -a): windows10 1. Define a simple test interface, where A method has the parameter Bytebuffer type public interface TestService {void addParams (String name, ByteBuffer buffer); ....} 2. Simply implement a service and start the server: ServerConfig serverConfig = new ServerConfig () .setProtocol ("bolt ") .setPort (9697) .setDaemon (false); ProviderConfig providerConfig = new ProviderConfig () .setInterfaceId (TestService.class.getName ()) .setRef (new TestServiceImpl ()) .setServer (serverConfig); providerConfig.export (); 3. Implement a simple client, directly connect to the server, call interface ConsumerConfig consumerConfig = new ConsumerConfig () .setInterfaceId (TestService.class.getName ()) .setProtocol ("bolt") .setDirectUrl ("bolt: //127.0.0.1: 9697"); TestService testService = consumerConfig.refer (); ByteBuffer bb = ByteBuffer. allocateDirect (100); // -------- bb.putInt (1000); bb.flip (); testService.addParams ("test", bb); call testService.addParams ("test", bb) After that, it directly causes the server-side JVM to crash and exit. There is no problem if ByteBuffer.allocateDirect (100) is replaced with ByteBuffer.allocate (100).

[leizhiyuan]

rpc 参数不能传递这种 DirectByteBuffer 这种直接内存，底层对象的序列化，hessian 应该处理不了解的，更推荐的是pojo类型的对象。

HeapByteBuffer 这种事heap的。应该是没问题的。也不建议

[greatle]

是的，一般rpc的时候都会传pojo类或Serializer类，但为防止误用导致崩溃，能够在调用的时候直接抛出错误可能更友好些.

[leizhiyuan]

是的，一般rpc的时候都会传pojo类或Serializer类，但为防止误用导致崩溃，能够在调用的时候直接抛出错误可能更友好些.

这个应该是序列化没问题，但是反序列化的时候报错。能想到的一种办法就是利用现在hessian中的黑名单能力，在扩展一个。将一些已知的类做限制。

[greatle]

这个应该是序列化没问题，但是反序列化的时候报错。能想到的一种办法就是利用现在hessian中的黑名单能力，在扩展一个。将一些已知的类做限制。 — 可以在sofa-rpc目录中的serialize_blacklist.txt文件中加入一行java.nio.DirectByteBuffer，就可以在调用的时候限制了

[leizhiyuan]

这个讨论了一下，还是不建议改了，这个能在线下测试出来，就在线下测试出来即可。hessian不支持的类型还是挺多的。。