Lorenz Breu wrote:
I think I found the problem. The Socket class in tomcat.jni specifies
recvFrom() whereas the native network.c implements recvfrom() (all
lowercase). Changing the java method name and rebuilding tomcat removed
the UnsatisfiedLink error (I mentioned this on the tomcat dev
Trustin Lee wrote:
First thing I would add would be the unlock for Socket.accept
(something each Acceptor, not only APR should have)
and make sure that Socket.close for the acceptor socket is called even
on the CTRL+C. After all native calls are exited, then you can safely
call the
Trustin Lee wrote:
SocketAcceptor a = new NioSocketAcceptor();
after:
SocketAcceptor a = new AprSocketAcceptor();
Wow, that's cool!
You might encounter segfault due to a bug of the current
implementation because we are using tomcat-native bridge for APR 1.2.
Any feed back is welcome!
Trustin Lee wrote:
You might encounter segfault due to a bug of the current
implementation because we are using tomcat-native bridge for APR 1.2.
Any feed back is welcome!
The problem is probably with shutting down the APR library.
Tomcat-native is very thin JNI layer for APR, so some
Deepak J wrote:
Perhaps not the right forum to post these results. But just wanted your
opinion on the tests.
You should fix up your email client to not wrap lines or attach
the results as simple .txt
It's simply unreadable.
Regards,
Mladen
Vinod Panicker wrote:
Seconded. If I've learned one thing from server development, it is
that each component should be tested thoroughly before it is used as a
dependency. Hibernate may be a boon for certain people, but it really
doesn't cut it when performance is a concern - at least that's
Niklas Therning wrote:
It would be great if there is some .indent file because
I already noticed that there are some files that are
starting to break those rules.
Please have a look here:
http://mina.apache.org/developer-guide.html#DeveloperGuide-CodingConvention
Back when MINA was a
Niklas Therning wrote:
That's one of the reasons why we made this decision IIRC. But maybe it's
time to reconsider? It sure would be nice to have all source code fixed
before we release 2.0.
If the decision was made to change the coding style, then IMHO
it's better to do that sooner then
Hi,
Looking at MINA sources I found out that the coding style is
different from what I'm used to. Well, it's personal anyhow, but
it should be important.
Are there any rules for that?
I have noticed few:
1. After each '(' there must be a space.
Exception is if next char is ')'
2. There must
