Re: Cast Problem in Handler
Maarten,
then, i need to make an filter a cast of the object to bytebuffer? and
because in the example it does filter ?
thanks
On Jan 30, 2008 11:44 AM, Maarten Bosteels [EMAIL PROTECTED] wrote:
Brenno,
The Object passed in via messageReceived will always be an IoBuffer (or
ByteBuffer in mina 1.x)
when there is no ProtocolCodecFilter in your filter chain (or another
filter
that transforms IoBuffers into something else).
see also
http://mina.apache.org/tutorial-on-protocolcodecfilter.html
http://mina.apache.org/tutorial-on-protocolcodecfilter-for-mina-2x.html
Maarten
On Jan 30, 2008 4:32 PM, Brenno Hayden [EMAIL PROTECTED] wrote:
Hello,
I was studying the example of Mina, discovered that in the example
netcat, he makes a cast in hanlder
public void messageReceived(IoSession session, Object message) {
ByteBuffer buf = (ByteBuffer) message;
..
}
More without adding any filter, the more the same error occurs earlier.
Some
tips ?
Thanks
On Jan 29, 2008 1:35 PM, Brenno Hayden [EMAIL PROTECTED] wrote:
Hi Julien,
Thank you, helped a lot! The source-code is fine, now.
thanks
On Jan 29, 2008 1:20 PM, Julien Vermillard [EMAIL PROTECTED]
wrote:
Hi,
MINA provide you by default buffer of bytes and not Strings, you
shoudl take a look at this example :
http://svn.apache.org/viewvc/mina/branches/1.0/example/src/main/java/org/apache/mina/example/reverser/
And specificly to this code :
SocketAcceptorConfig cfg = new SocketAcceptorConfig();
cfg.getFilterChain().addLast(
codec,
new ProtocolCodecFilter(new
TextLineCodecFactory(Charset
.forName(UTF-8;
It's adding a codec filter for decoding raw bytes into String
HTH,
Julien
On Tue, 29 Jan 2008 13:12:02 -0400
Brenno Hayden [EMAIL PROTECTED] wrote:
Hi,
I have one problem. When I do a cast in the code below
Public class MyHanlder extends IoHandlerAdapter {
public void messageReceived(IoSession session, Object message) {
String s = (String)message;
Has the following problem
org.apache.mina.util.SessionLog warn
WARNING: [/127.0.0.1:3696] EXCEPTION, please implement
mypackage.MyHandler.exceptionCaught() for proper handling:
java.lang.ClassCastException:
org.apache.mina.common.PooledByteBufferAllocator$PooledByteBuffer
at mypackage.MyHandler.messageReceived(MyHandler.java:52)
ps: I'm using java 5 e framework 1.1.5 for java 5
Brenno Hayden F. Dantas
--
Brenno Hayden F. Dantas
--
Brenno Hayden F. Dantas
--
Brenno Hayden F. Dantas
Re: Cast Problem in Handler
Brenno,
a) no ProtocolCodecFilter in the chain
= object passed in via messageReceived is an IoBuffer
Sometimes this is fine, but most of the times, it's absolutely necessary to
have a ProtocolCodecFilter.
b) ProtocolCodecFilter(new TextLineCodecFactory(..)) in the chain
= object passed in via messageReceived is a String (one line of text)
c) ProtocolCodecFilter(new FooBarCodecFactory(..)) in the chain
= object passed in via messageReceived is a FooBar
Maarten
On Jan 31, 2008 4:39 PM, Brenno Hayden [EMAIL PROTECTED] wrote:
Maarten,
then, i need to make an filter a cast of the object to bytebuffer? and
because in the example it does filter ?
thanks
On Jan 30, 2008 11:44 AM, Maarten Bosteels [EMAIL PROTECTED]
wrote:
Brenno,
The Object passed in via messageReceived will always be an IoBuffer (or
ByteBuffer in mina 1.x)
when there is no ProtocolCodecFilter in your filter chain (or another
filter
that transforms IoBuffers into something else).
see also
http://mina.apache.org/tutorial-on-protocolcodecfilter.html
http://mina.apache.org/tutorial-on-protocolcodecfilter-for-mina-2x.html
Maarten
On Jan 30, 2008 4:32 PM, Brenno Hayden [EMAIL PROTECTED] wrote:
Hello,
I was studying the example of Mina, discovered that in the example
netcat, he makes a cast in hanlder
public void messageReceived(IoSession session, Object message) {
ByteBuffer buf = (ByteBuffer) message;
..
}
More without adding any filter, the more the same error occurs
earlier.
Some
tips ?
Thanks
On Jan 29, 2008 1:35 PM, Brenno Hayden [EMAIL PROTECTED] wrote:
Hi Julien,
Thank you, helped a lot! The source-code is fine, now.
thanks
On Jan 29, 2008 1:20 PM, Julien Vermillard [EMAIL PROTECTED]
wrote:
Hi,
MINA provide you by default buffer of bytes and not Strings, you
shoudl take a look at this example :
http://svn.apache.org/viewvc/mina/branches/1.0/example/src/main/java/org/apache/mina/example/reverser/
And specificly to this code :
SocketAcceptorConfig cfg = new SocketAcceptorConfig();
cfg.getFilterChain().addLast(
codec,
new ProtocolCodecFilter(new
TextLineCodecFactory(Charset
.forName(UTF-8;
It's adding a codec filter for decoding raw bytes into String
HTH,
Julien
On Tue, 29 Jan 2008 13:12:02 -0400
Brenno Hayden [EMAIL PROTECTED] wrote:
Hi,
I have one problem. When I do a cast in the code below
Public class MyHanlder extends IoHandlerAdapter {
public void messageReceived(IoSession session, Object message) {
String s = (String)message;
Has the following problem
org.apache.mina.util.SessionLog warn
WARNING: [/127.0.0.1:3696] EXCEPTION, please implement
mypackage.MyHandler.exceptionCaught() for proper handling:
java.lang.ClassCastException:
org.apache.mina.common.PooledByteBufferAllocator$PooledByteBuffer
at mypackage.MyHandler.messageReceived(MyHandler.java:52)
ps: I'm using java 5 e framework 1.1.5 for java 5
Brenno Hayden F. Dantas
--
Brenno Hayden F. Dantas
--
Brenno Hayden F. Dantas
--
Brenno Hayden F. Dantas
Re: How to gracefully shutdown a connection from client
Saurabh Jain wrote: Hi, I am writting a Client-Server application with mina. I am having problem in gracefully shutting down the client. the way i am trying to do is: - The client sends a logout request to the server. - The server does the clean up and closes the connection. - The client is waiting for the connection to be closed by the server. - As soon as the connection is closed the client does the cleanup and exit. The first two steps are fine. But the client is not recieving close notification, due to this the client is hanging. The code is as under: On server side when I recieve LOGOUT: session.close(); On Client Side: GenericRequest req = new GenericRequest(Constants.REQ_LOGOUT, null); WriteFuture future = session.write(req); future.awaitUninterruptibly(); conHandler.shutdown(); pinger.shutDown(); System.out.println(Waiting to close::); this.session.getCloseFuture().awaitUninterruptibly(); System.out.println(Closed ); The client is hanging on this.session.getCloseFuture().awaitUninterruptibly(); Please let me know what is the right way to gracefully shut down a client application. Thanx, Saurabh Maybe the client session's CloseFuture is only notified when you call session.close() on the client side. I'm not sure how it's supposed to be. If you use this.session.close().awaitUninterruptibly(); it might work better? -- Niklas Therning www.spamdrain.net
Re: How to gracefully shutdown a connection from client
When i try to use close at client side then i get a java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThread) due to the Security manager implementation of my application. Does close operation require any specific permissions? Also I have gone through the examples and i think this is the same mechanism used in the examples. (May be I have missed something [:(] ) I followed the chat example. Saurabh. Niklas Therning wrote: Saurabh Jain wrote: Hi, I am writting a Client-Server application with mina. I am having problem in gracefully shutting down the client. the way i am trying to do is: - The client sends a logout request to the server. - The server does the clean up and closes the connection. - The client is waiting for the connection to be closed by the server. - As soon as the connection is closed the client does the cleanup and exit. The first two steps are fine. But the client is not recieving close notification, due to this the client is hanging. The code is as under: On server side when I recieve LOGOUT: session.close(); On Client Side: GenericRequest req = new GenericRequest(Constants.REQ_LOGOUT, null); WriteFuture future = session.write(req); future.awaitUninterruptibly(); conHandler.shutdown(); pinger.shutDown(); System.out.println(Waiting to close::); this.session.getCloseFuture().awaitUninterruptibly(); System.out.println(Closed ); The client is hanging on this.session.getCloseFuture().awaitUninterruptibly(); Please let me know what is the right way to gracefully shut down a client application. Thanx, Saurabh Maybe the client session's CloseFuture is only notified when you call session.close() on the client side. I'm not sure how it's supposed to be. If you use this.session.close().awaitUninterruptibly(); it might work better? -- Niklas Therning www.spamdrain.net - Niklas Therning www.spamdrain.net -- View this message in context: http://www.nabble.com/How-to-gracefully-shutdown-a-connection-from-client-tp15189221s16868p15211665.html Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: [AsyncHttpClient] On bringing the code bases and communities together
Just so I understand... What is the direction we're taking? Just for the terminology sake, I'll call these versions - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were working on) - g-ahc-v2: Geronimo AHC based on Mina trunk - mina-ahc: Mina AHC that was refactored into asyncweb Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to migrate them again from g-ahc-v2 to mina-ahc? Thanks, Sangjin On Jan 30, 2008 6:36 PM, Alex Karasulu [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] wrote: Being that its in the sandbox...anything goes. ;-) However...with that said...lets see what pans out here at Mina. I would certainly consider the delta now before we get 3 diverse versions ;-) Yes the preferred version is Mina 2.x. Indeed! We might want to first make sure the two Geronimo forks are merged and using MINA 2.0. Meaning all the features and fixes in the one based on MINA 1.1.x are put into the one based on MINA 2.0-M1. That might bring the consolidated Geronimo fork closer to the MINA version in Asyncweb trunk. Then we can focus on how to merge these two together? Alex
Re: [AsyncHttpClient] On bringing the code bases and communities together
Hi, Just so I understand... What is the direction we're taking? Just for the terminology sake, I'll call these versions - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were working on) - g-ahc-v2: Geronimo AHC based on Mina trunk - mina-ahc: Mina AHC that was refactored into asyncweb Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to migrate them again from g-ahc-v2 to mina-ahc? I think it's a good idea. The first thing to do is to freeze the g-ahc-v1 to avoid endless porting between the two branches. The main problem for the migration back to Asyncweb is the codec, it was modified a lot ? Julien Thanks, Sangjin On Jan 30, 2008 6:36 PM, Alex Karasulu [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] wrote: Being that its in the sandbox...anything goes. ;-) However...with that said...lets see what pans out here at Mina. I would certainly consider the delta now before we get 3 diverse versions ;-) Yes the preferred version is Mina 2.x. Indeed! We might want to first make sure the two Geronimo forks are merged and using MINA 2.0. Meaning all the features and fixes in the one based on MINA 1.1.x are put into the one based on MINA 2.0-M1. That might bring the consolidated Geronimo fork closer to the MINA version in Asyncweb trunk. Then we can focus on how to merge these two together? Alex
Re: [AsyncHttpClient] On bringing the code bases and communities together
Yes.. I think that is the best course of action. I think they are pretty similar since I created the mina 2 version in late December. I think the delta is rather small. Jeff On Jan 31, 2008, at 1:34 PM, Sangjin Lee [EMAIL PROTECTED] wrote: Just so I understand... What is the direction we're taking? Just for the terminology sake, I'll call these versions - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were working on) - g-ahc-v2: Geronimo AHC based on Mina trunk - mina-ahc: Mina AHC that was refactored into asyncweb Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to migrate them again from g-ahc-v2 to mina-ahc? Thanks, Sangjin On Jan 30, 2008 6:36 PM, Alex Karasulu [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] wrote: Being that its in the sandbox...anything goes. ;-) However...with that said...lets see what pans out here at Mina. I would certainly consider the delta now before we get 3 diverse versions ;-) Yes the preferred version is Mina 2.x. Indeed! We might want to first make sure the two Geronimo forks are merged and using MINA 2.0. Meaning all the features and fixes in the one based on MINA 1.1.x are put into the one based on MINA 2.0-M1. That might bring the consolidated Geronimo fork closer to the MINA version in Asyncweb trunk. Then we can focus on how to merge these two together? Alex
Re: [AsyncHttpClient] On bringing the code bases and communities together
sorry for double post,I'm out of my office and using webmail which is really bugged :( Sorry for the inconvenience, Julien
Re: [AsyncHttpClient] On bringing the code bases and communities together
Hi Just so I understand... What is the direction we're taking? Just for the terminology sake, I'll call these versions - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were working on). - g-ahc-v2: Geronimo AHC based on Mina trunk - mina-ahc: Mina AHC that was refactored into asyncweb Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to migrate them again from g-ahc-v2 to mina-ahc? I think it's a good way, the first thing is probably to freeze the g-ahc-v1 for avoid more porting. The main problem for migrate to mina-ahc is the new Asynweb state based codec. You think a lot of feature are missing from mina http codec from the g-ahc one ? Julien (not sure to be clear) Thanks, Sangjin On Jan 30, 2008 6:36 PM, Alex Karasulu [EMAIL PROTECTED] wrote: On Jan 30, 2008 1:49 PM, Jeff Genender [EMAIL PROTECTED] wrote: Being that its in the sandbox...anything goes. ;-) However...with that said...lets see what pans out here at Mina. I would certainly consider the delta now before we get 3 diverse versions ;-) Yes the preferred version is Mina 2.x. Indeed! We might want to first make sure the two Geronimo forks are merged and using MINA 2.0. Meaning all the features and fixes in the one based on MINA 1.1.x are put into the one based on MINA 2.0-M1. That might bring the consolidated Geronimo fork closer to the MINA version in Asyncweb trunk. Then we can focus on how to merge these two together? Alex
Strange loop back connections using a massive number of handles.
All,
We moved to MINA 2.0 a while ago and starting having problems where
after running for a while we get this exception:
java.io.IOException: An existing connection was forcibly closed
by the remote host
Upon further analysis we are seeing that the process has over 100,000
handles that are attributed to loop back connections that are being
created down in the MINA layer.
Test specifications:
Java 1.6.0 u3 64bit Windows 2003 Server R2 and on 32bit Windows XP SP2
MINA 2.0 w/ latest tip from today Jan 31, 2008
slf4j-api-1.3.0
slf4j-simple-1.3.0
main.java
import org.apache.mina.transport.socket.nio.NioSocketAcceptor;
public class main
{
public static void main( String[] args )
{
System.out.println(Before no loopback connections);
NioSocketAcceptor acceptor = new NioSocketAcceptor();
System.out.println(After now there are );
}
}
/main.java
Test Steps
1. Add breakpoints at the two println statements.
2. Run tcp view --
http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx
3. Startup the test application find your java process in tcp view.
Note number of loop back socket connections
4. Proceed to second breakpoint at second println.
5. Note you will have 5 loop back connections associated with the java
jvm process
Why are there loop back socket connections being created since nothing
has been done at this point to bind to a port? Though I don't have any
test application this also is occurring for client connections. Over
time it seems more and more of these loopback connections are created
thus running the process out of handles or the machine out of loopback
socket ports.
Sadly starting tomorrow I will be porting our code back to 1.1.5 since
we are getting way too close to a deadline.
If others are seeing this I'd be happy to enter in a bug tomorrow but
thought I might see if this was seen by anyone else first.
Thank you,
Scott Peters
