The vm is currently reserved for async aggregate AE (collocated) endpoints. Async aggregate AE communicates with its colocated delegate AE using java (non-jms) queues to avoid serialization/deserialization of CASes. The vm keyword in the endpoint is used to identify such collocated AEs. Don't remember why vm was chosen to represent these endpoints. This decision was made early in the development of UIMA-AS. Fixing that will require refactoring of the UIMA-AS aggregate code and possibly other components as well. Even if this is fixed, the UIMA-AS client still has to seriallize/deserialize CASes when messaging the service. Not sure if using the vm protocol would reduce the latency assuming this is the main reason for using the AMQ vm transport between the UIMA-AS client and the service.
-jerry On Tue, Nov 3, 2020 at 3:11 PM Richard Eckart de Castilho <r...@apache.org> wrote: > Hi Jerry, > > > On 3. Nov 2020, at 17:52, Jaroslaw Cwiklik <cwik...@apache.org> wrote: > > > > My apologies for a late reply to your question. The UIMA-AS client does > not > > support vm protocol between clients and services. Only tcp and http are > > currently supported as you've noted. You can manage broker persistence > > settings in the broker configuration See > > http://activemq.apache.org/persistence (<broker persistent="false"> > > </broker>) > > is there a particular (technical) reason why the vm protocol is not > supported? > > Would a potential interested contributor be faced with significant trouble > in > trying to add support for it? > > Cheers, > > -- Richard
