asterixdb-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Murtadha Hubail (Code Review)" <>
Subject Change in hyracks[master]: Add Global Resource Id Factory
Date Tue, 01 Dec 2015 13:24:32 GMT
Murtadha Hubail has posted comments on this change.

Change subject: Add Global Resource Id Factory

Patch Set 3:

File hyracks/hyracks-api/src/main/java/org/apache/hyracks/api/application/

Line 28:     public boolean isReadyToProcessUnqiueIdRequests();
> Does this need to be on the ApplicationEntryPoint? Would the ApplicationCon
The thing is this logic needs to be application specific. Asterix is using the same CC and
NC application context from Hyracks. The only application specific implementations in Asterix
are CC/NCApplicationEntryPoint. If we need to implement a customized CC and NC application
contexts for Asterix, it is going to require many changes. Do you think that we need to provide
these implementations for this change?
File hyracks/hyracks-api/src/main/java/org/apache/hyracks/api/application/

Line 32:     public long getNCMaxUniqueId() throws Exception;
> This doesn't seem to fit in very well with the lifecycle-oriented methods o
Again, application specific implementation in NCApplicationEntryPoint.
File hyracks/hyracks-api/src/main/java/org/apache/hyracks/api/context/

Line 32: 
> Does this need to be part of the RootContext? That seems very high up in th
This request needs to go to NodeControllerService to send it to the CC. IHyracksRootContext
is the bridge between INCApplicationContext and NodeControllerService. We can move this to
INCApplicationContext by changing the current hierarchy and passing NodeControllerService
reference to INCApplicationContext. Thoughts?
File hyracks/hyracks-control/hyracks-control-common/src/main/java/org/apache/hyracks/control/common/base/

Line 75:     public void getUnqiueId(InetSocketAddress ncAddress, String nodeId) throws Exception;
> I think that we shouldn't need the ncAddress here? Isn't the nodeId enough 
This is true if we assume that no node will send such request before registration. In the
current implementation, a node is able to submit such request before its registration. I have
no problem removing it, but in case of such invalid request, we won't have the node ip to
respond by an exception.
File hyracks/hyracks-control/hyracks-control-common/src/main/java/org/apache/hyracks/control/common/ipc/

Line 1265:         private final InetSocketAddress ncAddress;
> Again, I think the we can do without this address.
See comment in IClusterController.
File hyracks/hyracks-control/hyracks-control-common/src/main/java/org/apache/hyracks/control/common/ipc/

Line 158:     public void getUnqiueId(InetSocketAddress ncAddress, String nodeId) throws Exception
> Again, I think the we can do without this address.
See comment in IClusterController.
File hyracks/hyracks-control/hyracks-control-nc/src/main/java/org/apache/hyracks/control/nc/

Line 165:     private final LinkedBlockingQueue<GetUniqueIdResponseFunction> uniqueIdResponseQ;
> Why do we need a new queue here?
The existing queue is used to collect requests and process them sequentially. This queue is
used for responses (unique id responses in specific). Since multiple concurrent threads may
request unique ids, this queue is used to synchronize them.
File hyracks/hyracks-storage-common/src/main/java/org/apache/hyracks/storage/common/file/

Line 28:     private final IHyracksRootContext rootCtx;
> Again, this might not need to be the root context.
See comment in IHyracksRootContext.

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: Ib9f49234eebe912c48e7f71980433a9b42595741
Gerrit-PatchSet: 3
Gerrit-Project: hyracks
Gerrit-Branch: master
Gerrit-Owner: Murtadha Hubail <>
Gerrit-Reviewer: Ian Maxon <>
Gerrit-Reviewer: Jenkins <>
Gerrit-Reviewer: Murtadha Hubail <>
Gerrit-Reviewer: Till Westmann <>
Gerrit-Reviewer: abdullah alamoudi <>
Gerrit-HasComments: Yes

View raw message