I am writing an application in Java to make calls and view when people are in calls, their phone is ringing or are idle, using the library Jain-Sip and at the moment am trying to correctly implement presence with SUBSCRIBE and NOTIFY messages. I am able to get presence data to be received, but after a while the presence data stops being displayed by my program.
I believe this is because the overridden method "processRequest" is not being called. This is the earliest point in the program where NOTIFY messages are being handled and not even the print statements are being output.
The bizarre thing about this is that the notify messages are being sent when I make calls, and the presence data is there. I know this because I have done Wireshark traces when running the program.
Note: No exceptions are occurring during execution of the program, to cause erroneous behaviour.
If anybody has any insight into why this is happening, I would be very grateful.
Thanks a lot,
Adam
Make sure you add your listener class correctly. The only other possible cause would be if the NOTIFY is unsolicited, which should not be the case but it happens. Try to enable this flag gov.nist.javax.sip.DELIVER_UNSOLICITED_NOTIFY. See more about it here https://jsip.ci.cloudbees.com/job/jsip/javadoc/gov/nist/javax/sip/SipStackImpl.html
Otherwise you will need to attach DEBUG logs to figure it out, could be malformed request or something of the sort.
Related
I am trying to start basic and get a list of all threads in my inbox. I only have 14 total to make testing easy. Whenever I use the following:
ListLabelsResponse lR = mService.users().labels().list(user).execute();
I am able to get the list of labels. But when I try to do the same for threads following the developers tutorial from google: https://developers.google.com/gmail/api/v1/reference/users/threads/list
ListThreadsResponse threadResponse =
mService.users().threads().list(user).setQ(query).execute();
It never ends. Once the above statement is called, the rest of the method in which this statement is in never runs. Nothing happens. I get no error messages. I tested the above statement with and without the .setQ.
Through lots of logging, I narrowed it down to that single ListThreadResponse statement that makes the program seem like its running forever without doing anything. I waited for 5 minutes just to see if it's really slow but still nothing. Does anyone know why this could be happening?
If you check the documentation for listing labels you will see that the scope https://www.googleapis.com/auth/gmail.labels is enough. This will not suffice for listing threads however, which requires a broader scope.
If you use the appropriate scopes, and do the authorization step again, you will get tokens that will work.
For my game, I have it running on two servers (one for the game, one for the login system). They both need to interact with each other, and sometimes, ask questions about the state of something else in the other server.
For this example, the game server will be asking the login server if a player is trying to log in:
public boolean isLoggingIn(int accountId) {
//Form a packet to send.
int retVal = sendData();
return retVal > 0;
}
Obviously I'd use an int so information other than booleans can be returned.
My question is, how do I get this modal-style programming working? It'd work just like JFileChooser's getOpenDialog() function.
Also, I should mention that more than one thread can call this method at once.
I assume by modal, you mean trying to block all actions except one. I strongly suspect that this style will lead you into trouble. Modal interaction is a form of locking and therefore not very tolerant to hangups and disconnects and such. To make it tolerant, you need timeouts and cleanup code for cases when someone entered a mode and then nothing further happened. (i.e they closed their laptop, or the game crashed, they unplugged the network cable etc).
If I were you I would instead try to think of things in terms of authentication and authorization.
The quick answer - you need to expose methods on both servers as RMI-capable, and simply invoke methods like you described.
You might find it useful to review the official Oracle RMI tutorial: http://docs.oracle.com/javase/tutorial/rmi/index.html
Althought your design might be wrong - it's your design, and why not letting you shoot your head? ;)
Also, it's worth looking at Spring Security: http://static.springsource.org/spring-security/site/
If you use something like this on a thread that is supposed to handle other requests after it, it would hang up all those requests while it is blocking for a return value if the latency between the game and login servers is high. Certainly what you want instead is a callback so that your thread could handle other requests while it waits for a response.
I see no reason to halt execution of a thread until a value is received. If you need the value for an operation after it, then just copy all the code you have after the call you want to be "modal" in the callback. If you expect to send multiple requests while still waiting for a response, then send a unique "responseId" from the requester's side that the responder can include in its response. Use the "responseId" as a key for a Map with Runnables as values. When you receive a response, call remove on the Map with the responseId key and call run() on the Runnable value that is returned. MINA is supposed to asynchronous and should not block for a response packet.
If you have a really good reason for why you want to handle it all on the same thread, you can look into the java.util.concurrent package. I would implement it using a CountDownLatch of count 1, call await() after sending a request message, and call countDown() when you receive a response by MINA. You have to use an AtomicReference or an array of length 1 to hold the value you received in the response that you can read back into the waiting thread.
PS, you still doing MapleStory work?
I can use this code to make outgoing call:
Intent dial = new Intent(Intent.ACTION_CALL);
dial.setData(Uri.parse("tel:5556") );
context.startActivity(dial);
But how to detect whether the call is picked up or the call is refused?
I tried PhoneStateListener, but it is not working.
Unfortunately, Android gives no mean to know when an outgoing call has been answered.
PhoneStateListener works fine but the 3 states notified by onCallStateChanged are not enough. An additional state like CALL_STATE_CONNECTED would be welcome.
There is an open issue requesting this feature but it didn't get much attention so far:
https://code.google.com/p/android/issues/detail?id=14266
Some people (like me) falls back using logcat and tries to infer if an outgoing call has been answered but this is far from an ideal solution.
I am also searching for an answer to the same problem, apparently no straight forward method is present to do this. But, I think we can combine a Call Log content observer with PhoneStateListener to get the call duration.
We could set a flag in the shared prefs when an outgoing call is started, if anything changes in call log and our shared prefs flag is true we could get the call duration from the call log to see if the call was ever connected :)
You can Check these Duplicate questions:
How can my android app detect a dropped call?
Detecting outgoing call and call hangup event in android
So, to explain this, I'll start out by going through the application stack.
The system is running JSP with jQuery on top, talking through a controller layer with a service layer, which in turn utilizes a persistence layer implemented in Hibernate.
Now, traditionally, errors like having overlapping contracts has been handled through throwing exceptions up through the layers until they're translated into an error message for the user.
Now I have an object that at any given time can only be tied to one contract. At the moment, when I save a contract, I look at all of these objects and check if they're already covered by an existing contract. However, since multiple clients can be saving at any given time, this introduces the risk of getting past the check on two separate contracts, leading to one object being tied to two contracts at the same time.
To combat this, the idea was to use a queue, put objects into the queue from the main thread, and then have a separate thread take them out one by one, saving them.
However, here's the problem. For one, I would like the user to know that the saving is currently happening, for another, if by accident the scenario before happens, and two contracts with the same object covering the same time is in the queue, the second one will fail, and this needs to be sent back to the user.
My initial attempt was to keep data fields on the object put into the queue, and then check against those in a blocking wait, and then throw an exception or report success based on what happens. That deadlocked the system completely.
Anyone able to point me in the right direction with regards to techniques and patterns I should be using for this?
I can't really tell why you have a deadlock without seeing your code. I can think of some other options though:
Poll the thread to see its state (not as good).
Use some kind of eventing system. You would have an event listener (OverlappingContractEventListener perhaps) and then you would trigger the event from the thread when the scenario happens. The event handler would need to persist this information somehow.
If you are going for this approach, then on the client side you will need to poll.
You can poll a specific controller (using setInterval and AJAX) that looks up the corresponding information for the object to see what state its in. This information should have been persisted by your event listener.
You can use web workers (this is supported in Chrome, Firefox, Safari, and Opera. IE will support it in 10) and perform the polling in the background.
There is one other way that doesn't involve eventing. It depends on you figuring out the source of your deadlock though. Once you fix the source of your deadlock you can do one of two things:
Perform an AJAX call to the controller. The controller will wait for the service to return information. The code to issue feedback to the user will be inside the success handler of your controller.
Use a web worker to perform the call in the background. The web worker would also perform an AJAX call and wait for the response.
Shouldn't you be doing the check for duplicate contracts in the database? Depending on the case, you can do this with a constraint, trigger, o stored procedure. If it fails, send an exception up the stack. That's normally the way to handle things like this. You can then catch the exception in jQuery and display an error:
jQuery Ajax error handling, show custom exception messages
Hope this helps.
I'm facing this problem: after clicking on a button, I make a request to the server and get some data; then, I display the data on a new page/view. This raises a problem: the UI has to wait while the request is being made and data is being received, parsed and set on the view. This results in the user having to wait until all the data is loaded before even being able to go back, and doesn't even have the chance to cancel the call. Multithreading would solve the issue, and that's where I need help.
The HTML5 Web Workers would do the trick for me, however I don't want to "hard code" them in JSNI and have all the calls written with Javascript instead of GWT Java (RequestBuilder). I've read about DeferredCommand but I also don't think it's the answer to my issue.
Any suggestions? Or this is an impossible optimization, at the moment?
In JS, therefore GWT, there is no multithreading. Instead you should use asynchronous calls with callbacks. Normally when you use GWT RPC for communication, you issue a request and handle result in onSuccess event. Alternatively you can always use Timer to check for result periodically. I'm not sure what kind of request you are making, so hard to be specific. Probably you should check appropriate section of Communicating with the server
EDIT: I've just noticed you mention RequestBuilder. The sendRequest() should not block execution and you should process result in RequestCallback.onResponseReceived() of provided callback. Which mean you somehow continue your button event handling in that callback.