Test coverage documentation in MINA to promote more collaboration (Was: Re: mina and jdk6u4)
I've been noticing and hearing many complaints about the amount of tests and
overall coverage in the MINA code base. If there was more coverage
contributors and committers would feel much more comfortable making changes
knowing they're not going to break something.
At some point we need to stop growing the code base like mad and just start
documenting and thoroughly testing the code. Otherwise as we grow the
barrier of entry into the heart of MINA especially will increase.
Alex
On Feb 13, 2008 12:00 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-02-01 (금), 13:57 +0100, Emmanuel Lecharny 쓰시길:
Makoto YUI wrote:
I have the same problem to you.
I'm using the latest snapshot (
mina-core-2.0.0-M1-20080124.103130-116.jar).
| java.lang.ArrayIndexOutOfBoundsException
| at
org.apache.mina.util.CircularQueue.shrinkIfNeeded(CircularQueue.java
:233)
This problem caused when newLen is less than the length of
System.arraycopy().
| Object[] tmp = new Object[newLen];
| ..
|if (first last) {
|System.arraycopy(items, first, tmp, 0, last - first);
* bug
|} else {
|System.arraycopy(items, first, tmp, 0, oldLen -
first); *
bug
|System.arraycopy(items, 0, tmp, oldLen - first,
last);*
bug
|}
It seems to be preferred to use java.util.LinkedList instead of custom
CircularQueue
for messageQueue(s) in
AbstractProtocolEncoderOutput/AbstractProtocolDecoderOutput.
Thanks,
Makoto YUI
I don't think that it's a problem to use our own brewed CircularQueue
...
I looked at the code, and I'm a little bit annoyed that there is
absolutely no comment at all. There is a clear bug somewhere, as you got
a java.lang.ArrayIndexOutOfBoundsException (and many thanks for having
posting this mail, btw !!!), but without a knowledge about what is doing
this class, it's really difficult to find a fix in 2 minutes. This
should not be the case...
Btw, there is no test cases either...
I wrote that evil code hehe. :)
There's test case for CircularQueue in 1.x branch, but it was removed
from the trunk when I replace it with LinkedList. After then, I
realized the CircularQueue implementation performs better than
LinkedList, so I resurrected it. However, I forgot to resurrect the
test case together. Will take care of this when I get back home.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Blocking DNS queries (Was: Re: [AsyncWeb] Ideas for client)
2008-02-12 (화), 23:57 -0700, Mike Heath 쓰시길: 이희승 (Trustin Lee) wrote: 2008-02-12 (화), 11:16 -0700, Mike Heath 쓰시길: Eero Nevalainen wrote: Btw, what was the status of DNS resolution in MINA? I remember that at some point DNS resolving used the blocking java API calls. I could imagine that an asynchronous HTTP-client would have to perform a lot of DNS queries(or not, depending on use). Could this become a pithole? That's a very good point, Eero. I think blocking DNS lookups could definitely be a very big pit hole. Did anything ever come from all the asynchronous DNS lookup discussions? And that's not the only DNS issue. If a DNS returns multiple A records for a given host name, most browsers will try to connect to the IP address from the first A record. If that fails, they'll try the next IP address and so on until the connection succeeds or all of the A records have been exhausted. We should support this same behavior in AsyncWeb. I thought it's the operating system who decides which A record to use and it's often random round-robin style. Is there any related documentation or is it from your experiment? Just curious. The way Mozilla browsers handle DNS Round Robin is explained here http://www.mozilla.org/docs/netlib/dns.html under the Round Robin Support section. It would be nice to have a built in DNS lookup mechanism in MINA as we discussed in our previous discussion, but once the domain name is resolved, it will be cached by the operation system, so it shouldn't be a big problem in most cases. It will of course be a problem if someone is writing a web robot or something similar. I do agree that in most cases it won't be a problem. Thanks for the link to the documentation. So, I guess we need some pluggability in domain name resolution. For now, we are using InetSocketAddress and as long as we depend on it, we don't have any control over how domain name is resolved in MINA. This mean that we need to provide our own endpoint representation classes. It will probably cause the major API change, but I think it worth to do this. How does that sound? Will we need to implement this in 2.0 or... in 3.0? :) -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
Usage of SimpleIoProcessorPool in MINA 2.0
Hi all, I'm porting from MINA 1.1 to 2.0 and trying to convert this: SocketConnector connector = new SocketConnector (processors, executor); to the 2.0 equivalent. Since there's no constructor that takes a processor count and an executor, I looked at SimpleIoProcessorPool, and tried: SocketConnector connector = new NioSocketConnector (new SimpleIoProcessorPoolNioSession (NioProcessor.class, executor, processors)); This is what's recommended in the javadoc for SimpleIoProcessorPool, but since NioSession isn't public, it won't compile. What I really want to be able to do is share an Executor across several services, not have it managed by MINA. Matthew.
Re: Test coverage documentation in MINA to promote more collaboration (Was: Re: mina and jdk6u4)
Oh yeah, that's a good idea. We have been stepping on the accelerator
for a very long time to implement new features and improve performance,
so it seems like it's time to take care of stability.
One problem is that most bug reports these days are not easy to
reproduce, which means they are related with high concurrency situation
and unit tests cannot be the way to find many potential bugs, although
CircularQueue issue is probably detectable by a unit test.
The best solution would be to have a kind of regression test lab within
the ASF so we can run some exhaustive tests preiodically and share the
facility with other projects like HTTPD and Directory. I don't think it
will happen soon though.
Anyways, we need to raise the coverage rate on and on.
2008-02-13 (수), 03:23 -0500, Alex Karasulu 쓰시길:
I've been noticing and hearing many complaints about the amount of tests and
overall coverage in the MINA code base. If there was more coverage
contributors and committers would feel much more comfortable making changes
knowing they're not going to break something.
At some point we need to stop growing the code base like mad and just start
documenting and thoroughly testing the code. Otherwise as we grow the
barrier of entry into the heart of MINA especially will increase.
Alex
On Feb 13, 2008 12:00 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-02-01 (금), 13:57 +0100, Emmanuel Lecharny 쓰시길:
Makoto YUI wrote:
I have the same problem to you.
I'm using the latest snapshot (
mina-core-2.0.0-M1-20080124.103130-116.jar).
| java.lang.ArrayIndexOutOfBoundsException
| at
org.apache.mina.util.CircularQueue.shrinkIfNeeded(CircularQueue.java
:233)
This problem caused when newLen is less than the length of
System.arraycopy().
| Object[] tmp = new Object[newLen];
| ..
|if (first last) {
|System.arraycopy(items, first, tmp, 0, last - first);
* bug
|} else {
|System.arraycopy(items, first, tmp, 0, oldLen -
first); *
bug
|System.arraycopy(items, 0, tmp, oldLen - first,
last);*
bug
|}
It seems to be preferred to use java.util.LinkedList instead of custom
CircularQueue
for messageQueue(s) in
AbstractProtocolEncoderOutput/AbstractProtocolDecoderOutput.
Thanks,
Makoto YUI
I don't think that it's a problem to use our own brewed CircularQueue
...
I looked at the code, and I'm a little bit annoyed that there is
absolutely no comment at all. There is a clear bug somewhere, as you got
a java.lang.ArrayIndexOutOfBoundsException (and many thanks for having
posting this mail, btw !!!), but without a knowledge about what is doing
this class, it's really difficult to find a fix in 2 minutes. This
should not be the case...
Btw, there is no test cases either...
I wrote that evil code hehe. :)
There's test case for CircularQueue in 1.x branch, but it was removed
from the trunk when I replace it with LinkedList. After then, I
realized the CircularQueue implementation performs better than
LinkedList, so I resurrected it. However, I forgot to resurrect the
test case together. Will take care of this when I get back home.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
Re: Blocking DNS queries (Was: Re: [AsyncWeb] Ideas for client)
On Feb 13, 2008 10:07 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote: 2008-02-12 (화), 23:57 -0700, Mike Heath 쓰시길: 이희승 (Trustin Lee) wrote: 2008-02-12 (화), 11:16 -0700, Mike Heath 쓰시길: Eero Nevalainen wrote: Btw, what was the status of DNS resolution in MINA? I remember that at some point DNS resolving used the blocking java API calls. I could imagine that an asynchronous HTTP-client would have to perform a lot of DNS queries(or not, depending on use). Could this become a pithole? That's a very good point, Eero. I think blocking DNS lookups could definitely be a very big pit hole. Did anything ever come from all the asynchronous DNS lookup discussions? And that's not the only DNS issue. If a DNS returns multiple A records for a given host name, most browsers will try to connect to the IP address from the first A record. If that fails, they'll try the next IP address and so on until the connection succeeds or all of the A records have been exhausted. We should support this same behavior in AsyncWeb. I thought it's the operating system who decides which A record to use and it's often random round-robin style. Is there any related documentation or is it from your experiment? Just curious. The way Mozilla browsers handle DNS Round Robin is explained here http://www.mozilla.org/docs/netlib/dns.html under the Round Robin Support section. It would be nice to have a built in DNS lookup mechanism in MINA as we discussed in our previous discussion, but once the domain name is resolved, it will be cached by the operation system, so it shouldn't be a big problem in most cases. It will of course be a problem if someone is writing a web robot or something similar. I do agree that in most cases it won't be a problem. Thanks for the link to the documentation. So, I guess we need some pluggability in domain name resolution. For now, we are using InetSocketAddress and as long as we depend on it, we don't have any control over how domain name is resolved in MINA. This mean that we need to provide our own endpoint representation classes. It will probably cause the major API change, but I think it worth to do this. How does that sound? Will we need to implement this in 2.0 or... in 3.0? :) I would say 2.0-M2 Maarten -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: Test coverage documentation in MINA to promote more collaboration (Was: Re: mina and jdk6u4)
I can provide such a lab. I just cannot reveal the contributing party. If
you and others are interested please contact me offline. We've been trying
to prepare a high concurrency environment for ApacheDS specifically so we
can share this with MINA. We just need a solid plan for the
infrastructure.
Alex
On Feb 13, 2008 4:18 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
Oh yeah, that's a good idea. We have been stepping on the accelerator
for a very long time to implement new features and improve performance,
so it seems like it's time to take care of stability.
One problem is that most bug reports these days are not easy to
reproduce, which means they are related with high concurrency situation
and unit tests cannot be the way to find many potential bugs, although
CircularQueue issue is probably detectable by a unit test.
The best solution would be to have a kind of regression test lab within
the ASF so we can run some exhaustive tests preiodically and share the
facility with other projects like HTTPD and Directory. I don't think it
will happen soon though.
Anyways, we need to raise the coverage rate on and on.
2008-02-13 (수), 03:23 -0500, Alex Karasulu 쓰시길:
I've been noticing and hearing many complaints about the amount of tests
and
overall coverage in the MINA code base. If there was more coverage
contributors and committers would feel much more comfortable making
changes
knowing they're not going to break something.
At some point we need to stop growing the code base like mad and just
start
documenting and thoroughly testing the code. Otherwise as we grow the
barrier of entry into the heart of MINA especially will increase.
Alex
On Feb 13, 2008 12:00 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-02-01 (금), 13:57 +0100, Emmanuel Lecharny 쓰시길:
Makoto YUI wrote:
I have the same problem to you.
I'm using the latest snapshot (
mina-core-2.0.0-M1-20080124.103130-116.jar).
| java.lang.ArrayIndexOutOfBoundsException
| at
org.apache.mina.util.CircularQueue.shrinkIfNeeded(
CircularQueue.java
:233)
This problem caused when newLen is less than the length of
System.arraycopy().
| Object[] tmp = new Object[newLen];
| ..
|if (first last) {
|System.arraycopy(items, first, tmp, 0, last -
first);
* bug
|} else {
|System.arraycopy(items, first, tmp, 0, oldLen -
first); *
bug
|System.arraycopy(items, 0, tmp, oldLen - first,
last);*
bug
|}
It seems to be preferred to use java.util.LinkedList instead of
custom
CircularQueue
for messageQueue(s) in
AbstractProtocolEncoderOutput/AbstractProtocolDecoderOutput.
Thanks,
Makoto YUI
I don't think that it's a problem to use our own brewed
CircularQueue
...
I looked at the code, and I'm a little bit annoyed that there is
absolutely no comment at all. There is a clear bug somewhere, as you
got
a java.lang.ArrayIndexOutOfBoundsException (and many thanks for
having
posting this mail, btw !!!), but without a knowledge about what is
doing
this class, it's really difficult to find a fix in 2 minutes. This
should not be the case...
Btw, there is no test cases either...
I wrote that evil code hehe. :)
There's test case for CircularQueue in 1.x branch, but it was removed
from the trunk when I replace it with LinkedList. After then, I
realized the CircularQueue implementation performs better than
LinkedList, so I resurrected it. However, I forgot to resurrect the
test case together. Will take care of this when I get back home.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Test coverage documentation in MINA to promote more collaboration (Was: Re: mina and jdk6u4)
이희승 (Trustin Lee) wrote: Oh yeah, that's a good idea. We have been stepping on the accelerator for a very long time to implement new features and improve performance, so it seems like it's time to take care of stability. I tink that MINA 2.0 is the perfect target for that ! Now that 2.0-M1 has been voted, we can deserve some energy on 2.0-M2 : a 2.0-M1 with better coverage, reviewed documentation, tested, with some more examples. It will cost time, but I'm sure that the community can provide some help ! We have so many users now that everyone of them can also give a little bit of time to improve MINA ! For instance, as we are using MINA at Directory, it would be good to explain how we are using it (configuration and codec implementation). I think that would be helpfull to many users starting with MINA. We will switch to MINA 2.0 soon, and we will try to give such kind of documentation to the MINA project on the same time. One problem is that most bug reports these days are not easy to reproduce, which means they are related with high concurrency situation and unit tests cannot be the way to find many potential bugs, although CircularQueue issue is probably detectable by a unit test. That's true. May be we need some better FAQ for all the users who are asking the same questions. Compiling the Users mailing list and gathering the most frequent questions can help. MINA 2.0 is really a great step forward, it deserves the associated tests, doc and samples ! May be a MINA in Action ? :) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Test coverage documentation in MINA to promote more collaboration (Was: Re: mina and jdk6u4)
LoL! That would be fantastic. :)
2008-02-13 (수), 10:54 +0100, Julien Vermillard 쓰시길:
Hi
BTW is it possible to have an ASF machine with two serial port wired in
loop-back for being able to run automated serial transport tests ?
Julien
On Wed, 13 Feb 2008 04:47:40 -0500
Alex Karasulu [EMAIL PROTECTED] wrote:
I can provide such a lab. I just cannot reveal the contributing
party. If you and others are interested please contact me offline.
We've been trying to prepare a high concurrency environment for
ApacheDS specifically so we can share this with MINA. We just need a
solid plan for the infrastructure.
Alex
On Feb 13, 2008 4:18 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED]
wrote:
Oh yeah, that's a good idea. We have been stepping on the
accelerator for a very long time to implement new features and
improve performance, so it seems like it's time to take care of
stability.
One problem is that most bug reports these days are not easy to
reproduce, which means they are related with high concurrency
situation and unit tests cannot be the way to find many potential
bugs, although CircularQueue issue is probably detectable by a unit
test.
The best solution would be to have a kind of regression test lab
within the ASF so we can run some exhaustive tests preiodically and
share the facility with other projects like HTTPD and Directory. I
don't think it will happen soon though.
Anyways, we need to raise the coverage rate on and on.
2008-02-13 (수), 03:23 -0500, Alex Karasulu 쓰시길:
I've been noticing and hearing many complaints about the amount
of tests
and
overall coverage in the MINA code base. If there was more
coverage contributors and committers would feel much more
comfortable making
changes
knowing they're not going to break something.
At some point we need to stop growing the code base like mad and
just
start
documenting and thoroughly testing the code. Otherwise as we
grow the barrier of entry into the heart of MINA especially will
increase.
Alex
On Feb 13, 2008 12:00 AM, 이희승 (Trustin Lee)
[EMAIL PROTECTED] wrote:
2008-02-01 (금), 13:57 +0100, Emmanuel Lecharny 쓰시길:
Makoto YUI wrote:
I have the same problem to you.
I'm using the latest snapshot (
mina-core-2.0.0-M1-20080124.103130-116.jar).
| java.lang.ArrayIndexOutOfBoundsException
| at
org.apache.mina.util.CircularQueue.shrinkIfNeeded(
CircularQueue.java
:233)
This problem caused when newLen is less than the length of
System.arraycopy().
| Object[] tmp = new Object[newLen];
| ..
|if (first last) {
|System.arraycopy(items, first, tmp, 0,
last -
first);
* bug
|} else {
|System.arraycopy(items, first, tmp, 0,
oldLen -
first); *
bug
|System.arraycopy(items, 0, tmp, oldLen -
first,
last);*
bug
|}
It seems to be preferred to use java.util.LinkedList
instead of
custom
CircularQueue
for messageQueue(s) in
AbstractProtocolEncoderOutput/AbstractProtocolDecoderOutput.
Thanks,
Makoto YUI
I don't think that it's a problem to use our own brewed
CircularQueue
...
I looked at the code, and I'm a little bit annoyed that there
is absolutely no comment at all. There is a clear bug
somewhere, as you
got
a java.lang.ArrayIndexOutOfBoundsException (and many thanks
for
having
posting this mail, btw !!!), but without a knowledge about
what is
doing
this class, it's really difficult to find a fix in 2 minutes.
This should not be the case...
Btw, there is no test cases either...
I wrote that evil code hehe. :)
There's test case for CircularQueue in 1.x branch, but it was
removed from the trunk when I replace it with LinkedList.
After then, I realized the CircularQueue implementation
performs better than LinkedList, so I resurrected it. However,
I forgot to resurrect the test case together. Will take care
of this when I get back home. --
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
Re: Test coverage documentation in MINA to promote more collaboration (Was: Re: mina and jdk6u4)
I think this is a great idea. As someone who was brought onboard to help with documentation as well as coding, I would have a hard time keeping up if this was a full-time job. I think it would make a great deal of sense to work on this for the 2.0 release, since feature creep should be at a minimum right now anyway.. just my 2 cents... On Feb 13, 2008 5:18 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: 이희승 (Trustin Lee) wrote: Oh yeah, that's a good idea. We have been stepping on the accelerator for a very long time to implement new features and improve performance, so it seems like it's time to take care of stability. I tink that MINA 2.0 is the perfect target for that ! Now that 2.0-M1 has been voted, we can deserve some energy on 2.0-M2 : a 2.0-M1 with better coverage, reviewed documentation, tested, with some more examples. It will cost time, but I'm sure that the community can provide some help ! We have so many users now that everyone of them can also give a little bit of time to improve MINA ! For instance, as we are using MINA at Directory, it would be good to explain how we are using it (configuration and codec implementation). I think that would be helpfull to many users starting with MINA. We will switch to MINA 2.0 soon, and we will try to give such kind of documentation to the MINA project on the same time. One problem is that most bug reports these days are not easy to reproduce, which means they are related with high concurrency situation and unit tests cannot be the way to find many potential bugs, although CircularQueue issue is probably detectable by a unit test. That's true. May be we need some better FAQ for all the users who are asking the same questions. Compiling the Users mailing list and gathering the most frequent questions can help. MINA 2.0 is really a great step forward, it deserves the associated tests, doc and samples ! May be a MINA in Action ? :) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org -- Talent hits a target no one else can hit; Genius hits a target no one else can see.
Re: doubt Mina
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
http://www.littleshoot.org
Open Source, Open Standards, Open Data
Re: doubt Mina
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
Re: Test coverage documentation in MINA to promote more collaboration (Was: Re: mina and jdk6u4)
I too would love to see a comprehensive test suite for MINA and I like
the direction this thread is headed.
I have been thinking for a couple of months now that using something
like Amazon's EC2 would be a great test bed. (Except that we couldn't
use EC2 to test the serial transport. :( ) It would be easy to automate
firing up any number of EC2 instances to run different load tests.
Amazon donates EC2 time to BYU, my beloved alma matter. I have a
contact at Amazon. I could him ask about getting EC2 time donated to
the ASF. If there's interest in that, I'll go ahead and fire off an email.
-Mike
Alex Karasulu wrote:
I can provide such a lab. I just cannot reveal the contributing party. If
you and others are interested please contact me offline. We've been trying
to prepare a high concurrency environment for ApacheDS specifically so we
can share this with MINA. We just need a solid plan for the
infrastructure.
Alex
On Feb 13, 2008 4:18 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
Oh yeah, that's a good idea. We have been stepping on the accelerator
for a very long time to implement new features and improve performance,
so it seems like it's time to take care of stability.
One problem is that most bug reports these days are not easy to
reproduce, which means they are related with high concurrency situation
and unit tests cannot be the way to find many potential bugs, although
CircularQueue issue is probably detectable by a unit test.
The best solution would be to have a kind of regression test lab within
the ASF so we can run some exhaustive tests preiodically and share the
facility with other projects like HTTPD and Directory. I don't think it
will happen soon though.
Anyways, we need to raise the coverage rate on and on.
2008-02-13 (수), 03:23 -0500, Alex Karasulu 쓰시길:
I've been noticing and hearing many complaints about the amount of tests
and
overall coverage in the MINA code base. If there was more coverage
contributors and committers would feel much more comfortable making
changes
knowing they're not going to break something.
At some point we need to stop growing the code base like mad and just
start
documenting and thoroughly testing the code. Otherwise as we grow the
barrier of entry into the heart of MINA especially will increase.
Alex
On Feb 13, 2008 12:00 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-02-01 (금), 13:57 +0100, Emmanuel Lecharny 쓰시길:
Makoto YUI wrote:
I have the same problem to you.
I'm using the latest snapshot (
mina-core-2.0.0-M1-20080124.103130-116.jar).
| java.lang.ArrayIndexOutOfBoundsException
| at
org.apache.mina.util.CircularQueue.shrinkIfNeeded(
CircularQueue.java
:233)
This problem caused when newLen is less than the length of
System.arraycopy().
| Object[] tmp = new Object[newLen];
| ..
|if (first last) {
|System.arraycopy(items, first, tmp, 0, last -
first);
* bug
|} else {
|System.arraycopy(items, first, tmp, 0, oldLen -
first); *
bug
|System.arraycopy(items, 0, tmp, oldLen - first,
last);*
bug
|}
It seems to be preferred to use java.util.LinkedList instead of
custom
CircularQueue
for messageQueue(s) in
AbstractProtocolEncoderOutput/AbstractProtocolDecoderOutput.
Thanks,
Makoto YUI
I don't think that it's a problem to use our own brewed
CircularQueue
...
I looked at the code, and I'm a little bit annoyed that there is
absolutely no comment at all. There is a clear bug somewhere, as you
got
a java.lang.ArrayIndexOutOfBoundsException (and many thanks for
having
posting this mail, btw !!!), but without a knowledge about what is
doing
this class, it's really difficult to find a fix in 2 minutes. This
should not be the case...
Btw, there is no test cases either...
I wrote that evil code hehe. :)
There's test case for CircularQueue in 1.x branch, but it was removed
from the trunk when I replace it with LinkedList. After then, I
realized the CircularQueue implementation performs better than
LinkedList, so I resurrected it. However, I forgot to resurrect the
test case together. Will take care of this when I get back home.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: doubt Mina
to example echoserver, how to make this test:
open 2 conection and send message simultaneous? someone did this?
I want to check the performance of the example echoserver.
some tips?
thanks
On 2/13/08, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
Brenno Hayden F. Dantas
Re: doubt Mina
FYI...if you are going to do this...you are gonna have to tweak your IP
stack to be able to handle that many open sockets.
Jeff
[EMAIL PROTECTED] wrote:
to example echoserver, how to make this test:
open 2 conection and send message simultaneous? someone did this?
I want to check the performance of the example echoserver.
some tips?
thanks
On 2/13/08, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Test coverage documentation in MINA to promote more collaboration (Was: Re: mina and jdk6u4)
Swet. Lez do it - keep us posted on this.
Alex
On Feb 13, 2008 12:53 PM, Mike Heath [EMAIL PROTECTED] wrote:
I too would love to see a comprehensive test suite for MINA and I like
the direction this thread is headed.
I have been thinking for a couple of months now that using something
like Amazon's EC2 would be a great test bed. (Except that we couldn't
use EC2 to test the serial transport. :( ) It would be easy to automate
firing up any number of EC2 instances to run different load tests.
Amazon donates EC2 time to BYU, my beloved alma matter. I have a
contact at Amazon. I could him ask about getting EC2 time donated to
the ASF. If there's interest in that, I'll go ahead and fire off an
email.
-Mike
Alex Karasulu wrote:
I can provide such a lab. I just cannot reveal the contributing party.
If
you and others are interested please contact me offline. We've been
trying
to prepare a high concurrency environment for ApacheDS specifically so
we
can share this with MINA. We just need a solid plan for the
infrastructure.
Alex
On Feb 13, 2008 4:18 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
Oh yeah, that's a good idea. We have been stepping on the accelerator
for a very long time to implement new features and improve performance,
so it seems like it's time to take care of stability.
One problem is that most bug reports these days are not easy to
reproduce, which means they are related with high concurrency situation
and unit tests cannot be the way to find many potential bugs, although
CircularQueue issue is probably detectable by a unit test.
The best solution would be to have a kind of regression test lab within
the ASF so we can run some exhaustive tests preiodically and share the
facility with other projects like HTTPD and Directory. I don't think
it
will happen soon though.
Anyways, we need to raise the coverage rate on and on.
2008-02-13 (수), 03:23 -0500, Alex Karasulu 쓰시길:
I've been noticing and hearing many complaints about the amount of
tests
and
overall coverage in the MINA code base. If there was more coverage
contributors and committers would feel much more comfortable making
changes
knowing they're not going to break something.
At some point we need to stop growing the code base like mad and just
start
documenting and thoroughly testing the code. Otherwise as we grow the
barrier of entry into the heart of MINA especially will increase.
Alex
On Feb 13, 2008 12:00 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-02-01 (금), 13:57 +0100, Emmanuel Lecharny 쓰시길:
Makoto YUI wrote:
I have the same problem to you.
I'm using the latest snapshot (
mina-core-2.0.0-M1-20080124.103130-116.jar).
| java.lang.ArrayIndexOutOfBoundsException
| at
org.apache.mina.util.CircularQueue.shrinkIfNeeded(
CircularQueue.java
:233)
This problem caused when newLen is less than the length of
System.arraycopy().
| Object[] tmp = new Object[newLen];
| ..
|if (first last) {
|System.arraycopy(items, first, tmp, 0, last -
first);
* bug
|} else {
|System.arraycopy(items, first, tmp, 0, oldLen -
first); *
bug
|System.arraycopy(items, 0, tmp, oldLen - first,
last);*
bug
|}
It seems to be preferred to use java.util.LinkedList instead of
custom
CircularQueue
for messageQueue(s) in
AbstractProtocolEncoderOutput/AbstractProtocolDecoderOutput.
Thanks,
Makoto YUI
I don't think that it's a problem to use our own brewed
CircularQueue
...
I looked at the code, and I'm a little bit annoyed that there is
absolutely no comment at all. There is a clear bug somewhere, as you
got
a java.lang.ArrayIndexOutOfBoundsException (and many thanks for
having
posting this mail, btw !!!), but without a knowledge about what is
doing
this class, it's really difficult to find a fix in 2 minutes. This
should not be the case...
Btw, there is no test cases either...
I wrote that evil code hehe. :)
There's test case for CircularQueue in 1.x branch, but it was removed
from the trunk when I replace it with LinkedList. After then, I
realized the CircularQueue implementation performs better than
LinkedList, so I resurrected it. However, I forgot to resurrect the
test case together. Will take care of this when I get back home.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Test coverage documentation in MINA to promote more collaboration (Was: Re: mina and jdk6u4)
How many machines would we need? Is this something that could be
virtualized?
On Feb 13, 2008 2:13 PM, Alex Karasulu [EMAIL PROTECTED] wrote:
Swet. Lez do it - keep us posted on this.
Alex
On Feb 13, 2008 12:53 PM, Mike Heath [EMAIL PROTECTED] wrote:
I too would love to see a comprehensive test suite for MINA and I like
the direction this thread is headed.
I have been thinking for a couple of months now that using something
like Amazon's EC2 would be a great test bed. (Except that we couldn't
use EC2 to test the serial transport. :( ) It would be easy to automate
firing up any number of EC2 instances to run different load tests.
Amazon donates EC2 time to BYU, my beloved alma matter. I have a
contact at Amazon. I could him ask about getting EC2 time donated to
the ASF. If there's interest in that, I'll go ahead and fire off an
email.
-Mike
Alex Karasulu wrote:
I can provide such a lab. I just cannot reveal the contributing party.
If
you and others are interested please contact me offline. We've been
trying
to prepare a high concurrency environment for ApacheDS specifically so
we
can share this with MINA. We just need a solid plan for the
infrastructure.
Alex
On Feb 13, 2008 4:18 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
Oh yeah, that's a good idea. We have been stepping on the
accelerator
for a very long time to implement new features and improve
performance,
so it seems like it's time to take care of stability.
One problem is that most bug reports these days are not easy to
reproduce, which means they are related with high concurrency
situation
and unit tests cannot be the way to find many potential bugs,
although
CircularQueue issue is probably detectable by a unit test.
The best solution would be to have a kind of regression test lab
within
the ASF so we can run some exhaustive tests preiodically and share
the
facility with other projects like HTTPD and Directory. I don't think
it
will happen soon though.
Anyways, we need to raise the coverage rate on and on.
2008-02-13 (수), 03:23 -0500, Alex Karasulu 쓰시길:
I've been noticing and hearing many complaints about the amount of
tests
and
overall coverage in the MINA code base. If there was more coverage
contributors and committers would feel much more comfortable making
changes
knowing they're not going to break something.
At some point we need to stop growing the code base like mad and
just
start
documenting and thoroughly testing the code. Otherwise as we grow
the
barrier of entry into the heart of MINA especially will increase.
Alex
On Feb 13, 2008 12:00 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED]
wrote:
2008-02-01 (금), 13:57 +0100, Emmanuel Lecharny 쓰시길:
Makoto YUI wrote:
I have the same problem to you.
I'm using the latest snapshot (
mina-core-2.0.0-M1-20080124.103130-116.jar).
| java.lang.ArrayIndexOutOfBoundsException
| at
org.apache.mina.util.CircularQueue.shrinkIfNeeded(
CircularQueue.java
:233)
This problem caused when newLen is less than the length of
System.arraycopy().
| Object[] tmp = new Object[newLen];
| ..
|if (first last) {
|System.arraycopy(items, first, tmp, 0, last -
first);
* bug
|} else {
|System.arraycopy(items, first, tmp, 0, oldLen -
first); *
bug
|System.arraycopy(items, 0, tmp, oldLen - first,
last);*
bug
|}
It seems to be preferred to use java.util.LinkedList instead of
custom
CircularQueue
for messageQueue(s) in
AbstractProtocolEncoderOutput/AbstractProtocolDecoderOutput.
Thanks,
Makoto YUI
I don't think that it's a problem to use our own brewed
CircularQueue
...
I looked at the code, and I'm a little bit annoyed that there is
absolutely no comment at all. There is a clear bug somewhere, as
you
got
a java.lang.ArrayIndexOutOfBoundsException (and many thanks for
having
posting this mail, btw !!!), but without a knowledge about what is
doing
this class, it's really difficult to find a fix in 2 minutes. This
should not be the case...
Btw, there is no test cases either...
I wrote that evil code hehe. :)
There's test case for CircularQueue in 1.x branch, but it was
removed
from the trunk when I replace it with LinkedList. After then, I
realized the CircularQueue implementation performs better than
LinkedList, so I resurrected it. However, I forgot to resurrect
the
test case together. Will take care of this when I get back home.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
Re: doubt Mina
How to do I do this?
On 2/13/08, Jeff Genender [EMAIL PROTECTED] wrote:
FYI...if you are going to do this...you are gonna have to tweak your IP
stack to be able to handle that many open sockets.
Jeff
[EMAIL PROTECTED] wrote:
to example echoserver, how to make this test:
open 2 conection and send message simultaneous? someone did this?
I want to check the performance of the example echoserver.
some tips?
thanks
On 2/13/08, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
Brenno Hayden F. Dantas
Re: Test coverage documentation in MINA to promote more collaboration (Was: Re: mina and jdk6u4)
Mark Webb wrote: How many machines would we need? Is this something that could be virtualized? With Amazon EC2 you create as many instances as you want so it would give us a great deal of flexibility. Each EC2 instance is virtualized so you're not getting exclusive access to a machine but you do get a certain guaranteed level of service. You can read more about EC2 here, http://www.amazon.com/gp/browse.html?node=201590011 -Mike snip
[jira] Updated: (DIRMINA-530) Compression filter - trivial bug fix and fix for use with SSL
[
https://issues.apache.org/jira/browse/DIRMINA-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin SB updated DIRMINA-530:
--
Attachment: patch-compression.diff
Patch file fixes both issues.
Compression filter - trivial bug fix and fix for use with SSL
-
Key: DIRMINA-530
URL: https://issues.apache.org/jira/browse/DIRMINA-530
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 2.0.0-M2
Environment: N/A? But Mac OS X Leopard (Java 1.5) does display the
issue.
Reporter: Justin SB
Fix For: 2.0.0-M2
Attachments: patch-compression.diff
The compression filter has a simple bug, where it uses limit() instead of
remaining(). Where position != 0, this causes reads to exceed available data:
-byte[] inBytes = new byte[inBuffer.limit()];
+byte[] inBytes = new byte[inBuffer.remaining()];
inBuffer.get(inBytes).flip();
Also, when the compression filter is chained with the SSL filter, and SSL
status notification is enabled, the SSL filter sends state messages through
the chain. These are not IoBuffers, but the compression filter treats them
as if they were:
+public void messageReceived(NextFilter nextFilter, IoSession session,
Object message) throws Exception {
+ // Ignore control messages e.g. from SSL filter
+ boolean compress = compressInbound (message instanceof IoBuffer);
+
+if (!compress) {
Patch file will be attached...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [AsyncWeb] Ideas for client
Sangjin Lee wrote:
What I've seen with AHC is that the configuration is often the most
challenging aspect. One metaphor I used is that HttpClient is more like a
browser. Things like keep-alive, user-agent, accept-encoding, etc. normally
belong to the browser and not at the individual request level. I'm sure
there are many delicate decisions to make that don't get solved easily by
this metaphor, but I think it's certainly useful.
This is the metaphor I would like to follow is well which is why in my
API proposal I didn't provide a mechanism for sending a raw HttpRequest
object through the HttpClient.
After reviewing all the feedback and thinking about the problem more,
I'm thinking that if the user submits a MutableHttpRequest, then the
HttpClient will modify that request as appropriate. If the HttpRequest
does not implement MutableHttpRequest, then the request will be sent
unmodified. I think this should solve the problem adequately. WDT?
I've mentioned this before, but one thing I like with AHC is handling
multiple requests with a completion queue (not unlike CompletionService).
This addresses a use case which is a variation of one of Mike's use cases.
Suppose you want to send requests to N URLs concurrently. You want to limit
the overall duration to a certain time, and you want to place a standard
error result for the URL for which the response did not get in time. This
is a pretty typical situation with a scatter-and-gather scenario (e.g.
portal with multiple server-side content aggregation, etc.).
With a completion queue, one can do things like the following:
CompletionQueue q;
client.send(request1, q);
client.send(request2, q);
...
client.send(requestN, q);
for (int i = 0; i N; i++) {
Future f = q.take();
Response r = f.get();
}
This can be done by the user in terms of a listener/callback, but it would
certainly be nice to provide support for this... My 2 cents.
I too really like the idea of using a Queue for handling futures. It
opens up a lot of interesting possibilities.
The problem I see is for each method in HttpClient, do we provide an
overloaded version that accepts a Queue? This would make the API very
cluttered IMO.
We use an HttpListener to add the completed future to the queue. See
the following example.
BlockingQueue q;
queueListener = new QueueListener(q);
client.send(request1).addListener(queueListener);
client.send(request2).addListener(queueListener);
client.send(request3).addListener(queueListener);
client.send(request4).addListener(queueListener);
for (int i = 0; i N; i++) {
Future f = q.take();
HttpResponse r = f.get();
}
The problem with this approach is that with the AsyncWeb client API, as
I've proposed it, there would be no way to know which request the future
object represents because we don't know the order in which each
HttpListener will be invoked.
I will try to refine this in the API that I'm proposing.
-Mike
On Feb 12, 2008 10:53 AM, Mike Heath [EMAIL PROTECTED] wrote:
Rick McGuire wrote:
Mike Heath wrote:
Rick McGuire wrote:
The one feature I like about the AHC client that appears to be missing
here is the higher-level abstraction of an HTTP request. The one
drawback of doing everything with URLs is the requirement that the
user
of the client needs to be responsible for encoding all of the
parameter
information in the URL. In the AHC approach, a request is configured
as
an operation to a particular address and additional specifics of the
operation are attached to the request (parameters, credentials needed
for authentication, proxy configuration etc.). The AHC client then
uses
that information to handle the URL encoding, authentication
challenges,
proxy connection, etc. There are times where a straighforward fetch
me
this URL mode is sufficient. There are other situations where that
becomes awkward to use.
Thanks for the feedback Rick. That's one of the issues I've been going
back and forth on. In the HttpConnection interface, you have no choice
but to build and send an HttpRequest manually. So you have some
flexibility there. I've been debating whether or not to put support
for
sending a raw HttpRequest in the 'simplified' HttpClient. I've been
leaning toward add that functionality to the HttpClient your reply is
making me lean even further in that direction.
-Mike
Yes, it is a bit of a balancing act. After a certain point, it becomes
difficult to continue adding all of the possibilities to the method
signatures. I think a good balance point is to support having a request
object that's got all of the bells and whistles and a few methods that
handle the most typical use scenarios (but in the end, are just creating
the same type of request object on the caller's behalf).
Rick
Yes I totally agree. A lot of the methods I put in HttpClient were
brainstorming ideas. I was trying to support the most common cases as
well as some of the more
[jira] Updated: (ASYNCWEB-4) caller supplied content is ignored, and some request headers may be added twice
[ https://issues.apache.org/jira/browse/ASYNCWEB-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated ASYNCWEB-4: --- Attachment: ASYNCWEB-4.patch Moving over a bug fix from the G sandbox. Whenever we fix any issue, we will move it over to asyncweb for consideration. This issue has to do with handling user-supplied message bodies... caller supplied content is ignored, and some request headers may be added twice --- Key: ASYNCWEB-4 URL: https://issues.apache.org/jira/browse/ASYNCWEB-4 Project: Asyncweb Issue Type: Bug Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: ASYNCWEB-4.patch, GERONIMO-3839-v2.patch, GERONIMO-3839.patch Some request headers get special treatment by HttpRequestEncoder. HttpRequestEncoder does not make any effort in checking to see if they are present in the headers already. As a result, they may be added twice if one is not careful. For example, - Content-Type Content-Length are added by HttpRequestEncoder for POST requests, and should not be added by callers. - Host User-Agent are always added by HttpRequestEncoder, and should not be added by callers as ordinary headers. Although one could argue that callers should not add these headers by hand, I think HttpRequestEncoder still should ensure that they are not added twice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (ASYNCWEB-4) caller supplied content is ignored, and some request headers may be added twice
[ https://issues.apache.org/jira/browse/ASYNCWEB-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee reopened ASYNCWEB-4: Assignee: Sangjin Lee (was: Rick McGuire) Reopening. caller supplied content is ignored, and some request headers may be added twice --- Key: ASYNCWEB-4 URL: https://issues.apache.org/jira/browse/ASYNCWEB-4 Project: Asyncweb Issue Type: Bug Reporter: Sangjin Lee Assignee: Sangjin Lee Attachments: ASYNCWEB-4.patch, GERONIMO-3839-v2.patch, GERONIMO-3839.patch Some request headers get special treatment by HttpRequestEncoder. HttpRequestEncoder does not make any effort in checking to see if they are present in the headers already. As a result, they may be added twice if one is not careful. For example, - Content-Type Content-Length are added by HttpRequestEncoder for POST requests, and should not be added by callers. - Host User-Agent are always added by HttpRequestEncoder, and should not be added by callers as ordinary headers. Although one could argue that callers should not add these headers by hand, I think HttpRequestEncoder still should ensure that they are not added twice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (ASYNCWEB-4) caller supplied content is ignored, and some request headers may be added twice
[ https://issues.apache.org/jira/browse/ASYNCWEB-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee moved GERONIMO-3839 to ASYNCWEB-4: -- Security: (was: public) Component/s: (was: AsyncHttpClient) Affects Version/s: (was: 1.x) Key: ASYNCWEB-4 (was: GERONIMO-3839) Project: Asyncweb (was: Geronimo) caller supplied content is ignored, and some request headers may be added twice --- Key: ASYNCWEB-4 URL: https://issues.apache.org/jira/browse/ASYNCWEB-4 Project: Asyncweb Issue Type: Bug Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: GERONIMO-3839-v2.patch, GERONIMO-3839.patch Some request headers get special treatment by HttpRequestEncoder. HttpRequestEncoder does not make any effort in checking to see if they are present in the headers already. As a result, they may be added twice if one is not careful. For example, - Content-Type Content-Length are added by HttpRequestEncoder for POST requests, and should not be added by callers. - Host User-Agent are always added by HttpRequestEncoder, and should not be added by callers as ordinary headers. Although one could argue that callers should not add these headers by hand, I think HttpRequestEncoder still should ensure that they are not added twice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: doubt Mina
I actually think that's exactly why the visitor pattern is nice -- the
more transports you have, the better it gets because you can elegantly
deal with the additional types rather than resorting to instansofs.
The double-dispatch method calling is also a bigger performance boost
the more types you have (as opposed to more else ifs with the
instanceof approach).
A visitor itself can also do all sorts of things other than just
identify the type.
That said, it's really a cosmetic difference either way and barely
worth the discussion -- your time is certainly better spent elsewhere!
-Adam
On Feb 13, 2008 11:58 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
I am not sure if it's a more flexible solution considering we are going
to have more transports. For example, we have serial port communication
transport, and we will have to add a visit method per each transport.
Trustin
2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
This would be a nice place for the good old visitor pattern, so
something like, in SocketSession,
SocketSession implements VisitableSession
...
public void accept(final SessionVisitor visitor)
{
visitor.visitSocketSession(this);
}
Then you have a lot of flexibility with the visitor itself to handle
types nicely. The SessionVisitor would be an interface like:
public interface SessionVisitor
{
void visitSocketSocket(final SocketSession session);
void visitDatagramSession(final DatagramSession session);
}
I'd be happy to make a patch along those lines if people were
interested. It would use generics for return types rather than the
above for slightly more flexibility.
-Adam
On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
Hello ,
i have same doubt..
- How can I tell if the connection is udp or tcp?
In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
http://www.littleshoot.org
Open Source, Open Standards, Open Data
[jira] Commented: (ASYNCWEB-4) caller supplied content is ignored, and some request headers may be added twice
[ https://issues.apache.org/jira/browse/ASYNCWEB-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568791#action_12568791 ] Mike Heath commented on ASYNCWEB-4: --- Is this still an issue in the AsyncWeb common codec? caller supplied content is ignored, and some request headers may be added twice --- Key: ASYNCWEB-4 URL: https://issues.apache.org/jira/browse/ASYNCWEB-4 Project: Asyncweb Issue Type: Bug Reporter: Sangjin Lee Assignee: Sangjin Lee Attachments: ASYNCWEB-4.patch, GERONIMO-3839-v2.patch, GERONIMO-3839.patch Some request headers get special treatment by HttpRequestEncoder. HttpRequestEncoder does not make any effort in checking to see if they are present in the headers already. As a result, they may be added twice if one is not careful. For example, - Content-Type Content-Length are added by HttpRequestEncoder for POST requests, and should not be added by callers. - Host User-Agent are always added by HttpRequestEncoder, and should not be added by callers as ordinary headers. Although one could argue that callers should not add these headers by hand, I think HttpRequestEncoder still should ensure that they are not added twice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
