Hmm, ok. It's true that down the line the remote events might morph into more
specialised DSL-based remote event filter/conversion.
I just wished the naming would have been a bit more representative.
Ideally, the filter/converter classes used for remote events should have lived
in a remote jar
A similar issue was reported recently in JIRA, but where the cause was long
GCs.
I'll be adding a bit of safety to deal with these situations.
The reason this happens is cos the existing Java Hot Rod client is based around
sync TCP communications. A true async client would make this a lot
Should it be morphed into a FAQ?
On 03 Mar 2015, at 16:23, Galder Zamarreño gal...@redhat.com wrote:
Hmm, ok. It's true that down the line the remote events might morph into more
specialised DSL-based remote event filter/conversion.
I just wished the naming would have been a bit more
