《Gradle user guide》翻译 — 第七章 Java快速开始

发表于 2013-09-21 | 阅读次数

7.1 Java插件 <p> 如我们所了解的，Gradle是一个通用的构建工具。它可以通过你的构建脚本实现几乎任何你想做的事情。不过，作为开箱即用的产品，它不会做任何构建脚本不包含的任务。</p> 大多数的Java项目都跟基础情况很相似：你需要编译你的Java源文件，执行单元测试，并且创建一个包含你的类的JAR包。如果你不需要为每个项目编写这些代码那将很好。幸运的是，你确实不需要去做。Gradle通过插件解决了这个问题。插件是Gradle的扩展，它用某种方式配置了你的项目，通常是添加一些预先配置好的任务去做一些有用的事情。Gradle包含了很多插件，你也可以很方便的编写你自己的插件并与别人共享之。一个这方面的插件就是Java插件。该插件给你项目增加了一些任务，这些任务可以编译你源代码、执行单元测试，并能打包JAR文件。 <p> Java插件基于约定配置的。这意味着该插件对项目很多方面定义了默认值，如，Java源文件的存放位置。如果你在项目里遵循约定，你一般不需要在你构建脚本里做什么事情。如果你在某些情况下不想遵循约定，Gradle也允许你个性化你的项目。事实上，因为是通过插件的方式来支持Java项目，如果你不想要，你甚至都可以完全不用插件来构建你的Java项目。</p> 我们在随后的章节里，在许多样例中深入的覆盖了Java插件、依赖管理和多项目构建等方面。在本章，我们打算给你一个如何使用Java插件构建Java项目的初步认识。</div>

阅读全文 »

《Gradle user guide》原创翻译 — 第六章构建脚本基础

发表于 2013-09-21 | 阅读次数

译者注：从第六章开始翻译，为了个人学习需要，先省略了前面已经了解和不太相关部分。见谅。

6.1 项目和任务

Gradle里的一切都基于两个基本概念：项目和任务。(projects and tasks)。

每个Gradle构建都是由一个或多个项目组成的。项目代表你的软件中可构建的一些组件。具体的含义取决于你实际构建的东西。例如，项目可能代表一个JAR或者一个web工程。它也可能代表一个由其他项目生成的jar包组成的ZIP压缩包。项目不必代表准备构建的东西，它应该代表准备完成的事情，如，把你的应用发布到生成环境中。如果你仍感觉有些模糊也不用担心。Gradle对约定式构建的支持，给出了对项目更明确的定义。

每个项目由一个或多个任务组成。任务代表一些原子化的构建过程中执行的工作。如，编译一些类，创建一个JAR包，生成javadoc，或是发布一些归档到库中。

现在，我们将会关注在一个项目中定义一些简单的任务。在后面的章节，我们将会学习处理多项目以及更多的关于项目和任务的知识。

6.2 Hello world

你通过使用gradle命令来执行Gradle构建。gradle命令在当前路径下查找build.gradle配置文件。我们称这个build.gradle文件为构建脚本，或像我们随后看到的那样，严格的称其为构建配置脚本。构建脚本定义了项目和它的任务。

尝试创建名为build.gradle的构建脚本。
例子6.1 第一个构建脚本

build.gradle

task hello {
    doLast {
        println 'Hello world!'
    }
}}

在命令行中，进入包含脚本的目录然后通过gradle -q hello命令执行构建脚本。

例子6.2 执行构建脚本

gradle -q hello的输出</p> <blockquote> <p> > gradle -q hello
Hello world!
</p> </blockquote> <table cellpadding="0" cellspacing="0"> <tbody> <tr> <td> -q选项做了什么？
用户手册中的大多数例子都是用-q选项执行的。这会屏蔽Gradle’s 日志信息，因此只会显示任务的输出信息。这会使用户手册中的例子的输出简洁一些。如果你不想可以不使用该选项。参见第18章，记录更详细的日志，影响Gradle输出的命令行选项。</td> </tr> </tbody> </table> 这里发生了什么？构建脚本定义了一个单独的称作hello的任务，并且给其增加了一个操作。当你执行gradle hello命令的时候，Gradle执行了hello任务，该任务依次执行你提供的操作。操作是等待执行的包含一些Groovy代码的闭包。

如果你认为这看起来和Ant的目标相似，那么你答对了。Gradle的任务就等于Ant中的目标(target)。不过，如你将要看到的那样，它强大的多。我们使用了与Ant不用的术语，是因为我们觉得任务比目标更贴切。不过，这里术语的使用与Ant产生了冲突，在Ant称命令为任务，如javac或copy。所以，当我们说任务的时候，我们都是指Gradle里的任务，等价于Ant里的目标。如果我们讨论Ant里的任务(Ant命令)，我们会说ant 任务。

译者注：接下来会直接翻译第七章的内容，因为和译者直接相关。是关于构建Java工程的。</div>

阅读全文 »

Mac os下修改path环境变量

发表于 2013-09-20 | 阅读次数

不是什么高级的方法，只是我才刚会而已。记录一下。

修改：/etc/paths文件，跟windows一样增加你想要配置到path下的目录即可。

vim /etc/paths

阅读全文 »

自定义实现log4j的appender

发表于 2013-09-17 | 阅读次数

log4j，应用最广泛的日志框架。其作者后来推出logback，也是好选择。不多说废话。

log4j组件介绍
Log4j主要有三个组件： Logger：负责供客户端代码调用，执行debug(Object msg)、info(Object msg)、warn(Object msg)、error(Object msg)等方法。
Appender：负责日志的输出，Log4j已经实现了多种不同目标的输出方式，可以向文件输出日志、向控制台输出日志、向Socket输出日志等。 Layout：负责日志信息的格式化。

log4j默认提供了很多Appender，如org.apache.log4j.ConsoleAppender，FileAppender等。不过，如果有特殊的需求，就需要自定义实现，比如把日志发送到Flume中。我们的需求正是如此。

自定义一个Appender很简单，只需继承AppenderSkeleton类，并实现几个方法即可。

@Override
     protected void append(LoggingEvent event) {
         System.out.println("OneCoder: " + event.getMessage());
     }

     @Override
     public void close() {
           // TODO Auto-generated method stub
     }

     @Override
     public boolean requiresLayout() {
           // TODO Auto-generated method stub
           return false ;
     }

上述代码的效果就是将原信息再开头加上”OneCoder”。我们想要发送到Flume里，也只需在该方法里添加Flume客户端的相关实现即可。这样你的系统日志就灵活多了。

当然，想要生效你需要修改log4j的配置文件，将appender改为你自己实现的appender即可。

阅读全文 »

计数排序Java实现

发表于 2013-09-12 | 阅读次数

计数排序——线性排序算法《算法导论》8.2

package com.coderli.algorithm.arrayandsort;

/**
 * 《算法导论》8.2 计数排序 线性排序算法<br>
 * 
 * <pre>
 * 计数排序假设<b>n个输入元素的每一个都是介于0到k之间的整数。</b>
 * k为某个整数，k = O(n)时。技术排序的运行事件为&Theta;(n)
 * 
 * 
 * @author OneCoder
 * @date 2013年9月11日 下午8:15:00
 * @website http://www.coderli.com
 */
public class CountSort {

	private static int[] sortArray = new int[] { 2, 5, 3, 0, 2, 3, 0, 3, 4, 1};
	private static int k = 6;

	public static void main(String[] args) {
		int[] countArray = new int[k];
		int[] outArray = new int[sortArray.length];
		// 给元数组中的数字计数
		for (int i = 0; i < sortArray.length; i++) {
			countArray[sortArray[i]] = countArray[sortArray[i]] + 1;
		}
		// 计算元素位置
		for (int j = 1; j < k; j++) {
			countArray[j] = countArray[j] + countArray[j - 1];
		}
		// 排序到输出数组
		for (int h = sortArray.length - 1; h >= 0; h--) {
			outArray[countArray[sortArray[h]] - 1] = sortArray[h];
			countArray[sortArray[h]] = countArray[sortArray[h]] - 1;
		}
		// 打印结果
		for (int n : outArray) {
			System.out.print(n + &quot; &quot;);
		}
	}
}

阅读全文 »

CentOS下 PostgreSQL部署记录

发表于 2013-08-20 | 阅读次数

MySQL License收费的问题越来越现实了。PostgreSQL成了最好的替代方案。

部署环境：CentOS6.3 x64。PostgreSQL版本：9.2.4-1。

CentOS的Develop包模式行可能已经带了PostgreSQL数据库，不过版本较老，这里还是要全新部署一个。官网提供了很多的部署方式，这里笔者选择的是命令行交互的离线安装包的方式，因为可以脱离网络和操作系统UI进行安装，比较贴近生产环境。

离线包下载地址：

http://community.openscg.com/se/postgresql/packages.jsp

下载好对应操作系统的包，赋予执行权限，执行即可完成安装。安装期间会交互的让你设置一些默认的存放目录，如果没有特殊要求，默认回车即可。

安装很快即可完成。

启动数据库

不能使用root用户启动，需要使用安装时新创建的用户，默认为postgres。

bin>postgres -D data

-D 为指定配置文件和数据存放目录。该目录须存在且包含postgres.conf配置文件。按照上面的方式安装后，只要指定为安装目录下的data文件夹即可。

如果不存在，则需要初始化该目录。

>initdb -D 目录

如果需要远程连接访问该数据库，需要修改pg_hba.conf文件，给指定的主机和ip开发访问权限。其实影响访问的还有postgresql.conf中的配置，不过默认是开放了权限的。

启动后可通过

>psql

客户端连接到数据库，查看数据库信息。具体命令可通过help查看。

阅读全文 »

Mac OS下 Redis2.6.14部署记录

发表于 2013-08-17 | 阅读次数

部署一个Redis作为缓存进行验证，记录部署过程。

官网：

http://redis.io/

目前最近稳定版为2.6.14。解压，进入目录。按照README文件的指引进行编译和验证。

在解压后的根目录执行

$>make

执行后，可以通过

$>make test

进行验证,基本看到的就是一堆OK。

编译完成，启动Redis服务。进入src目录。

$>cd src
$>./redis-server

至此，redis服务就启动好了，如果你想把redis相关的命令安装到/usr/local/bin下，可以执行

$>make install

启动后，可以通过客户端命令验证服务是否正常运行。

至此，一个redis服务就部署完成了，如果想通过Java访问可以下载Jedis包，API非常简单。

阅读全文 »

CentOS下 Storm0.8.2 环境搭建记录

发表于 2013-08-12 | 阅读次数

Storm是Twitter开源的一个实时计算框架，它需要依赖Zookeeper，ZeroMQ；同时还需要你的系统环境中有Java和Python。所以整个搭建步骤如下：

1. 搭建Zookeeper集群。
2. 在控制节点机[ Nimbus ]和工作节点机[ Supervisor ]上安装相同的环境（ZeroMQ，JZMQ，Java，Python等）
3. 在控制节点机[ Nimbus ]和工作节点机[ Supervisor ]上安装Storm框架
4. 配置Storm，通过storm.yaml文件
5. 用命令启动Storm(需要分别启动Nimbus、Supervisor、ui)

1. 搭建Zookeeper

由于 storm并不用zookeeper来传递消息。所以zookeeper上的负载是非常低的，单个节点的zookeeper在大多数情况下都已经足够了，因此这里我们搭建单节点zookeeper。
下载最新版3.4.5：http://zookeeper.apache.org/releases.html#download
解压，在conf下增加配置文件zoo.cfg，可参考zoo-sample.cfg的配置修改，主要修改dataDir路径位置

启动zookeeper：

bin/zkServer.sh start

启动后，可通过：

bin/zkCli.sh -server 127.0.0.1:2181

验证启动状况和客户端连接状况

2、搭建ZeroMq2.1.7版：
官方提到，不要安装2.1.0版，如果使用2.1.7版遇到问题，可尝试降级到2.1.4版本。
下载：http://download.zeromq.org/
解压后，在目录中执行：

shell/>./configure

遇到uuid-dev的错误，说明需要安装uuid包：
在ubuntu下安装uuid-dev，在centos上安装：

yum install libuuid-devel.x86_64

然后再执行configure即可。
然后：

make
sudo make install

3、安装JZMQ
下载：https://codeload.github.com/nathanmarz/jzmq/zip/master
解压后执行：

./autogen.sh
./configure
make
sudo make install

./configure时会检查你的JAVA_HOME是否正确，不正确会报错，并提示。

4、安装Storm

下载：https://github.com/nathanmarz/storm
解压，配置storm.yaml配置文件。主要配置：
1) storm.zookeeper.servers: Storm集群使用的Zookeeper集群地址，其格式如下：

storm.zookeeper.servers:
  - "111.222.333.444"
  - "555.666.777.888"

如果Zookeeper集群使用的不是默认端口，那么还需要storm.zookeeper.port选项。
2) storm.local.dir: Nimbus和Supervisor进程用于存储少量状态，如jars、confs等的本地磁盘目录，需要提前创建该目录并给以足够的访问权限。然后在storm.yaml中配置该目录，如：

	storm.local.dir: "/home/admin/storm/workdir"

3) java.library.path: Storm使用的本地库（ZMQ和JZMQ）加载路径，默认为"/usr/local/lib:/opt/local/lib:/usr/lib"，一般来说ZMQ和JZMQ默认安装在/usr/local/lib 下，因此不需要配置即可。
4) nimbus.host: Storm集群Nimbus机器地址，各个Supervisor工作节点需要知道哪个机器是Nimbus，以便下载Topologies的jars、confs等文件，如：
nimbus.host: "111.222.333.444"
5) supervisor.slots.ports: 对于每个Supervisor工作节点，需要配置该工作节点可以运行的worker数量。每个worker占用一个单独的端口用于接收消息，该配置选项即用于定义哪些端口是可被worker使用的。默认情况下，每个节点上可运行4个workers，分别在6700、6701、6702和6703端口，如：

	supervisor.slots.ports:
	    - 6700
	    - 6701
	    - 6702
	    - 6703

启动Storm最后一步，启动Storm的所有后台进程。和Zookeeper一样，Storm也是快速失败（fail-fast)的系统，这样Storm才能在任意时刻被停止，并且当进程重启后被正确地恢复执行。这也是为什么Storm不在进程内保存状态的原因，即使Nimbus或Supervisors被重启，运行中的Topologies不会受到影响。
以下是启动Storm各个后台进程的方式：

1. Nimbus: 在Storm主控节点上运行"bin/storm nimbus >/dev/null 2>&1 &"启动Nimbus后台程序，并放到后台执行；
2. Supervisor: 在Storm各个工作节点上运行"bin/storm supervisor >/dev/null 2>&1 &"启动Supervisor后台程序，并放到后台执行；
3. UI: 在Storm主控节点上运行"bin/storm ui >/dev/null 2>&1 &"启动UI后台程序，并放到后台执行，启动后可以通过http://{nimbus host}:8080观察集群的worker资源使用情况、Topologies的运行状态等信息。

注意事项：

1. Storm后台进程被启动后，将在Storm安装部署目录下的logs/子目录下生成各个进程的日志文件。
2. 经测试，Storm UI必须和Storm Nimbus部署在同一台机器上，否则UI无法正常工作，因为UI进程会检查本机是否存在Nimbus链接。
3. 为了方便使用，可以将bin/storm加入到系统环境变量中。

至此，Storm集群已经部署、配置完毕，可以向集群提交拓扑运行了。
附：Storm的主要依赖：
Apache Zookeeper、ØMQ、JZMQ、Java 6和Python 2.6.6

阅读全文 »

JPPF-log4j远程日志管理

发表于 2013-07-17 | 阅读次数

利用JPPF进行并行计算，计算任务运行在远端节点上，那么如何收集运行在远端的任务日志，用于跟踪和分析呢？

JPPF框架对此也有封装，主要的实现思路是，通过自定义实现一个log4j的appender，对外提供JMX服务。客户端（监控端）实现一个监听器，监听远端日志，这样即可把远端日志采集到本地进行统一的管理。这对于我们收集和管理并行计算实时日志是非常有用的。具体看一下：

在没个执行任务的Node节点，修改log4j的配置，启用jppf提供的JmxAppender：
log4j-node.properties

log4j.appender.JMX=org.jppf.logging.log4j.JmxAppender
log4j.appender.JMX.layout=org.apache.log4j.PatternLayout
log4j.appender.JMX.layout.ConversionPattern=%d [%-5p][%c.%M(%L)]: %m\n

### set log levels - for more verbose logging change &#39;info&#39; to &#39;debug&#39; ###
#log4j.rootLogger=DEBUG, JPPF
log4j.rootLogger=INFO, JPPF, JMX

客户端代码如下：

/**
* @author lihzh
* @alia OneCoder
* @blog http://www.coderli.com
* @date 2013年7月17日 上午10:34:44
*/
public class RemoteLog {
     public static void main(String args[]) throws Exception {
            // get a JMX connection to the node MBean server
           JMXNodeConnectionWrapper jmxNode = new JMXNodeConnectionWrapper("localhost" ,
                     12001);
           jmxNode.connectAndWait(500000L);
            // get a proxy to the MBean
           JmxLogger nodeProxy = jmxNode.getProxy(JmxLogger.DEFAULT_MBEAN_NAME ,
                     JmxLogger. class);
            // use a handback object so we know where the log messages come from
           String source = "node   " + jmxNode.getHost() + ":" + jmxNode.getPort();
            // subbscribe to all notifications from the MBean
           NotificationListener listener = new MyLoggingHandler();
           nodeProxy.addNotificationListener(listener, null, source);
           String source167 = "node   " + jmxNode167.getHost() + ":" + jmxNode167.getPort();
     }
}

public class MyLoggingHandler implements NotificationListener {
            // handle the logging notifications
            public void handleNotification(Notification notification,
                     Object handback) {
                String message = notification.getMessage();
                String toDisplay = handback.toString() + ": " + message;
                System. out.println(toDisplay);
           }
     }

简单介绍下，就是通过ip和端口与需要监听的node节点建立jmx链接，然后讲自己事先的监听处理类MyLoggingHandler实例，注册到nodeProxy上。这样如果node端有日志出现，就会通知到监听端，可以进行自己的分类处理。试验一下，启动JPPF环境和启动监听，运行之前介绍的JPPF任务，可以看到在本地成功打印出任务日志信息,这样，并行计算任务分节点的日志收集处理也就很容易实现了。

阅读全文 »

JPPF并行计算框架类加载机制研究

发表于 2013-07-12 | 阅读次数

不算什么深入的研究，主要是了解下JPPF中类的加载和隔离机制。

JPPF中类的加载采用的是分布式类加载技术。这样既可在Node节点运行在node上并不存在的类。也就是类可以仅在用户的Client端存在。

如图，JPPF的class loader大致分三层。
System class loader是由JVM控制的加载器，用于启动node节点。在大多数JVM中是，该loader是java.net.URLClassloader的实例。
Server class loader是类AbstractJPPFClassloader的实现，提供了远程访问server端classpath中的类和其他资源的功能。该loader在node连接到server端的时候创建，断开连接的时候销毁。其父loader为System class loader。
Client class loader也是AbstractJPPFClassloader类的实现，提供了远程访问一个或多个客户端上的类和资源的功能。该loader在客户端提交任务的时候创建。一个node可能会持有很多client class loader。

JPPF的node节点仅持有一个与Server的连接，该连接被所有的loader共享，这样可以避免并发时潜在的的一致性，同步和冲突等问题。

Java的classloader是先从parent loader开始加载的饿，下图展示了node节点加载类的过程

node节点先从server节点请求class。如果server节点存在class，则直接加载返回。
如果class仅在client端存在，则会先访问server，server无，再通过server定位client，访问client端的class。

在JPPF框架里，每个client都有一个唯一的UUID，用于唯一标识该client。Node节点便可根据此UUID识别出当前classloader读取的是哪个client的class

每个Server也有唯一的UUID标识，这样就可以实现链式类加载：

需要注意的是，在这种情况下，node节点仍然只持有一个server classloader，仅连接跟它直接关联的server。

UUID与classloader
使用client端UUID，即可实现不同的client端在执行同一个任务的时候的classloader隔离，因为uuid不同，会使用不同的classloader加载类。不过，如果同一个UUID提交了两个不同版本的任务class，则有可能出现冲突和错误。
你也可以手动指定client端的UUID，这样classloader即可重用。哪怕你重连client也可以重用同一个classloader。不过，此时随之而来的问题就是在客户端修改的版本可能不会在node端自动生效，不同的版本还可能造成冲突。这时，你可以重启node或者更换UUID使node重新加载class。

任务预部署
对于大任务，如果担心每次走网络效率低，根据上面介绍的classloader机制，自然想到可以预先将任务文件部署到server或者node节点。不过此时需要自己管理好部署的版本，所谓各有利弊。不过，如果任务版本稳定的话，建议采用此种方式。

classloader缓存池
为了避免加载过多的类造成内存溢出，JPPF在node端增加了classloader缓存池大小的设置，如果超过上限，则会销毁最老的classloader。

jppf.classloader.cache.size = n

本地缓存资源文件
当调用getResourceAsStream(), getResource(),getResources() or getMultipleResources()方法的时候，class loader会缓存非类定义的文件至内存或者本地文件系统中。这样会避免再次请求该文件时候的网络访问，提高效率。你可以指定缓存在内存中还是文件系统中：

# either “file” (the default) or “memory“
jppf.resource.cache.storage = file

文件的保存路径当然也是可以配置的，默认是系统临时文件夹System.getProperty("java.io.tmpdir").：

jppf.resource.cache.dir = some_directory

JPPF server中的类缓存

JPPF的服务端会在内存中缓存被classloader加载进来的类和其他资。这样就可以避免与客户端的频繁的网络访问，从而提高执行速度。你也无需担心内存溢出的问题，因为这种缓存采用的是软引用，这样缓存的类就可以在必要的时候被JVM的垃圾回收机制回收。在一般情况，该缓存还是可以显著的提升效率的。

Class loader代理模型
JPPF默认采用的是”父优先“的类加载模型，也就是上面我们介绍的模型。上述模型虽然好用，但是类的加载顺序就相对固定，也就不能最大化的优化加载效率。因此，JPPF通过继承URLClassLoader，复写并开放addURL接口（jdk里是protected，JPPF为public），使得用户的自己开发任务可以直接调用该方法，形成对classloader的一种扩展。用户可调用addURL方法，指定自己想要加载类的地址。此时JPPF classloader的加载顺序会出现变化，从大的步骤看，会先查找指定的URL classpath：

* 从clientclassloader入手：代理到server的classloader
* server的classloader: 先仅查找用户指定的URL classpath
* 如果找到类，则结束查找
* 否则，回到client的classloader，也仅查找URL的classpath
* 如果找到，结束查找。

此书，如果仍未找到，则回到前面介绍的通过网络的查找顺序。
概括来说，就是如果URL优先的代理模型激活，则node会先从本地层级中查找URL指定的classpath，然后在网络上通过server查找。有三种指定代理模型的方式，最简单的就是直接配置在node节点的配置文件中：

# possible values: parent | url, defaults to parent
jppf.classloader.delegation = parent

下载文件

如我们之前的介绍的，我们可以通过addURL(URL)方法，动态指定加载类的URL地址，那么自然想到，我们可以通过先将文件下载到本地，然后指定URL地址，从而进行本地加载，以提到效率。在AbstractJPPFClassLoader类中，有方法：
public URL[] getMultipleResources(final String...names)
可以帮你同时下载多个文件到本地。

以上只是我了解到的JPPF中关于类加载部分的设计和实现。从已有掌握来看，JPPF考虑的还是非常全面周到的，隔离、效率、一致性都有考虑，应该说对并行计算来说，很有保障。

阅读全文 »