JNI is not thread safe? Suppose we have 10 simultaneous requests from Swing GUI and 10 threads in the java server, each calling the same JNI quant function. What’s the threading scenario? Will there be 10 independent JNI calls that don’t interfere with each other? I feel in the c++ codebase the 10 threads may clash.
Q: What RMI reliability issues and solutions did you see (you said JMS is rather reliable)?
%%A: In my apps, there are few reliability issues observed — because it’s production, but the request volume is probably much lower than the JMS requests. Once a while, there are error messages in the log, possibly related to RMI calls.
Q: For swing-server communication, when would you use RMI and when JMS?
%%A: JMS for large volume, request queuing.
%%A: JMS for request forwarding.
%%A: JMS is flexible for asynchronous request/reply
%%A: JMS requires queue/topic set-up in the broker (except temporary queues) — extra admin effort. Tibrv is clean and nice. RMI is also simpler.
%%A: RMI is quick and dirty (inefficient). Requestor blocks briefly to get a quick response.
%%A: if you must get a response before proceeding, then RMI or web service is better than MOM
What’s the memory organization in an JNI process?
%%A: java+C stack + java heap + c heap + c globals
Q: Between sync and async, What’s the difference in your application code?
%%A: sender app is indifferent. Receiver uses sync receive() call or onMessage()