...
- Xbuf2 stores field data off-heap. This can result in more complexities in the following areas
- Troubleshooting issues
- Monitoring memory utilization
- Performing capacity planning particularly related to memory utilization.
- Xbuf2 generated classes are larger.
Known Limitations:
- Not currently supported for State Replication applications
- Not currently supported for mix OS type deployments e.g. sender on Windows and receiver on Linux or vice versa
- Does not support the following field types
- UUID
- UUID[]
- Currency
- Currency[]
...
- An application may not hold onto an XBuf/Xbuf2 encoded message beyond the scope of a message handler.
- An application may not hold onto an XString , or Embedded Entity type or embedded entity type from a message beyond the scope of a message handler because these objects are pooled along with the message and will be reset once the message is returned to its pool. See Zero Garbage Nested Entities for detailed usage, but the general rule of thumb is to copy any entity that needs to be retained by applications state, or to use the more advanced 'take' apis. Note that 'take' is not supported for String fields as string fields are not pooled for Xbuf messages.
- Setting an XString or Embedded Entity field or embedded entity field on a message transfers ownership to the message. If the application wants to retain the entity is application state, then it should copy it into a new entity or use the more advanced 'lend' apis. See Zero Garbage Nested Entities for more details.
- An application may not mutate a returned array type from a message and should not hold onto to the array beyond the duration of a message handler. See Zero Garbage Array Accessors for more details.