mardambey

import java.util.Properties
import kafka.server.KafkaServer
import kafka.server.KafkaConfig
import kafka.producer.ProducerConfig
import kafka.producer.Producer
import kafka.message.Message
import kafka.producer.ProducerData
import kafka.consumer.ConsumerConfig
import kafka.consumer.Consumer
import kafka.utils.Utils

rob-murray

// create file:
sudo vim /usr/share/applications/intellij.desktop

// add the following
[Desktop Entry]
Version=13.0
Type=Application
Terminal=false
Icon[en_US]=/home/rob/.intellij-13/bin/idea.png
Name[en_US]=IntelliJ

acolyer

Internet Scale Services Checklist

A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."

• http://mvdirona.com/jrh/talksandpapers/jamesrh_lisa.pdf

Basic tenets

• Does the design expect failures to happen regularly and handle them gracefully?
• Have we kept things as simple as possible?

thomasdarimont

Dump loaded classes from another JVM process with Java 9

We will use jrunscript and internal hotspot API to access and export the classfile data. To do that we will use 2 jrunscript processes, a "debuggee" process and a "debugger" jrunscript process. The debugger process will attach to and inspect the debuggee process (internal) via hotspot API. For this example we use the "latest" Java 9 build b41 on OSX.

Motivation for this example was given by the fact that the latest JDK 9 release b41 doesn't ship an rt.jar anymore. The content from rt.jar was now moved to a new platform specific format with the extension .jimage in the JDK_HOME/lib/modules.

You can find more information about the new packaging in Java 9 in Mark Reinholds blogpost: http://mreinhold.org/blog/jigsaw-modular-images

thomasdarimont

We use Java 9 since it's new and already includes sa-jdi.jar in classpath :) Note that the debugee JVM dosen't need to be Java 9.

tom@gauss ~/dev/repos/thomasdarimont/playground/tmp $ java -version
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b41)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b41, mixed mode)

ifesdjeen

package introspect;

import net.bytebuddy.instrumentation.method.bytecode.bind.annotation.AllArguments;
import net.bytebuddy.instrumentation.method.bytecode.bind.annotation.Origin;

import java.lang.reflect.Method;

public class LogInterceptor {
  public static void log(@AllArguments Object[] allArguments,
                  @Origin Method method) {

jexp

// running spark on a large single machine
// 6 workers, with 12G RAM each -> 72G total and 8G for the driver -> 80G RAM in total
// the machine has 6 physical CPUs
// the jar contains just AnormCypher.org + Dependencies 
neo@neo:/tmp/spark$ bin/spark-shell --jars ../neo4j/target/scala-2.10/Neo4j-Spark-Demo-assembly-1.0.jar --driver-memory 8G --executor-memory 12G --master local[6]
Welcome to
      ____              __
     / __/__  ___ _____/ /__
    _\ \/ _ \/ _ `/ __/  '_/

codefromthecrypt

Questions come up some times about why things get bad data. It is hard to pin things down, as maybe you can't modify the code, or even know where to look. Here's an example of how to track down what's making bad trace ids in finagle.

Firstly, download and extract byteman so you can use it.

$ (cd /tmp; wget -q http://downloads.jboss.org/byteman/3.0.5/byteman-download-3.0.5-bin.zip; unzip byteman-download-3.0.5-bin.zip)
$ export BYTEMAN_HOME=/tmp/byteman-download-3.0.5/