We Keep Coding

How do I keep track of requests issued/completed without the use of additional state variables? (Java/Grpc)

I am using the StreamObserver class found in the grpc-java project to set up some bidirectional streaming.
When I run my program, I make an undetermined number of requests to the server, and I only want to call onCompleted() on the requestObserver once I have finished making all of the requests.
Currently, to solve this, I am using a variable "inFlight" to keep track of the requests that have been issued, and when a response comes back, I decrement "inFlight". So, something like this.
// issuing requests
while (haveRequests) {
MessageRequest request = mkRequest();
this.requestObserver.onNext(request);
this.inFlight++;
}
// response observer
StreamObserver<Message> responseObserver = new StreamObserver<Message> {
#Override
public void onNext(Message response) {
if (--this.onFlight == 0) {
this.requestObserver.onCompleted();
}
// work on message
}
// other methods
}
A bit pseudo-codey, but this logic works. However, I would like to get rid of the "inFlight" variable if possible. Is there anything within the StreamObserver class that allows this sort of functionality, without the need of an additional variable to track state? Something that would tell the number of requests issued and when they completed.
I've tried inspecting the object within the intellij IDE debugger, but nothing is popping out to me.

To answer your direct question, you can simply call onComplete from the while loop. All the messages passed to onNext. Under the hood, gRPC will send what is called a "half close", indicating that it won't send any more messages, but it is willing to receive them. Specifically:
// issuing requests
while (haveRequests) {
MessageRequest request = mkRequest();
this.requestObserver.onNext(request);
this.inFlight++;
}
requestObserver.onCompleted();
This ensures that all responses are sent, and in the order that you sent them. On the server side, when it sees the corresponding onCompleted callback, it can half-close its side of the connection by calling onComplete on its observer. (There are two observers on the server side one for receiving info from the client, one for sending info).
Back on the client side, you just need to wait for the server to half close to know that all messages were received and processed. Note that if there were any errors, you would get an onError callback instead.
If you don't know how many requests you are going to make on the client side, you might consider using an AtomicInteger, and call decrementAndGet when you get back a response. If the return value is 0, you'll know all the requests have completed.

Spring websocket and Stomp.js - how long should i wait between subscribe and send?

I have the following code (from the spring websocket demo app) :
stompClient.connect({}, function(frame) {
setConnected(true);
console.log('Connected: ' + frame);
stompClient.subscribe('/user/queue/greeting', function(greeting) {
displayQueueMessage(greeting);
});
function sendName() {
var name = document.getElementById('name').value;
stompClient.send("/app/wsdemo", {}, JSON.stringify({
'name' : name
}));
}
This is a simple subscribe call for a queue on the server, and another method "sendName()" that sends calls the server.
after sendName is called, the server response to the callback function supplied at the connect method:
function(greeting) {
displayQueueMessage(greeting);
});
My question is - how "long" should the client wait from the subscribe call until he can start calling sendName ? I mean, the potential issue i can see here is the following:
i) the client subscribes first for the queue,
ii) the client calls sendName
iii) the server recieves the 2nd call before he recieves the subscribe call.
iv) the response from the server will not be recieved by the client.
my questions:
1) is that scenario really is an issue?
2) how can i avoid it?
3) iv'e read somewhere that since websocket works with tcp, the order of messages is maintained, so my last question is - what about the fallback capability of stompJS for clients with no websocket support? will the order be maintained as well?

Since you subscribe to the queue during the connect phase, you just have to wait for the connection to be established before sending requests to the server.

I think you fix your problem and now know what is promise, callback and that javascript in asynchronous.
When you subscribe:
stompClient.subscribe('/user/queue/greeting', function(greeting) {
displayQueueMessage(greeting);
});
you pass callback function as second parameter, and when and only when subscribe happens (successful request) you callback will be executed.
You can avoid it if you will call sendName() in callback, or using any other approach to synchronize that two points.

flex blazeds response null for first time service call

I am using Flash Builder 4.5 with Blazeds service to develop flex
appliacation, here i used java for services and here i am getting
empty value from server side for first time service call, after that
from next service calling it gives correct result to me, I don't know
why i am getting null value for first time hitting the service. Here
for the first time hitting java service, the functionality is running
at java side but return value is null.
Please any one help me out.

If we use LastResult for service response then I got this error, I used requestHandler for handling response and i got my response for first time itself.
Service.addEventListener("result", resultHandler);
private function resultHandler(evt:ResultEvent):void {
var ac = evt.result;
}

Android SignalR should be implemented as Service or IntentService?

On my Android App, I'm implementing SignalR connection (https://github.com/erizet/SignalA) to connect to a Hub server to send requests and receive responses.
a sample of my code is as follows:
signalAConnection = new com.zsoft.SignalA.Connection(Constants.getHubUrl(), this, new LongPollingTransport())
{
#Override
public void OnError(Exception exception)
{
}
#Override
public void OnMessage(String message)
{
}
#Override
public void OnStateChanged(StateBase oldState, StateBase newState)
{
}
};
if (signalAConnection != null)
signalAConnection.Start();
There's also the sending bit
signalAConnection.Send(hubMessageJson, new SendCallback()
{
public void OnError(Exception ex)
{
}
public void OnSent(CharSequence message)
{
}
});
The sending and receiving will occur across activites, and some responses will be sent at random times regardless of the activity, also, the connection should be opened as long as the app is running (even if the app is running in the background) that's why I wish to implement the signalA connection as a background service
The question is should I implement it as:
1 - a Service (http://developer.android.com/reference/android/app/Service.html)
OR
2 - an Intent Service (http://developer.android.com/training/run-background-service/create-service.html)
Keeping in mind that I will need to send strings to the service and get response strings from the service.
I would be most grateful if someone would show me how to implement this kind of connection in code as a background service/intentservice.
Thanks for reading.
UPDATE:
Please see this demo activity made by the developer as how he implemented SignalA
https://github.com/erizet/SignalA/blob/master/Demo/src/com/zsoft/SignalADemo/DemoActivity.java
The problem is AQuery (which I know nothing about) is being used in this demo activity. Does AQuery run in the background all the time ?
The problem is, the latest update on SignalA mentions the following
I have changed the transport. LongPolling now uses basic-http-client
instead of Aquery for http communication. I've removed all
dependencies on Aquery.
Hence I'm not sure whether I should follow this demo activity or not
Update 2:
This is the thing that is confusing me most
in the IntentService, the OnHandleIntent method calls stopSelf after it finishes its tasks, when I actually want the code in the IntentService to keep running all the time
protected abstract void onHandleIntent (Intent intent)
Added in API level 3
This method is invoked on the worker thread with a request to process. Only one Intent is processed at a time, but the processing happens on a worker thread that runs independently from other application logic. So, if this code takes a long time, it will hold up other requests to the same IntentService, but it will not hold up anything else. When all requests have been handled, the IntentService stops itself, so you should not call stopSelf().

SignalA is running on the thread that creates and starts the connection, but all network access is done in the background. The remaining work on the starting thread is really lightweight, hence its perfectly ok to do it on the UI tread.
To answer your question, you need to have a thread running the signala connection. Therefore I think a Service is the best choice since SignalA need to be running all the time.
Regarding Aquery and the demo project. I removed all dependencies to Aquery in the libraries, not in the Demo. To be clear, you don't need Aquery to run SignalA.

In my case, what I wanted was a Service not an Intent Service, since I wanted something that would keep running until the app closes

Android -- Bluetooth Read Write Problem?

While testing and analyzing code of Bluetooth Chat, I have questions about my own program.
a) My program sends a command to another bluetooth device. (I can handle it using sample code provided)
b) It then receives a response to my previous command.
c) Based on the response received, my device sends another command.
d) It then receives a response to my command.
and the same procedure continues ...
My question is , in Bluetooth Chat program there is a handler which receives a response. How can I make sure to receive first response and then used that to send another command ... and then receive a response again based on second command, using that same handler.

My question is , in Bluetooth Chat program there is a handler which receives a response. How can I make sure to receive first response and then used that to send another command ... and then receive a response again based on second command, using that same handler.
How about using a state machine?