java IV for quant #ANZ

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()


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s