Jim,
I checked out the code and made some quick tests with the expected correct
results.
Thanks
Stefan
semog wrote:
>
> I made the change in the code to turn this on by default based on your
> contribution. I made a few minor tweaks for .NET 1.1, but that's about
> it.
> Thanks for catchin
Hi Stefan,
The point of Java having this setting on by default is very strong. Also,
the point that both sides needs to be turned on in order for it to be
effective makes a lot of sense, and also agrees with my observed test
results.
I made the change in the code to turn this on by default based
Hi Jim,
semog wrote:
>
> First, I would like to keep the default TcpNoDelayEnabled setting as
> false, rather than changing it to true. Without knowing how it will
> impact other users, I think this is safer, and for those who want to tune
> their connection, they can do so. If you can clarif
I re-worked the sample test code that Stefan posted so I could use it to test
my changes. I'm not sure really how to turn this in to a unit-test, since
it's simply an implementation evaluation test tool, and not really a
validation test. Anyway, I had to change to use high-resolution timers,
bec
Jim,
> "transport.TcpNoDelayEnabled=true"
seems perfect to me.
Vadim.
On Thu, Aug 28, 2008 at 11:15 AM, semog <[EMAIL PROTECTED]> wrote:
>
> I took a look at your changes, and I think they are very good. However, I
> want to discuss some changes I made to them to accommodate some of the
> const
I took a look at your changes, and I think they are very good. However, I
want to discuss some changes I made to them to accommodate some of the
constraint requirements that NMS has, as well as to safely introduce these
changes.
First, I would like to keep the default TcpNoDelayEnabled setting a
Hi Stefan,
Thanks for fixing the license. I'll take a look at the code changes. This
is one of those areas where I think we have the potential for speeding up
the code, but also the potential for creating subtle problems. I'd like to
make sure that these changes get tested very closely.
The ch
Hi Jim,
Sorry, but I simple overlooked the license agreement. I uploaded the patch
again with the ASF license.
I think adding the option to the URI is a good thing but Open Wire already
negotiated the NoDelay option at connection start up. Unfortunately NMS
hasn't yet supported this option so b
2008/8/28 Vadim Chekan <[EMAIL PROTECTED]>:
> Would it be property of connection or transport?
> I thought connection means JMS connection and it has nothing to do with TCP.
FWIW a JMS Connection typically has a TCP connection underneath. We
often use the connection URL to configure things like tr
Would it be property of connection or transport?
I thought connection means JMS connection and it has nothing to do with TCP.
Vadim.
On Wed, Aug 27, 2008 at 10:33 PM, Jim Gomes <[EMAIL PROTECTED]> wrote:
> Since I couldn't look at your code because of the license grant issue,
> I looked in to wha
Since I couldn't look at your code because of the license grant issue,
I looked in to what you had mentioned about the NoDelay option. I
took a stab at adding support for turning this (and several other
socket transport options) on and off from the connection URI. Once
you fix the license grant,
Hi Stefan,
Thanks for creating Jira AMQNET-109 and attaching the patch. However,
the Grant ASF License option was not checked. Would you re-attach the
patch and check that option? I can then look at integrating it into
the codebase.
Thanks!
-Jim
On 8/26/08, Stefan Gmeiner <[EMAIL PROTECTED]
I had similar results as yours when performance testing NMS. You may want
evaluate IKVM for C# integration. Using IKVM, I had 4 times the message
throughput than NMS. Also, the converted jar -> dll gives you access to the
full JMS API for your C# producers and consumers.
Stefan Gmeiner wrote:
>
13 matches
Mail list logo
