I have a scenario where I have some timing data that I get from a MIDI file. When a MIDI note needs to be played, I need to send a command over UDP. Basically, I have instructions that say "play note A, wait 125ms, play note B, wait 300ms, play note C..." and each time I "play note X" I need to send data over UDP. I have tried using both a TimerTask and a simple thread with a loop that check the system time and calculate how much time has elapsed and decide whether or not to play a note based on that, but both methods seem to have timing issues. The TimerTask doesn't run exactly on the specified interval (which was stated in the documentation) so I get erratic messages. The thread works better, but it still hiccups sometimes which I assume is because other threads are getting priority over it.
Is there a better way to send this data with more accurate timing? Is there something I can use like the Clip interface in Java that is used for playing audio?
Any assistance is very much appreciated.
This is an approach just about doomed to failure. Let me count the issues here:
1)Android is not a real time OS. Neither is Linux (which its built on). Expecting ms level timings to happen exactly correctly is never going to work. Even if the clock is accurate enough to interrupt on a 1ms rate, there's no assurance that Linux will schedule your thread for wakeup.
2)TimerTasks aren't promised to be accurate even to the degree limited by 1.
3)You're then sending it somewhere via UDP? A protocol that has no assurance as to delivery or timing, to a receiver who will then do something with it- and that receiver may have additional timing issues of its own.
Throw out this entire approach and start over would be my advice. Every single step of this says bad idea.
Related
What is both faster and "better practice", using a polling system or a event based timer?
I'm currently having a discussion with a more senior coworker regarding how to implement some mission critical logic. Here is the situation:
A message giving an execution time is received.
When that execution time is reached, some logic must be executed.
Now multiple messages can be received giving different execution times, and the logic must be executed each time.
I think that the best way to implement the logic would be to create a timer that would trigger the logic when the message at the time in the message, but my coworker believes that I would be better off polling a list of the messages to see if the execution time has been reached.
His argument is that the polling system is safer as it is less complicated and thus less likely to be screwed up by the programmer. My argument is that by implementing it my way, we reduce the reduce the computational load and thus are more likely execute the logic when we actually want it to execute. How should I implement it and why?
Requested Information
The only time my logic would ever be utilized would almost certainly be at a time of the highest load.
The requirements do not specify how reliable the connection will be but everyone I've talked to has stated that they have never heard of a message being dropped
The scheduling is based on an absolute system. So, the message will have a execution time specifying when an algorithm should be executed. Since there is time synchronization, I have been instructed to assume that the time will be uniform among all machines.
The algorithm that gets executed uses some inputs which initially are volatile but soon stabilize. By postponing the processing, I hope to use the most stable information available.
The java.util.Timer effectively does what your colleague suggests (truth be told, in the end, there really aren't that many ways to do this).
It maintains a collection of TimerTasks, and it waits for new activity on it, or until the time has come to execute the next task. It doesn't poll the collection, it "knows" that the next task will fire in N seconds, and waits until that happens or anything else (such as a TimerTask added or deleted). This is better overall than polling, since it spends most of its time sleeping.
So, in the end, you're both right -- you should use a Timer for this, because it basically does what your coworker wants to do.
My application takes a lot of measurements of it's internal processes. For example I time certain methods, I time external webservice calls and I also have variables which have a changing value, and processes which have a 'state' (e.g. PAUSED, WAITING etc).
The application uses 100 to 200 threads, and each bit of data would be associated with a particular thread.
I am looking for some software that I can channel all this information into that would produce useful metrics and graphs of the data (ideally in real time or close to real time), let me set thresholds to trigger warnings, would allow me to filter the data by thread or thread group, etc etc.
The application is performing time critical tasks so the software/api would need to be very fast and never block.
The application is written in java, and ideally the software/api would be in java as well. I think what I'm looking for is called Event Stream Processing, but I'm really not sure what language to use to describe it.
All I've found so far are Esper and ERMA. Can anyone give me a recommendation? I'm the only one working on this project so I'm hoping for something that is pretty easy to set up and use, and has a workable front end.
In the end I found Graphite which was pretty close to being exactly what I wanted. Not the simplest to set up and configure however, but I got it working in the end.
http://graphite.wikidot.com/
In my case I send data directly from my application to Statsd (via UDP), which collects the data and does some pre processing before it ends up in the whisper back end, there is a simple example of a java interface here https://github.com/etsy/statsd/commit/2253223f3c19d2149d65ec5bc802198ff93da4cb
Alternatively you could send your data directly to graphite, example here http://neopatel.blogspot.co.uk/2011/04/logging-to-graphite-monitoring-tool.html
I have been researching Services, but I cannot figure out a way to do something periodically. I realize that when a service is called, it calls the OnCreate() method and the onStartMethod() but what I want to do is do a process every 10 minutes or so (subject to change). So in which method/how would I make the service execute code on an interval of a certain time?
I'm sorry if I missed something in the Android documentation.
[EDIT]
More specifically, I want to update some information and see if it is any different than the existing one -- and then issue a taskbar Notification to the user.
You probably want to check out AlarmManager, it's an easy way to do what you want. It'd also be nicer in terms of memory usage, battery, etc. than keeping a service open for 10 minutes just waiting to do something.
http://developer.android.com/reference/android/app/AlarmManager.html
I'm writing a chess program in Java. The GUI should be able to communicate with a chess engine supporting the Chess Engine Communication Protocol. But I'm having some difficulties reconciling the protocol with Java's I/O facilities.
Because engines that predate protocol version 2 do not send "feature", xboard uses a timeout mechanism: when it first starts your engine, it sends "xboard" and "protover N", then listens for feature commands for two seconds before sending any other commands.
It seems that Java's facilities for interrupting I/O operations are limited. The only option I can find is NIO's InterruptibleChannel, which closes itself when interrupted.
I don't want the stream to close when the timeout occurs -- I just want to interrupt the read. Does anyone know a solution?
I think you may be overthinking the problem. You don't need to abort the read() call after 2 seconds, you just need your backing logic to understand that after 2 seconds it should not expect to receive any "feature" commands. Then your implementation can write the next command, and your read() will return the byte(s) from the response to that command.
That's how I'd approach it anyways, by having generic code that reads in bytes and passes them further up the chain where context-specific processing can be done. Then you don't need to interrupt the read, the upstream code just needs to understand that the data it eventually gets back may be a "feature" command, or it may not be.
It's not clear to me that you need to do anything much. What you have quoted is the timeout behaviour of the board. You don't have to implement that, it is done, at the board, which is the peer, i.e. the other end.
I am thinking how to build a real-time system using java without Sun Real-time System API.
Say, a boss generates an event at 11:00 am, he has to get feedback at 11:10 am. If no any feedback, he will resend his event.
The staff gets his boss's event at 11:01 am, he has to leave 1 minutes for sending his result back to his boss. So actually he has 8 minutes to do his job. At 11:09 am, he has to send a feedback no matter he finished it or not.
This is a real-time system, isn't it ?
In this case, how to design our system using java ? This is a producer-consumer pattern. In the consumer side, use which object (blockingqueue, delayqueue ...) to meet this requirement ?
Any weblink, open source will be welcome.
Thank.
You cannot do real-time programming in the real computer engineering sense in Java. You are at the mercy of a thread scheduler and an operating system with totally unknown underlying properties. If the OS felt like waiting until 11:20 until it got back around to giving the JVM some CPU time, that's its business.
If you mean "realtime" in the Microsofty way as in "Things respond really really fast and we're careful never to block the main UI thread" that doesn't have a well defined technical meaning. It just means "architecture user facing code to give the appearance they don't have to wait on the computer."
--edit in response to comment.
If by 11:08 you mean 'between 11:07:59 and 11:08:01' then regular java can generally do that for you on a modern platform with careful programming. What it can't deliver is a situation where the event happening at 11:08:01 is considered a platform defect, it just doesn't make that guarantee.
When we say 'real time' and what the RTS API is for, is a situation more like "The bonding head must be at these coordinates at exactly this millisecond, if it's more than half a millisecond late, the part will be defective, and if it's more than 2 milliseconds early, a $300,000 servo table is going to crash into its bearings and cause a $10,000,000 assembly line outage."
The system you described can be solved with JMS.
Use a pub-sub JMS queue to assign the work. The "boss" is the publisher. Each member of the staff is a "subscriber".
The "boss" will need to store each message it publishes in a "check back" area (perhaps a list) and set a timer for 10 minutes. When it gets a response to a message, it will clear the timer and remove the message from the "check back" area.