Re: doubt Mina
My point :) is that introducing a visitor interface that depends on all
transport modules doesn't sound good to me. If we are going to do that,
the visitor interface will have to be provided as a separate module that
depends on all other transport modules to avoid a cyclic dependency. We
had a similar problem in TransportType in MINA 1.x related with cyclic
dependency.
2008-02-16 (토), 00:21 -0500, Adam Fisk 쓰시길:
> Hmmnn...I don't think so. As far as I can tell, he's talking about
> adding more types to a future MINA release. That would mean adding a
> method to each new type -- hardly a high cost given the return. If
> you want to make it possible for users to add types, you could simply
> have an "visitGenericType" method that would be no worse than the
> current situation, but it doesn't seem like users adding their own
> types would ever be a common use case.
>
> -Adam
>
>
> On Feb 14, 2008 8:53 AM, David M. Lloyd <[EMAIL PROTECTED]> wrote:
> > I believe that Trustin's point is that the visitor pattern is only
> > effective if you know all the visitable types ahead of time. It's quite
> > difficult for a user to wedge in their own type after the fact - they
> > would have to modify the visitor interface for each new transport type
> > they add.
> >
> > - DML
> >
> >
> > Adam Fisk wrote:
> > > 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 if"s 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/
> > >>
> > >
> > >
> > >
> >
> >
>
>
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
Re: State machine documentation question
I'll take your word for it. I have not used a tape deck in some time. I will take a look at the code see what I think the appropriate change is. As for Rodrigo's comments, I completely agree with what you say. I think that if you have a problem with something you should be able to suggest a solution On Feb 16, 2008 8:59 AM, Niklas Therning <[EMAIL PROTECTED]> wrote: > Mark Webb wrote: > > I have been trying to write a MINA system using the state machine > > library. As I go through the documentation I think I found an error > > that is confusing me. So either I am just simply confused or there is > > an error :) > > > > Looking at the diagram, I think the transition from "Paused" to > > "Playing" should be "play". This would allow the @Transitions > > annotation in TapeDeckHandler to make more sense, since this > > annotation appears to support multiple @Transition annotations for one > > state. > Your correct, there is an error there. IIRC, on those old tape decks, > you usually pressed Play once and then used the Pause button to > pause/unpause. In that case the diagram is correct and the code should > be changed. What do you think? > > -- > Niklas Therning > www.spamdrain.net > -- Talent hits a target no one else can hit; Genius hits a target no one else can see.
Re: [Asyncweb] server API for commiting HTTPReponse in chunk
Adding commit(Partial)?Response method causes HttpResponse to keep a
response to IoSession, which doesn't sound good to me. What do you
think about providing another setContent method with Queue?
We could provide a special implementation of Queue that allows a user to
stream a list of IoBuffers on demand. The encoder will try to access
the queue by calling poll() to get the newest chunk.
Actually this proposal causes some changes in ProtocolCodecDecoder and
MINA itself so it can understand Queue. However, the encoder
won't need to be changed at all.
Another trickier part is decoding. I prefer to have HttpRequest (or
HttpResponse) to have a Queue as a content so the decoder can
offer the newly received chunk there.
On the other hand, Use of the Queue interface might be inadequate and we
might need to introduce more specialized interface like the following:
public interface IoBufferStream {
void offer(IoBuffer buf);
// Returns null on the end of the content.
// Returns an empty buffer if no chunk is ready yet.
IoBuffer poll();
// and some listener registration...
IoBufferStream addListener(IoBufferStreamListener listener);
IoBufferStream removeListener(IoBufferStreamListener listener);
}
By having MINA core providing a standardized interface for streaming a
large list of buffer chunks will make more broad range of users happier
rather than implementing such a feature in a certain protocol provider.
WDYT?
2008-02-14 (목), 12:20 +0100, Julien Vermillard 쓰시길:
> Hi,
>
> I would like to have your comments about the Asyncweb server API
>
> Actually you create your HttpResponse like that :
>
> MutableHttpResponse response = new DefaultHttpResponse();
> response.setContent(myIoBuffer);
> response.setHeader("Content-Type", "text/html");
> response.setStatus(HttpResponseStatus.OK);
>
> context.commitResponse(response);
>
> I like this API, it's very simple to use. I would like to keep it
> because it's *very* easy for anybody to make a simple HttpService for
> serving few data, like RPC call or anything you want.
>
> As Dave commented here http://jira.safehaus.org/browse/ASYNCWEB-21 it's
> totally inefficient for serving large data and streaming is impossible.
>
> I would like to propose a variation of Dave API idea :
>
> We keep "response.setContent(myIoBuffer);" because it will fit 70% of
> the use cases :)
>
> We add to MutableHttpResponse a Queue of IoBuffer you can fill like you
> want for example :
>
> MutableHttpResponse response = new DefaultHttpResponse();
> response.setStatus(HttpResponseStatus.OK);
> response.addContent(buffer1);
> response.addContent(buffer2);
> response.addContent(buffer3);
> response.commitResponse(response);
>
> So you can add content in chunks in place of 1 big buffer, that won't
> resolve the streaming problem, but it's convenient.
>
> Now streaming :
>
> MutableHttpResponse response = new DefaultHttpResponse();
>
> response.setStatus(HttpResponseStatus.OK);
>
> // add a first chunk (optional)
> response.addContent(buffer1);
>
> PartialResponseListener listener = new PartialResponseListener() {
> public void queueEmpty(HTTPResponse response) {
> if(moreDataToSend) {
> ...
> // add more data
> response.addContent(buffer);
> } else {
> // streaming is done finish the response
> response.done();
> }
> }
> };
> response.commitPartialResponse(response, listener);
>
> What I would like to discuss here is to find a good looking API doing
> everything you can imagine about streaming (audio,commet,big
> files,etc..) before looking at impementation
>
> and of course with good names fitting picky Koreans :)
>
> Julien
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
Asynchronous DNS query as a separate submodule
Hi,
I thought about incorporating asynchronous DNS query feature into MINA
core, and reached to the temporary conclusion that it might be a better
idea to keep it as a separate submodule.
The reasoning behind this idea is that InetSocketAddress() doesn't query
DNS server at all if an IP address is specified. For example, new
InetSocketAddress("gleamynode.net", 8080) causes a DNS lookup, but new
InetSocketAddress("123.123.123.123", 8080) doesn't, which means that we
can still keep SocketAddress as a standard interface to represent an
endpoint.
In the separate module, user could request asynchronous DNS query like
the following:
DnsResolver resolver = ...;
Future f = resolver.query("gleamynode.net");
// returns an InetAddress with an IP address rather than with host name.
InetAddress address = f.get();
By providing this submodule rather than changing the core:
1) Most users are happy that they don't need to change anything.
2) Some users who needs asynchronous domain name resolution can use the
submodule for better simultaneous, asynchronous, complicated domain
resolution.
We could provide it as a subproject, but in this case, providing it as a
submodule will make MINA more complete network application framework.
On the other point, it's also the implementation of DNS protocol, so it
might be a better idea to provide it as a subproject.
WDYT?
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
Re: [mina] Sending datagrams without connection
2008-02-09 (토), 13:06 -0600, David M. Lloyd 쓰시길: > David M. Lloyd wrote: > > Wilson Yeung wrote: > >> It would be quite nice to be able to do something equivalent to > >> sendto() with > >> a DatagramAcceptor or a DatagramConnector. > >> > >> I've written a UDP application based on Mina that sends precisely 1 > >> packet > >> to 1 million end points, and waits for 1 packet from 1 million end > >> points. Each 2 packet exchange is 1 Mina IoSession, and I continuously > >> reuse the > >> same 1000 - 5000 prebound IoSession objects, that is, I keep 1000 - > >> 5000 of > >> these exchanges in flight at a time. > > > > My opinion is that there should simply be one IoSession for all datagram > > sockets. > > Let me clarify - I mean one IoSession for *each* datagram socket. David and I met in the JBossWorld 2008 and had some time to discuss about this issue, and the following is my idea after the discussion with him. If we map one IoSession to one DatagramChannel, it means we need to provide additional information (i.e. remoteAddress of the received message) when messageReceived event is fired. There are a few solutions to this issue: 1) Add SocketAddress parameter to messageReceived - it's not so good because TCP/IP transports will never use it. 2) Change the datagram transport to use other type than IoBuffer. For example, provide a class that contains an IoBuffer and SocketAddress - it's also not so good because it breaks backward compatibility and prevents a user from migrating from TCP to UDP and vice versa. Their IoHandler implementation will not be reusable. Another problem is that we already have IoSession.getRemoteAddress(). If we map one session to one datagram channel, DatagramSession.getRemoteAddress() should return something ambiguous such as null, which causes backward compatibility issues. Actually, having more than one sessions per datagram channel is similar to the solution #2 above in that IoSession behaves a kind of wrapper of an extra information. The problem here is the creation and destruction overhead of DatagramSessions. So... I'd like to suggest to keep the current API while minimizing creation overhead. We definitely need to improve performance for datagram transport and see if how it compares to the plain NIO implementation. If the performance tuning attempt fails, we could think about revamping the overall API which might be pain to users. -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
