Wrote Skeleton Sources

[garudakang]

Wrote Skeleton Sources.

1. MeerRunner Tails File from /src/test/resources/catalina.log
2. Runner Sends ReadLine Strings To GuardMeer(ObserverMeers)
3. GuardMeer(ObserverMeers) Parses String and Send to BossMeer(FindMaxLength)
4. BossMeer(FindMaxLength) Computes Messages and Print out Result

[garudakang]

Eclipse Test Result is Follow...

14/04/08 17:21:43 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable 14/04/08 17:21:43 WARN bsp.BSPJobClient: No job jar file set. User classes may not be found. See BSPJob#setJar(String) or check Your jar file. 14/04/08 17:21:44 INFO bsp.LocalBSPRunner: Setting up a new barrier for 1 tasks! 14/04/08 17:21:44 INFO ipc.Server: Starting Socket Reader #1 for port 55555 14/04/08 17:21:44 INFO ipc.Server: IPC Server Responder: starting 14/04/08 17:21:44 INFO ipc.Server: IPC Server listener on 55555: starting 14/04/08 17:21:44 INFO ipc.Server: IPC Server handler 0 on 55555: starting 14/04/08 17:21:44 INFO ipc.Server: IPC Server handler 1 on 55555: starting 14/04/08 17:21:44 INFO ipc.Server: IPC Server handler 2 on 55555: starting 14/04/08 17:21:44 INFO ipc.Server: IPC Server handler 3 on 55555: starting 14/04/08 17:21:44 INFO ipc.Server: IPC Server handler 4 on 55555: starting find max : 209 find max : 209 find max : 209 find max : 209

[garudakang]

Todo

Get/Set RPC Server Info for Remote Connection (Master is Who?) RPC Client Sample Code

[edwardyoon]

Comments:

1. Why do we need to declare variables in MeerJob class? (30 ~ 36 lines)
2. MessageIterator will comsume the huge memory. We have to access directly.

[ijsong]

BossMeer bsp already has queue for incoming messages. So, I think it is fine that peer has new api to return iterator for message queue. (Is it right that hama is patched to handle this situation?)

bossMeer.masterCompute(peer.getCurrentMessageIterator(), signalMeer)

[edwardyoon]

So, I think it is fine that peer has new api to return iterator for message queue. (Is it right that hama is patched to handle this situation?)

Maybe, or not. I personally think that such case should be handled by user side.

You can declare your own methods hasNext(), next(), remove(). So, the getCurrentMessage() method can be used to to go to next element. To check whether next element exists, you'll just need to count the calls of next() method. My example is like below:

int numOfElements = getNumCurrentMessages();
int consumedElements = 0;
...
public boolean hasNext() {
  return (numOfElements > consumedElements) ? true : false;
}

public MSG_TYPE next() { 
  consumedElements++;
  return peer.getCurrentMessage(); 
}

@ijsong Will you try to implement this?

[edwardyoon]

Another comment:

The sync() method is used for the global synchronization. Below code and using of background threads are very odd to me. Your program seems totally wrong.

  if (peer.getPeerName().equals(masterName)) {
    peer.sync();

[ijsong]

@edwardyoon Ok. I will write it.

[edwardyoon]

@ijsong Instead of creating new class like MessageIterator, you can implement iterable object as a argument. For example,

masterCompute(new Iterator<Type>() { 
  ...
}, signalMeer);

[edwardyoon]

Let's close this ticket.