Sorry to keep bumping my own post, but I'm becoming very convinced
that this is an issue with the 1.5 JVM on PPC OS X. I've been sending
very large datasets though on various workstations, and the program
behaves perfectly. At this point, I'm going to concentrate on getting
this project ready for
Code pasted like crap for some reason. You can see it here:
http://pastebin.com/f736205f2
On Jun 1, 10:05 pm, tmountain wrote:
> I took your advice and pulled my streams up front. This did seem to
> offer a small performance benefit, but the issue persists. I've
> greatly simplified the reader f
I took your advice and pulled my streams up front. This did seem to
offer a small performance benefit, but the issue persists. I've
greatly simplified the reader function to ensure that there's nothing
stupid going on there causing the erratic behavior.
(defn connection-read [#^DataInputStream
co
I don't know how relevant this is to what you're trying to do, but
I've recently written something that sounds like what you're doing. My
approach was to always send the size of the file (this involves
sending chunks of a file around) to the server before sending the
file. Since read() will block
I'm not sure if that's related to the problem either, but it may very
well improve performance. Thanks for the suggestion. I will try
opening the streams ahead of time and see where that takes me.
On Jun 1, 10:20 am, MikeM wrote:
> I don't know if this is part of the problem, but you appear to b
No, it does not call flush. Should I call it everytime a write is
performed? If so, will this have a negative impact on performance?
Even if it does, it seems calling flush may be unavoidable?
(defn connection-write [#^Socket conn #^bytes data]
"writes data to the specified socket"
(let [#^Ou
Great! That largely indicates that we are reading the right amount of
data. So I'm thinking (connection-write) doesn't call flush?
On Jun 1, 11:30 pm, tmountain wrote:
> You're correct. Debugging with print statements shows that the
> otherwise clause is never being reached. That being said, si
I don't know if this is part of the problem, but you appear to be
calling getInputStream repeatedly on the socket. I think more
typically the socket connnection is established, input and output
streams are obtained one time only, then the streams are used as
needed for the duration of the connecti
On Mon, Jun 1, 2009 at 3:30 PM, tmountain wrote:
>
> You're correct. Debugging with print statements shows that the
> otherwise clause is never being reached. That being said, simply
> inserting a Thread.sleep(0) before the data is returned makes the
> program behave properly. If I remove that sl
You're correct. Debugging with print statements shows that the
otherwise clause is never being reached. That being said, simply
inserting a Thread.sleep(0) before the data is returned makes the
program behave properly. If I remove that sleep, the client gives back
a malformed packet response. It s
Hi Travis,
Indeed. I re-read your code and think I have a clearer understanding
of your intent now:
You have an open TCP connection down which 'messages' are being sent
which are prefaced by 'data length'. The 'messages' should be handled
one at a time.
So regardless of the maths
; oth
Thanks for the response. You are correct that there are issues with
the subtle maths in the "otherwise" portion of the code. I fixed that
issue, and it improved the situation somewhat; however, I was still
forced to insert a Thread.sleep inside of connection-read to get
predictable results. This p
Hi Travis,
connection-read appears to be subtlety wrong.
If all the bytes are ready to be read then it is correct, but if only
some are read it is incorrect. Now in the large data scenario the
latter will appear if there are no delays. Inserting a sleep delays
the program per packet such that the
Hi all - I'm in the process of writing a proxy for MySQL in Clojure,
and until now everything has been going smoothly. My project has
reached the point where it can shuffle data up and down the wire
between client and server with accurate results, but I'm running into
a strange issue. I've noticed
14 matches
Mail list logo
