young, productive developers (GS

Regarding my young GS colleague … He learns the production codebase very fast, so

* he can understand, in-depth, how and where all those complicated logic is implemented in production system
* he can understand what users mean, which is usually condensed in very terse emails, or quick phone calls
* he can quickly come up with quick solutions
* he knows what test scenarios are extremely unlikely so we need not handle them or test them
* he is faster navigating the code base from java to perl/shell scripts, to stored proc and big queries, to autosys and javascript, where business logic lives.

(I was weaker on all these aspects, for a long time.)

He’s more confident fixing existing codebase than architecting a rewrite. Limited experience. In this aspect, employer would see limited value in him.

gemfire cache listener runs in updater-thread

By default, CacheListener methods run on the cache updater thread.  You can easily verify it.

 

            final CacheListener listener = new CacheListenerAdapter() {

                  @Override

                  public void afterCreate(EntryEvent event) {

                        log.info(“afterCreate({})”, event);

                        count.incrementAndGet();

                  }

            };

           

            final AttributesMutator mutator = region.getAttributesMutator();

            mutator.addCacheListener(listener);

            try {

                  final TestBean bean = new TestBean();

                  region.put(“testAddCacheListener”, bean);

how a spring app stays alive after main() method returns

In fact, the main() method doesn’t return — prevented from returning. Prevented because main() calls await() of this class below.


protected static class ContextClosedCompleteListener implements ApplicationListener {
private final CountDownLatch countDownLatch = new CountDownLatch(1);
public ContextClosedCompleteListener(ConfigurableApplicationContext applicationContext) {
applicationContext.addApplicationListener(this);
}

// required by spring's ApplicationListener
public void onApplicationEvent(ContextClosedCompleteEvent event) {
log.info("Received context closed complete event");
countDownLatch.countDown();
}

// called from main()
public void await() throws InterruptedException {
countDownLatch.await();
}
}

c# q(NEW) keyword – 3 meanings

I’m sure there are excellent online articles, but here’s my own learning note.

Java “new” always hits Heap, period. Simple and clean.

C++ has array-new, placement-new, and class-specific-new. C++ “new” almost always hits the heap except
– except placement-new
– except you can customize op-new for your class to hit your allocator.

C# “new” doesn’t always mean Heap. The code “new MyStruct” usually hits the stack rather than the heap. See P55[[c#precisely]] for a nice diagram.

C# actually gives 3 unrelated (mildly confusion) meanings to the “new” keyword. One is the Java meaning. The 2nd meaning is “hide base type Member” and can apply to
* virtual methods — Most confusing
* non-virtual methods
* fields
* nested classes/interfaces
* events??

“Type” can be a base interface.

3rd meaning – select-new creates an instance of an anonymous type [3]. See http://www.dotnetperls.com/select-new.  http://stackoverflow.com/questions/2263242/select-new-keyword-combination is a summary of select-new

[3] java also let’s you create an instance of an anonymous type but you need to specify the supertype.

max throughput vs max concurrency

I now feel this is a a bit too academic. In practice, I feel concurrency is a technique to achieve throughput.

“max concurrency” is a system feature and probably means “full exploitation of processor and threading capacity”. I know a single SUN processor can have 4 cores and 32 concurrent kernel threads. In such a system, it’s also possible to create user-level threads so total concurrent threads can far exceed 32. I would think thousands are possible.

“max throughput” is a tangible benefit. I think it’s measured by the max number of completed requests per second. The highest throughput is usually achieved in latency-insensitive batch systems rather than synchronous or asynchronous request/response. The fastest way to transfer billions of terabytes of data is to load flash drives on trucks and ship to the receiving site – batch mode.

Max throughput requires finding out bottlenecks. Throughput of a given system is the throughput of the “narrowest” or “slowest” link on the critical path. Adding concurrency to the bottleneck spots (not other spots) improves throughput. For a realistic system, people would buy the max amount of memory they can afford to avoid hitting disk, put in a lot of processors, and somehow multiplex I/O. In low-latency systems, network I/O is often the biggest latency contributor. People use java NIO and exchange collocation, among other things.

Other concurrency techniques include partitioned table, parallel query, disk array, grid and cloud computing.

By “narrowest” I mean the high-way. The more lanes, the better the throughput. A 32-thread processor has 32 lanes. Each thread has a capacity limited by clock speed and software synchronization – that’s what I mean by “slowest”.

code tracing ^ performance tuning

In terms of practical value-add, keeping the job, workload management, time for family, keep up with colleagues and avoid falling into bottom quartile…. #1 challenge i see so far is legacy code tracing. How about latency and throughput?

market feed
eq/FX,
google, facebook
clearance

I think most performance optimization work is devoid of domain knowledge. Exceptions include
* high frequency trading
* CEP

know what "nice" solutions work only on paper

We are talking about real technical value-adding, not interviews. Context — non-trivial trading system design. Team of 5 – 20 developers.

If you can get at least one credible [1] dose of non-trivial first-hand experience in pricing / booking / real time mark2market -> real time pnl -> real time VaR / market data feed / execution … then you can give real inputs to design discussions. Real inputs, not the typical speculative inputs from an “armchair quarterback”. In other words, if you have done it, then you can speak from experience. Speculators can’t be sure if their solutions will work. If it’s a top brain, she can be fairly confident, but actual development invariably requires many implementation decision. Even for a genius, It’s impossible to make an educated guess at every juncture and be right every time.

Most of the tools are made by “strangers”. No one can be sure about the hidden limitations esp. at integration time. Some experience is better than no experience.

Here are a small sample of those tools that came to mind. These aren’t trivial tools, so real experience will teach you what to *avoid*. In short, every solutions works on paper, but Speculators don’t know what don’t work.

temp queue
lock free
rv
cache triggers and gemfire updaters
gemfire
camel
large scale rmi
large scale web service
DB-polling as a notification framework

(I have a fundamental bias for time-honored tools like MOM, SQL, RMI..)

[1] need to be a *mainstream* system, not a personal trading system. Each trading system could have quite different requirements, so ideally you want to sample a good variety of, say, pricing engines.

##extend lead over non-trading developers

(context — IV, not performance) When you compete for trading jobs in SG, you must show convincing value-add otherwise why should they pick you rather than some regular java guy in SG with 15 years xp?

— ranked in terms of entry barrier

  1. * c++
  2. * WPF? i think in a growing number of cases, a java guy can help out on the front end
  3. * socket, TCP/IP, FIX
  4. * analytics
  5. * low latency
  6. * distributed cache
  7. * swing — few java guys do swing but swing is fading
  8. * db tuning
  9. * threading,
  10. * java memory management
  11. * MOM — RV, MQ
  12. * biz jargons — they buy it
  13. * serialization
  14. * CEP??