I've seen that there is tons of posts like this, but couldn't find one that helps me.
I've read in one of them that this a generic error, and it depends on what you are doing.
In my case, I've created a socket, got its input and output stream and use the output to send some data. The strange thing is that I can send things and the server receives them. But I get this error pretty often. Like, once every 5 minutes.
Don't know if might help, but at first I had the soTimeout of the socket as 10 seconds. After reading some articles, I've increased it to 1 minute.
Don't know if I can add code that helps, because I litterally have the error when I do
output.write(byte[])
but if you think it might be something I could add, feel free to ask
Thanks in advance
Related
I am currently working on a small scale project to prove something works, I currently have a smart band device which has an Android SDK.
From this device I use the SDK to track a users heart rate in real time.
So my Android application receives updates to the heart rate in real time.
This was fairly easy to do however I now need to send this data in real time from the Android device to the server as efficiently as possible.
To start with battery drain is OK as initially this is just a proof of concept.
I have limited experience with sending large amounts of data to a server in real time and I was wondering if anyone has an ideas on what might be the best approach on Android?
I have looked into Sync Adapters but these seem to be more about keeping data aligned between the client and the server, this is something I am not concerned about. Another approach would be to see if the RequestQueue from Volley might work but again I am unsure if looking into this is even worthwhile?
Should I be looking into creating a Service and somehow using a socket to transfer the data?
EDIT: It looks like IntentService may be the best option for handling the task execution but I am assuming http requests would be too heavy for the client and I should look into something else for the transfer?
I am working on similar kind of project but the wrist band I am dealing with is Empatica E4. Please bear in mind that I am not an expert developer, therefore I am also looking forward for corrections in my design. Also, I will try to justify my idea step-by-step and as much as I can. I hope that this will give you some hints for your application and help others as well.
So, my current architecture looks like;
First of all, Empatica has also provided an Android SDK to receive the data. SF stands for Sampling Frequency whereas EDA, Temp, BVP and AccXYZ are my sensors in wrist band. Each sensor has different sampling frequency and the maximum is 64 Hz which gives you 15 ms interval between each samples. This interval is quite challenging to perform all the operations, therefore I buffer the sensors data in (Volatile LinkedBlockingQueue) FIFO queue so that I don't miss any sample. This was all happening in the service of my application.
Now, I have a Runnable task that I have used with ScheduledExecutorService to collects samples from the queue with the interval of 250 ms (you can vary it as per your need but I used 250 ms considering my needs, network latency and the device performance) and put them in a single JSON object. Number of samples that this Runnable task collects are varying for each sensor, which are, BVP: 16 samples, AccXYZ: 8 samples, Temp: 1 sample and EDA: 1 sample. At the output, I have a JSON object with the data to be sent to my server.
For transferring data to my server, I am using HTTP POST request. The reasons are easy, fast, efficient and good for concurrency. I am using Volley framework which will handle all my network related issues by itself. So I just add the JSON object in the Volley RequestQueue and my client is done here. As you mentioned, you can use socket connection to achieve your goal but I have to use multiple devices, therefore in my case, sockets can be problematic to achieve concurrency. I also tried to do it manually by using HttpURLConnection but the code was becoming tedious and hard to handle.
Finally, I have a REST API (in Python) on my server side which will handle the POST requests, parse the data and insert it in my MySQL database. As of now, I am still working on this REST API to parse the data and store it in DB. However, I have tested my application and I am successfully receiving the data from my device to the server.
Regarding your question "Should I be looking into creating a Service and somehow using a socket to transfer the data?", it's an excellent option if you are working on a single device. If more than one device, i think Http is better option.
Regarding your second question, I don't think Http would be heavy for the client and Volley is taking all your pain on itself. You just have to make a request queue and voila !!! You can find plenty of good tutorials for volley and I particularly followed this.
I hope my answer will help you a little.
PS: As I am still working on this thing and I have not come up with the final product yet, therefore I cannot surely tell about the risks involved in it but I will keep you updated if something new happens. Also, I am open to any suggestions and ideas that can help. Lastly, the picture above is not very detailed, I made it for you, just to share how I am dealing with the same idea.
I have a simple piece of code that creates an AudioRecord object, then uses it to record to a file. It is pretty standard and seems to work perfectly fine. I am using a Samsung GalaxyS Vibrant running stock Android 2.2.
However, I am getting messages such as these in logcat at different intervals:
04-13 14:03:30.754: V/AudioRecord(4831): Overrun user: 820, server: 1040, flowControlFlag 0
04-13 14:03:30.766: V/AudioRecord(4831): Overrun user: 820, server: 1040, flowControlFlag 1
Does anyone know what these mean? Am I overrunning the internal audio buffer and losing audio frames? It doesn't seem like it from the recorded file, but these intermittent messages are worrying me a bit.
This might be a little late, but this is merely a log message (not specifically Samsung, I've seen it with different makes, models & brands) telling you that you've started recording, but are not reading out the data from the AudioRecord.
Hence the Overrun user, the AudioRecord's buffers are full.
it seems this is an internal log used by some samsung devices. So you can not hide them but it is not harmful either. If you dont want to see it you can just filter out this from your logcat
Check your permissions.
<uses-permission android:name="android.permission.RECORD_AUDIO"></uses-permission>
this permission is necessary
I think is because read pcm data too slow, I faced the same question, when I do a little sleep between two read operations, this log become more when I set the sleep time longer.
So I think there is 2 ways to resolve this problem:
1.make read operation quick
2.make the buffer bigger, when you new a AudioRecorder set last para to 2*minBufferSize or bigger. It can allow you read more data every read operation.
Hope your can understand that, sorry for my poor english.
I am currently using an InputStream in my application (import java.io.InputStream) and have run into an issue regarding timing out. The way the InputStream seems to work is that it waits for a certain amount of bits and then proceeds. For my application this works a lot of the time, but there are cases where I am expecting the read to fail due to timeout. Does anyone know a way to do this?
I have found many examples of creating threads to run alongside the read() function and cancel it, but I was wondering if there is an existing class which lets me use an InputStream that times out.
This largely depends on where you are reading from. If it is from a file (or local) socket, there is no timeout. If it is from a remote socket, you can specify timeout when creating the socket. If it times out you should get an exception. Using threads/AsyncTask is the way to go, but you generally cannot interrupt a blocked read, unless you are using Java NIO.
And no, it is not ridiculous, how do you propose for it to 'time out on its own'? Someone has to signal the timeout, and that someone is either some sort of monitor thread or the OS raising an error.
I would use AsyncTask<> for this. You can try to start reading the stream asynchronously and then at a time of your choosing cancel the task, rather than blocking your UI. Documentation here
I have a similiar situation like this: How do I handle/fix "Error getting response stream (ReadDone2): ReceiveFailure" when using MonoTouch? but I'm only GETing a list, not posting anything in the body.
Furthermore, I'm using RestSharp, and it works in almost all the cases, but every once in a while I receive Error getting response stream (ReadDone2): ReceiveFailure.
What can possibly be the problem?
(ps: the exact same code on Wp7 doesn't cause any errors)
There is a bug report (https://bugzilla.xamarin.com/show_bug.cgi?id=19673) which appears to have a reproducible example. So, at the least, you could add yourself to the CC list for it.
(BTW, I get the error (also using restsharp) under Linux (Mint/17, Mono 3.2.8), so it is not specific to Android. It is hard to reproduce: for me it is simply happening after between 1000 and 10,000 web service calls, and it always works when restarting. I am not seeing a CPU or memory problem. It could be some buffer build-up, or might simply be a network failure, or even remote server problem?)
New to stackoverflow, been very helpful searching, but alas the time has come to ask a question.
I am trying to use an android 2.2 single core phone to do some research. I have implemented an algorithm that does quite a few calculations and produces a lot of data. These data must be processed, and the solution presented back to a client app within a 40ms time frame, then process again with new state data coming from the client. Also, the result of the calculations must be stored to the SD card as a data log. So being new to multithreading and android both, what should I use to do the following in my app: (As a side note, this phone, when in research mode is not intended to be used as a phone, phone will be in airplane mode with wireless off, and all apps that can be turned off will be turned off, and there is no need for UI display or interaction once it is up and running...)
need to process packets coming in over adb on serial port, these packets are state data that the program needs to perform its calcs on. These packets will be coming every 40ms, so I planned on using their arrival to trigger the start of the processing.
need to know if the algorithm is taking longer than 40ms and cancel it if so and send a message back on the serial port that it overran.
the calculation results need to be sent back over the serial connection via tcp and adb
The calculation intermediate data need to be recorded to SD. This can be quite a lot of data, on order of 140k, every 40ms.
So I have had trouble getting all the pieces together. I can't get my head around how a single core is going to keep up with all this going on at once?
So here is my thought, please tell me if I am headed in the right path. I am not asking for you to solve my problem, only any advice on how to break this beast down:
So i start a service to process the tcp packets coming in from the client
Use a service bound to the main worker thread to handle writes to the SD card
So assuming this setup, can i make the algorithm part of this somewhat deterministic so that it always runs if it gets a new tcp packet, and preempts the SD write going on in the background?
Argh...should have picked something simpler for my first program
Thanks.
Yes I think you are right, that it would be better to pick something easier for your first App ;)
But as far as I understand what you are trying to do, I don't think, that you need asynchronous multiprocessing. You get some data want to process it and pass a result. I think a HandlerThread is exactly what you are looking for. It is able to recieve Messages
with data inside. You send them to the Handler and process them in an overridden handleMessage(Message m) method. So everytime you recive a Message you could just log the Time
and see if the last one is older than your limit. If it is, you could just throw the Message or the whole queue, or send a Message to your serial-port inicating the overflow.
This could be implemented as you suggest in a Service. Another HandlerThread can be started with Thread.PRIORITY_BACKGROUND to write everything to SD.
You can send Messages even very compfortable if you apply a Messenger to the Handlers