Docker containers, briefly is not too shallow, and not too deep. Free of marketing propaganda.

  • containers are standard Linux processes running a shared kernel, not isolated kernels

Nsdq onsite IV #emerging Nsdq architecture

Q: Java NonBlocking IO?
%%A: one thread monitoring multiple sockets

Q: many simple Objects with complex relationships/interactions vs one (or very few) huge complex object?

Q: thread Futures? Any comments?

–some of my findings

  • microservices and containers are important
  • According to the system architect (last interviewer), the new framework uses one dedicated instance of matching engine serving a single symbol such as AAPL.
  • the new java framework only supports a few smaller exchanges initially, but is designed to roll out to more “exchanges” esp. those to be installed on client sites (like CSP). It is (theoretically) designed to be capable enough to implement the main stock exchange.
  • is Mostly java + javascript (Amber, react) with small amount of c++
  • the new java framework was deliberately designed to operate in single-threaded mode, despite oppositions. Therefore, multiple “clients” calling the same library concurrently would be unsafe.
  • java8
  • noSQL is adopted in addition to PostgreSQL, but the principal architect is less concerned about data store, which is only used in individual components

horror story: java app adopting protobuf #json says

Somebody added protobuf (because it was “faster”). The only thing faster is RTT because of of smaller payload, and that can be fixed with gzipped JSON.

The part that is distasteful to me is the relative work to maintain protobuf (compared to JSON). I use java so we use Jackson object mapping for JSON. Adding to a response means adding a field to a POJO.

In contrast, for protobuf I have to modify the .proto file, then update the serialization and deserialization logic which moves the data in/out of the protocol buffers and into POJOs. It has happened more than once that a release has happened where someone added a field and forgot to put in either the serialization or deserialization code for the protocol buffers.

java9 embrac`cloud

I feel the most strategic changes in java9 are about cloud, such as

  • MSA,
  • Docker container
  • memory footprint reduction is a 2016 article

When cloud computing becomes an even bigger driver than it is today, some legacy technologies will gain mind-share while others will lose mind-share. Java 9 team wants to be a winner.

reactive java #learning notes

After a 5-minute glance, I feel this is yet another (one of a group) jxee add-on package. Not sure about its shelf-life.

There are many jargon terms in, or related to, this concept. Presumably too many (and intimidating) to a new comer. is a 2016 Spring article. is a 2016 tutorial to RxJava library.

java ecosystem==jxee+tools+..

This classification helps me organize my java learning, but let’s not spend too much time on this imprecise concept —

So-called “java ecosystem” is anything outside the “core java” stack and include jxee plus ..

  • GC, JIT
  • JNI
  • swing, AWT
  • ajax integration
  • protobuf/json
  • tools: eclipse, Maven, CI tools,
  • tools: JDK bundled tools like jhat, visualvm


idle timer inside app server engines

I just realized idle timers are often “passive”. You may imagine a separate thread performing periodic polling to detect idlers[1]. Well, not common.

Idle Timer is just a “state” added to the “decoratee”. When the decoratee becomes idle, that time is saved in that state field. When a “Request” is received from a client Call from any thread, the state is checked. If idle time has been too long, we kill that decoratee or mark it as obsolete

See P189 [[Weblogic]]

[1] Heart beat checker is that way.

cluster admin server

In Weblogic (perhaps similar elsewhere), a cluster needs an admin server that’s not one of the cluster nodes.
j4: single point to deploy application, but without admin server, we can have similar convenience?
j4: watch tower to monitor the nodes, but without it, we can monitor them from another place?
j4: single location to store node-configuration

Java design: EJB home factory

Justification: InitialContext instantiation is expensive. Use a singleton

Justification: Home Look-up is usually vendor-specific. Centralize and HIDE the vendor-specific code in a single class, instead of repeating it in every process requiring home look-up

Justification: caching