InputStream problems on the 6680

[iandebeer]

I have an application that does an HTTP post using the Hessian protocol. The servlet receives the request correctly and responds by sending a byte array to the client. I have no problem in reading the the response on phones such as Nokia 6600, Nokia 6230i, Motorola E1000 etc. For some reason I do not get any data when I read the InputStream on the 6680. What is different on the 6680?
There has been a number of post on the forum that seems to suggest that the 6680 is misbehaving. Has any one managed to find what the problem is and suggest a work-around?
Regards
Ian

[wipfunk]

.. as you can see in last messages, this is a big problem that seems not to have solution.. (..until NOKIA does not give one answer..)..
ATTENTION this problem persist also on 6630 with new firmaware !!
bye
nico

[Danack]

There has been a number of post on the forum that seems to suggest that the 6680 is misbehaving. Has any one managed to find what the problem is and suggest a work-around?

I've seen on a 6680 that the phone fails to read chunk encoded http streams.

Basically it reads all the data but then sits there waiting for more to turn up.

The 'workaround'* is to use a datainputstream instead and use the available function (after the first bytes are read)

while ((bytesReadTotal != bytesToRead) && (bytesRead != -1)) {

if (bytesReadTotal > 0 &&
inputStream.available() <= 0){
bytesRead = -1;
}
else{
bytesRead = inputStream.read( response, bytesReadTotal, bytesToRead - bytesReadTotal);
if (bytesRead != -1){
bytesReadTotal += bytesRead;
}
}
}

You could also try using DIS.readFully(byte[] b,int off, int len)

cheers
Dan
Ack


*workaround in quotes as I haven't tested it on large streams ie that are going to be chunked into more than one chunk, and hasn't been tested for reliability.

[wipfunk]

..thanks a lot..
..now i can't test it , but I hope to make it the beginning of the next week !
bye
nicola palmieri

[iandebeer]

I tried this and other workarounds without any success.

[kakoskin]

If you are reading chunks (e.g. 512 bytes at time) then you can presume that the end of stream is reached when you first time don't get the full chunk.
However not a nice way to do it but that's only way if have got it working.

[dcrocha]

Can somebody please post the code?

Daniel

[njzk2]

did you tried to basically read the inputstream like :

<code>
int b;
while ((b = inputStream.read()) != -1) {
//do something with this int, like putting in into a byte array
}
</code>

[freak3]

hi,

i am having a similar problem:
my app tries to read some data from a server by calling a servlet there, the data is tranfered via http-headers. when using a german t-mobile simcard there is no problem, the app work on other phones too.
only when using a austrian a1-simcard the call http-request does not reach the server, which in turn does not respond. i can see that the gprs-counter is counting, appearantly the amount of data transfered between the phone and the machine that is configured in the apn. but there is no call to my server from that machine for some unknown reason. as i said, this only happens with the a1-card but, strangly, no problem appears when i use this card in some other phone, e.g. 6600.
has anyone encountered this kind of problem ?

tia eddi

[fgomezm]

I am having the same problem and I believe the problem has to do with the Java virtual machine in the 6680. Does anybody know if there is a fix for it?

[ipp0]

Hi,

I have a N90 which seems to have the same problem. I managed to work it out like this

in = conn.openDataInputStream();
byte[] data = new byte[300000];

// You really should to this with while(true) -loop but there seems to be a bug
// in Nokia's inputstream implementation (somehow it doesn't recognize the
// EOF), so you just have to trust that all of the
// inputstream's data gets read at once or handle a possible failure in some
// other manner
in.read(data, offset, data.length);

After this data hopefully has all of the requested data.

[njzk2]

this might work if all the data is available when you read it.
but if the whole data is not here yet, you will not read it all, and data that arrive later will stay in your inputStream
i suggest you put some kind of control there, like giveing the size of the data previously to send the data if you have the and on the server part

[ipp0]

Since I can't get my hands on the server code I think that is the only possibility to get the contents of the inputstream (in this case a png image). Somehow it seems like Nokia have messed up between int InputStream.read(byte[], int, int) and void DataInputStream.readFully(byte[], int, int).

I think this is the case because my example above seems to work flawlessly with my N90 phone and Series 60 FP3 MIDP emulator but not e.g. with WTK2.2.

I think it's kind of lame that Nokia hasn't addressed this because it's clearly quite serious bug in their MIDP implementation.

[agent.yk]

Hi there,

First, I'm glad to join this discussion cuz I spent alot of time surfing the net to solve this prob!

After performing many tests and reviewing wt u've guys wrote down there, I reached the following results:
1. This problem starts to appear since 6680 and following model (N series..) which basicly works on Symbian V8.x, while earlier versions (like 7610 which is v7) works fine with it.
2. I think the prblem is not matter of length, cuz when I've tested this code:

int ch,x=0;
ByteArrayOutputStream bStrm = new ByteArrayOutputStream();
while ((ch = is.read()) != -1 || x<45) {
  bStrm.write(ch);
  x++;
}

And previously managed the server to send exactly 50 bytes, so when I run this code and output bStrm.size() it should give me 50, and that realy happened wth the simulator, bt in the phone it gives me 45, means that It receives NULL value and just keep iterating till finish the assigned homework! (the 2nd condition of if statement).

Is it really a bug in the implementaion of the Vitual Machine??! Actually I think this shuoldn't be the reason cuz how do we explain the continuous emerging of this problem in newer models?!..

Any comments??
Y2K!

[fgomezm]

After a lot of different tests I managed to have a work-around for the input stream problem in the 6680. The solution is not elegant but it seems to work (under certain conditions, see below).
First of all, I should say that this seems to be a bug in the j2me implementation of the 6680 (the same Midlet works without any problem in a 6670). It is really amazing that Nokia does not react on this problem. If anybody knows a way to upgrade a 6680 terminal to fix the problem, please let me know.

The solution consists in using a SocketConnection rather than an HttpConnection but rather than closing the output stream after making the request, you use OutputStream.flush() to send the data but you leave the output stream open. As long as you do not close the OutputStream of the connection, the data keeps getting in to the DataInputStream. The key code is more or less like this:

os= c.openOutputStream();
os.write(request.getBytes());
os.write(authorization.getBytes());
os.write(useragent.getBytes());
os.write(contentlength.getBytes());
os.write(host.getBytes());
os.flush();

(Note: request, authorization, etc. are objects of type String that you have previously filled in with the right data).

is = c.openDataInputStream();

//here you must parse the response headers and then read the
//continuous data input stream
parseHttpHeader(is);

Problems of the solutions:
1- Apparently, not all phones support SocketConnection thus you may end up with situations in which this does not work.
2- If you use SocketConnection rather than HttpConnection the virtual machine does not allow you to open connection to port 80 (it gives you a SecurityException). This seems weird to me (why other ports are allowed but port 80 is not?). I assume that if the Midlet is properly signed this problem can be worked-around but I have not tried this out yet (any suggestion to circumvent the problem will be welcome).

If anybody needs more information, do not hesitate to contact me.

BR,

Paco Gomez