Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Highlighted
New Developer
Posts: 5
Registered: ‎03-04-2009
My Device: Not Specified

HttpConnection flush() is broken (still)

I know this has been brought up before, but why does any OutputStream provided by a HttpConnection close when you call flush() on it?  I read in an earlier thread about how it only supports HTTP 1.0, etc, etc, but this is still not an explanation as to why calling flush() on it closes it.

 

The JavaDocs for java.io.OutputStream clearly state that if an OutputStream is an abstraction, flush does NOT have to push the bytes to the ultimate destination, so long as they are cached.

 

I've wasted a good 2 days trying to figure out what I assumed was a bug in GZipOutputStream only to discover that another part of my code was calling flush() on the GZipOutputStream which was in turn wrapped around the HttpOutputStream.

 

This is a well-known issue.  If you're not going to fix it then why is it not documented ANYWHERE?  PLEASE!

New Developer
Posts: 5
Registered: ‎03-04-2009
My Device: Not Specified

Re: HttpConnection flush() is broken (still)

Incidentally, here's some sample code that demonstrates the problem:

 

public static void main(String[] args) throws Exception {

HttpConnection c = (HttpConnection) Connector.open("http://www.google.com");

OutputStream out = c.openOutputStream();

out.write("HEAD /intl/en/about.html HTTP/1.1\n".getBytes());

out.flush();

out.write("\n".getBytes());

out.close();

New Contributor
Posts: 3
Registered: ‎05-25-2011
My Device: Blackberry
My Carrier: AT&T

Re: HttpConnection flush() is broken (still)

Sorry to resurrect such an old thread, but if anyone is watching, does this issue still exist?  I seem to be running into it.  Any known workarounds?

Developer
Posts: 29
Registered: ‎05-23-2011
My Device: Curve
My Carrier: 8520

Re: HttpConnection flush() is broken (still)

[ Edited ]

I didn't understand very well, but I use the this code for example

 

try {
					connection = (SocketConnection)Connector.open(_url, Connector.READ_WRITE, false);
					_in = new InputStreamReader(connection.openInputStream());
					_out = new OutputStreamWriter(connection.openOutputStream());
					
					_out.write(data, 0, data.length());  
					_out.write('\n'); //write a terminator 
					
					_out.flush();
					_out.write('.');
					_out.write('\n');
					_out.flush();

 and the only problem i have is that on the receiver side the tcp package is broken. So u have to listen to a special character

 

code for a sample server

		try {
			// Get input from the client
			System.out.println("Server building message");
			DataInputStream in = new DataInputStream (server.getInputStream());
			PrintStream out = new PrintStream(server.getOutputStream());

			// receive the first loation
			while((line = in.readLine()) != null && !line.equals(".")) {
				input=input + line;
				System.out.println(input);
}
			System.out.println("closing");
			server.close();
		} catch (IOException ioe) {
			System.out.println("IOException on socket listen: " + ioe);
			ioe.printStackTrace();
		}

 

a short example:

if you sent on the client the String "abdef." and on the server side you only have

while((line = in.readLine()) != null)

 the server will close and print out only the String "a" because the TCP package is broken. I checked this out with wireshark and u receive two TCP package of those the second package includes the rest of the data. So in total with 

			while((line = in.readLine()) != null && !line.equals(".")) {
				input=input + line;
				System.out.println(input);
			}

you will get the complete String "abcdef"

 

maybe this could help you a bit

New Contributor
Posts: 3
Registered: ‎05-25-2011
My Device: Blackberry
My Carrier: AT&T

Re: HttpConnection flush() is broken (still)

Doesn't look like you're using HttpConnection in that example.

Developer
Posts: 29
Registered: ‎05-23-2011
My Device: Curve
My Carrier: 8520

Re: HttpConnection flush() is broken (still)

ohh, well, youre right, i havent seen that, sorry ... next time i should read better before answering Smiley Tongue

Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: HttpConnection flush() is broken (still)

I'm confused by this.  But I'm no http expert, so perhaps this is just my misunderstanding. 

 

When you send an http connection, it is a single packet of data.  That is how http works.   A flush asks the connection to send the data, an http packet is a single packet so that is the end of it.  

 

So why would you code a flush in the middle of  creating the packet?  Why not just wait to the end?

New Contributor
Posts: 3
Registered: ‎05-25-2011
My Device: Blackberry
My Carrier: AT&T

Re: HttpConnection flush() is broken (still)

I'm doing streaming of audio to a web server (using chunked-transfer encoding).  The data is dynamic and variable-sized, and I need to start sending captured data as soon as I can for performance reasons.

 

See: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1

 

Basically, I want to capture a certain amount of data (say, 1k of captured audio) and then transmit it to the server, rinse and repeat.

 

I'm not sure I follow your 1-packet (TCP packet?) reasoning -- The RFC makes no mention of packets (afaik, you could send an http request in hundreds of little 1-byte packets).

Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: HttpConnection flush() is broken (still)

[ Edited ]

Sorry, packet was the wrong choice of words.  I was merely pointing that most http requests are a single transmission from the BlackBerry.  I called that single transmission a packet.  It was the wrong word.  I should probably have called it a block.  I hope you understand that I was talking at an application level and not the TCP level. 

 

I've never streamed data from a BlackBerry nor used the chunked transfer encoding.  My experience with this sort of thing has always involved sending blocks at a time. 

 

But having looked at it I see why you are asking the question.  And sorry, I don't know if flush will, as far as the BlackBerry is concerned, complete the http connection block.  

 

I suspect that the BlackBerry will buffer all http requests until they are complete and has limits on the sizes of data that can be sent because of this approach, which presumably comes out of a desire to minimize bandwidth usage.  I suspect the RIM developers did not envisage the Blackberry being used as a streaming Server.  But I don't know this for a fact.

 

Good luck with your development.     .