《Apache CXF开发Web Service 理解CXF Frontends之Code-First》一文提到Code-First和Contract-First两种不同的方式，这里将介绍Contract-First的使用。如果使用Contract-First的开发方式，开发者首先准备好WSDL文档，通过CXF提供的工具wsdl2java来生成代码。这个工具在%CXF-HOME%/bin目录中。Contract-First需要完成的工作有：
生成服务组件
实现服务方法
发布Web Service
开发客户端
使用《Apache CXF开发Web Service 理解CXF Frontends之Code-First》中生成的WSDL文档，即启动mvn test –Pserve后，访问http://localhost:8080/OrderProcess?wsdl所看到的内容。现在是要把操作倒过去，通过这个WSDL来生成SEI。
<?xml version='1.0' encoding='UTF-8'?>
<wsdl:definitions name="OrderProcessService" targetNamespace="http://order.demo/" xmlns:ns1="http://schemas.xmlsoap.org/soap/http" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://order.demo/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="unqualified" targetNamespace="http://order.demo/" xmlns:tns="http://order.demo/" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="processOrder" type="tns:processOrder" />
<xs:element name="processOrderResponse" type="tns:processOrderResponse" />
<xs:complexType name="processOrder">
<xs:sequence>
<xs:element minOccurs="0" name="arg0" type="tns:order" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="order">
<xs:sequence>
<xs:element minOccurs="0" name="customerID" type="xs:string" />
<xs:element minOccurs="0" name="itemID" type="xs:string" />
数据中心的HBase（cdh3u3）集群已经稳定运行了差不多半年多了。由于前期规划的不合理，最近给所有的数据节点分批重装了一下系统，最后发现经常有几个节点出现磁盘空间不足的异常。查看文件系统，发现原来大约占用6T空间的HDFS已经占用了差不多15+T的数据
1、先用fsck进行文件系统检查，发现大约占用2T的空间（*3约等于6T，数据重量差不多就是这么多），并没有数据块有过多的备份。
2、查看对应datanode的数据目录，发现确实有很多的数据块（量非常大，都超过了实际hdfs中的数据块总量）
这时候，猜测应该是有很多需要被删除的数据块没有被删除。猜测可能是NameNode和DataNode之间的通讯出现异常导致。于是查看NameNode和DataNode日志，发现并没有任何异常信息，只是发现NameNode定时对其中的三台机器发出了删除指令
BLOCK* ask 192.168.200.8:50010 to delete blk_7080908721303033545_7530145
BLOCK* ask 192.168.200.9:50010 to delete blk_-6550808355677895247_7465333
BLOCK* ask 192.168.200.7:50010 to delete blk_2415291932316966347_7460687
其他节点则没有收到过相应的删除数据块的指令。因为所有节点的心跳一直没有问题，日志中也没有异常信息，一时想不到解决这个问题的办法。于是重启datanode，仍然无法删除过期的数据块。重启namenode，过了一段时间，发现数据量恢复正常了。
可是，过了一周发现同样的问题再次出现。google了一圈，只有在maillist中找到有人提到相关的问题，但是描述起来和我的情况并不完全一致：
Unbalanced Datanode and Lots of Blocks Waiting for Deletion
最后，通过dfsadmin证实了，确实是有大量的block在等待删除
hadoop dfsadmin -metasave meta.txt
meta.txt显示有：几十万的block等待删除
Metasave: Blocks 572428 waiting deletion from 8 datanodes.
4、没有办法，只好从源码着手。在FSNameSystem.java文件里面找到了最终问题的所在：
public int computeDatanodeWork() throws IOException {
int workFound = 0;
int blocksToProcess = 0;
int nodesToProcess = 0;
// blocks should not be replicated or removed if safe mode is on
if (isInSafeMode())
return workFound;
synchronized(heartbeats) {
blocksToProcess = (int)(heartbeats.size()
* ReplicationMonitor.REPLICATION_WORK_MULTIPLIER_PER_ITERATION);
nodesToProcess = (int)Math.ceil((double)heartbeats.size()
* ReplicationMonitor.INVALIDATE_WORK_PCT_PER_ITERATION / 100);
}
workFound = computeReplicationWork(blocksToProcess);
// Update FSNamesystemMetrics counters
synchronized (this) {
pendingReplicationBlocksCount = pendingReplications.size();
underReplicatedBlocksCount = neededReplications.size();
scheduledReplicationBlocksCount = workFound;
corruptReplicaBlocksCount = corruptReplicas.size();
}
workFound += computeInvalidateWork(nodesToProcess);
return workFound;
}
注意上面红色部分代码，computeInvalidateWork就是用于计算这次需要删除的数据块。但是并不是每次都把所有的节点都处理一遍，而是每次只处理nodesToProcess个节点，而这个数量决定于datanode的总数(heartbeats.size，我这儿是8)和一个系数(INVALIDATE_WORK_PCT_PER_ITERATION，写死的32)。
也就是说每次只处理
8*32% = 3(这就解释了为啥每次只删除三台数据节点上的数据块。)
再查看节点选择部分：
……
private Map<String, Collection<Block>> recentInvalidateSets =
new TreeMap<String, Collection<Block>>();
……
String firstNodeId = recentInvalidateSets.keySet().iterator().next();
……
发现是通过iterator遍历的，然后悲剧的发现recentInvalidateSets用的是TreeMap，也就是说是有序的……
所以只要这三个节点有数据需要删除，就不会删除到其他节点
这时候，发现这个问题是调整的时候，修改了一个配置项（dfs.replication.interval，默认是3秒，我修改成了30秒）导致的，当时修改的初衷是防止过早出现数据块复制。但是修改这个配置项以后，数据块副本数检查的间隔拉长了，导致30秒内，有几台机器一直有数据块需要删除，从而无法删除其他节点上的数据块，最终导致磁盘空间无法释放。因为INVALIDATE_WORK_PCT_PER_ITERATION是系统写死的，所以只能通过把dfs.replication.interval改回来，暂时解决这个问题。
ps：查了一下最新的1.0.4代码，这部分bug已经修复，改成随机抽取的模式，避免出现上述情况。（cdh3u4还存在这个问题）
已有 0 人发表留言，猛击->>这里<<-参与讨论
ITeye推荐
- —软件人才免语言低担保 赴美带薪读研！—
by zxy,Java/C++编程交流群:168424095
(1)WSAStartup()函数用于初始化Windows Sockets,并返回WSADATA结构体。只有调用WSAStartup()函数后，应用程序才能调用其他WindowsSockets API函数，实现网络通信。
函数原型：
intWSAStartup(
INWORD wVersionRequested,//Windows Sockets DLL规定调用者可以使用的WindowsSockets规范的版本，为WORD类型。高位字节中存储副版本号，低位字节中存储高版本号。可以使用MAKEWORD()函数返回该值。
OUTLPWSADATA lpWSAData//指向WSADATA结构体的指针，用于接收Windows Sockets执行的数据
)
成功返回0
(2)IP地址的表示形式
(2.1)网络字节顺序格式 TCP/IP规定，低位存储地址中保存数据的高位字节，数据传输顺序是由高位至低位进行的。
用结构体in_addr来保存网络字节顺序格式的IP地址，定义如下：
structin_addr{
union{
struct{u_chars_b1,s_b2,s_b3,s_b4;} S_ub_b;//由4个u_char组成的主机格式IP地址
struct{u_shorts_w1,s_w2;}S_un_w;//由2个u_short组成的主机格式IP地址
u_longS_addr;//以u_long变量表示的主机格式IP地址
}S_un;
inet_addr()、inet_ntoa()实现点分法IP地址字符串和网络字节顺序格式IP地址之间的转换
inet_addr()将点分法IP地址字符串转换为in_addr结构体中的IP地址格式，函数原型：
unsignedlong inet_addr(
constchar* cp//点分法IP地址字符串
);
正确，返回unsignedlong类型的网络字节顺序格式IP地址，错误返回INADDR_NONE
inet_ntoa()将in_addr结构体中IP地址转换为点分法IP地址字符串，函数原型：
charFAR* inet_ntoa(
structin_addr in//要进行转换的IP地址
);
返回char*类型的IP地址。
(2.2)主机字节顺序格式
用htonl()、htos()、ntohl()、htohs()实现主机字节顺序格式和网络字节顺序格式的转换。
htonl()将u_long类型的主机字节顺序格式IP地址转换为TCP/IP网络字节顺序格式，函数原型：u_long htonl(u_longhostlong);
htons()将u_short类型的主机字节顺序格式IP地址转换为TCP/IP网络字节顺序格式，函数原型：u_short htons (u_short hostshort);
ntohl()将u_long类型的TCP/IP网络字节顺序IP地址转换为格式主机字节顺序格式，函数原型：u_longntohl (u_long netlong);
ntohs()将u_short类型的TCP/IP网络字节顺序IP地址转换为格式主机字节顺序格式，函数原型：u_shortntohs (u_ short netlong);