Re: [VOTE] Release Apache MINA 2.0-M1
+1 Release MINA 2.0-M1 Maarten On Feb 12, 2008 8:38 AM, Cameron Taggart <[EMAIL PROTECTED]> wrote: > +1 > > > [ ]: +1, Release MINA 2.0-M1 > > [ ]: 0, Abstain > > [ ]: -1, Don't release MINA 2.0-M1 >
Re: MINA at JavaOne 2008 - idea wanted
On Tue, 12 Feb 2008 01:18:52 -0500 이희승 "(Trustin Lee)" <[EMAIL PROTECTED]> wrote: > Hi, > > I was invited as a speaker of JavaOne 2008 and will speak about Apache > MINA there. Please feel free to contact me to give me some idea about > what you want to hear about MINA if you have any plan to attend this > year's JavaOne. > > Cheers, > Trustin I have no plan to attend to JavaOne :) but here want I would like to hear : # 2.0 new features and API # presentation of new Apache apps using MINA : - FTPServer - AHC - Aweb - ...
Re: [VOTE] Release Apache MINA 2.0-M1
On Tue, 12 Feb 2008 01:11:47 -0500 이희승 "(Trustin Lee)" <[EMAIL PROTECTED]> wrote: > 2008-02-11 (월), 20:35 -0700, Mike Heath 쓰시길: > > [X]: +1, Release MINA 2.0-M1 > > Nice to see you fire the vote, which means another person will get to > know how to deal with the whole release procedure, as described in our > developer's guide. You could ask me or Julien if you have any > questions. > > Cheers, > Trustin +1, I can help for the release, I need to update the guide a little for add some configuration details. Julien
Re: [VOTE] Release Apache MINA 2.0-M1
[X]: +1, Release MINA 2.0-M1 이희승 (Trustin Lee) wrote: 2008-02-11 (월), 20:35 -0700, Mike Heath 쓰시길: [X]: +1, Release MINA 2.0-M1 Nice to see you fire the vote, which means another person will get to know how to deal with the whole release procedure, as described in our developer's guide. Thanks to your great doco, it seems that almost anyone can now release MINA ! Julien successfully did it last week :) Btw, Alex told me that you are now a father ! That is just a great news, and I'm very pleased to hear about it ! Congrats ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [AsyncWeb] Ideas for client
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. -Mike > > -Eero > > 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. >> >> Rick >> >> Mike Heath wrote: >>> I posted some use cases here: >>> http://cwiki.apache.org/confluence/display/AWEB/ClientUseCases They >>> still need some refinement to properly convey what I want but they're a >>> decent start. >>> >>> I've also posted a hypothetical AsyncWeb Client API at >>> http://swamp.homelinux.net/mina/asyncweb/client/api/ with the intent to >>> further promote discussion and foster more innovative ideas. I would >>> love to here some feedback on this API. What do you like, dislike, not >>> understand? Where do you see room for improvement? The API is really >>> rough in places but for the most part it conveys the ideas I've had over >>> the past week or so. Any suggestions for name changes to classes and/or >>> methods are welcome. >>> >>> -Mike >>> >>> >> > >
Re: [VOTE] Release Apache MINA 2.0-M1
+1 I was waiting on official 2.0-M1 to get a version 1.0-M1 of my project... Glad to see it's coming ! Also, just to point it, HTTP client (simplest one for my need) would be welcomed since I improve my project with a small http interface using old http-client support in Mina. So I will need to stay tuned with the first (beta?) release of the AsyncWeb client to get the full v1.0 out... Thank again to all the Mina's community and other projects !!! Frederic - Original Message - [ ]: +1, Release MINA 2.0-M1 [ ]: 0, Abstain [ ]: -1, Don't release MINA 2.0-M1
Re: [AsyncWeb] Ideas for client
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 Rick Mike Heath wrote: I posted some use cases here: http://cwiki.apache.org/confluence/display/AWEB/ClientUseCases They still need some refinement to properly convey what I want but they're a decent start. I've also posted a hypothetical AsyncWeb Client API at http://swamp.homelinux.net/mina/asyncweb/client/api/ with the intent to further promote discussion and foster more innovative ideas. I would love to here some feedback on this API. What do you like, dislike, not understand? Where do you see room for improvement? The API is really rough in places but for the most part it conveys the ideas I've had over the past week or so. Any suggestions for name changes to classes and/or methods are welcome. -Mike
Re: [AsyncWeb] Ideas for client
This is very cool to hear Matteo! I will definitely have to take a look at your code. It would be nice to integrate some of this into MINA. -Mike Matteo Merli wrote: > Hi, > > I've started an asyncronous DNS client based on MINA for my HTTP > caching proxy (also based on MINA: > http://alijo.googlecode.com ) > > The client is based on the code from the DNS server in Apache Directory. > > The implementations is not complete yes as : > > * Only returns first IP address in the DNS reply > * Only uses first DNS server (primary), as read from /etc/resolv.conf > * Can cache DNS addresses, but.. caches forever as no expiration is applied > * Does not use aliases > > I plan to work more on the DNS client. If anyone is interested, the > sources can be found here: > > DNS Codec: > http://alijo.googlecode.com/svn/trunk/protocol-dns/ > > DNS Client: > http://alijo.googlecode.com/svn/trunk/alijo/src/main/java/org/mm/proxycache/dns/ > > Again, the code is not polished , but if there is interest I can work > onrefining it and extracting it in a decent form. > > Regards, > Matteo > <[EMAIL PROTECTED]> > > On Feb 12, 2008 3:59 PM, Eero Nevalainen <[EMAIL PROTECTED]> 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? >> >> -Eero >> >> >> 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. >>> >>> Rick >>> >>> Mike Heath wrote: I posted some use cases here: http://cwiki.apache.org/confluence/display/AWEB/ClientUseCases They still need some refinement to properly convey what I want but they're a decent start. I've also posted a hypothetical AsyncWeb Client API at http://swamp.homelinux.net/mina/asyncweb/client/api/ with the intent to further promote discussion and foster more innovative ideas. I would love to here some feedback on this API. What do you like, dislike, not understand? Where do you see room for improvement? The API is really rough in places but for the most part it conveys the ideas I've had over the past week or so. Any suggestions for name changes to classes and/or methods are welcome. -Mike >> > > >
Re: MINA at JavaOne 2008 - idea wanted
Yeah I am in agreement with Mike. An architectural overview...and an example (heck use AHC vs HttpClient) and show how it scales. That will get ooohs and ahhhs. Jeff Mike Heath wrote: One of the problems I've had when promoting MINA is that most Java developers don't understand the scalability implications of the thread-per-connection architecture. If I jump right in with how cool MINA is with its separation of concerns, futures, filters, event mechanism, simplifies packet fragmentation problems, etc., the audience either gets lost or replies with something like, "Using InputStreamsis just as flexible as filters but doesn't come with all the difficulties of having to build a state machine. MINA just makes things complicated!" However, if I start out showing how quickly I get an OOM exception when using a thread-per-connection architecture and then show how I can handle thousands of connections in MINA without consuming loads of memory, the audience is able to better understand the main problem that MINA solves. Showing how painful it is to use NIO directly is fairly simple at this point. The important part is making sure the audience understands the need for the functionality that NIO has to offer. Once the audience understands the problems MINA solves, I've found they're usually much more receptive to the coolness that MINA has to offer. Just my $0.02. -Mike 이희승 (Trustin Lee) wrote: Hi, I was invited as a speaker of JavaOne 2008 and will speak about Apache MINA there. Please feel free to contact me to give me some idea about what you want to hear about MINA if you have any plan to attend this year's JavaOne. Cheers, Trustin
Re: MINA at JavaOne 2008 - idea wanted
One of the problems I've had when promoting MINA is that most Java developers don't understand the scalability implications of the thread-per-connection architecture. If I jump right in with how cool MINA is with its separation of concerns, futures, filters, event mechanism, simplifies packet fragmentation problems, etc., the audience either gets lost or replies with something like, "Using InputStreamsis just as flexible as filters but doesn't come with all the difficulties of having to build a state machine. MINA just makes things complicated!" However, if I start out showing how quickly I get an OOM exception when using a thread-per-connection architecture and then show how I can handle thousands of connections in MINA without consuming loads of memory, the audience is able to better understand the main problem that MINA solves. Showing how painful it is to use NIO directly is fairly simple at this point. The important part is making sure the audience understands the need for the functionality that NIO has to offer. Once the audience understands the problems MINA solves, I've found they're usually much more receptive to the coolness that MINA has to offer. Just my $0.02. -Mike 이희승 (Trustin Lee) wrote: > Hi, > > I was invited as a speaker of JavaOne 2008 and will speak about Apache > MINA there. Please feel free to contact me to give me some idea about > what you want to hear about MINA if you have any plan to attend this > year's JavaOne. > > Cheers, > Trustin
Nabble mails disabled ...
Hi guys, we have asked to block any mail received through Nabble, as some spammer are using it to directly send some offensive mails to the list. Sadly, those spams don't get moderated, so this was the only solution we had. If you are using a nabble address, please consider using an alternative mail to post to the mailing list. I'm trully sorry for this inconvenience, but I'm pretty sure you understand that this is the price to pay to avoid being flooded with spams on the MINA mailing list (remember that hundreds of people have subscribed to this list, and will receive those spams...) Thanks ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [AsyncWeb] Ideas for client
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.
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.
Thanks,
Sangjin
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 complex cases (like doing a PUT with a file,
> for example.)
>
> We need to find a balance of simplicity and function and I'm not sure
> where that point is at. Some of the issues that need to be addressed
> with supporting sending raw HttpRequest objects using the HttpClient
> (the way I've modeled it, that is) are:
> - If the HttpClient has connection pooling enabled but a request is
> sent without KeepAlive and Connection headers, do we automatically
> change the request to turn keepAlive on and use connection pooling or do
> we create a new connection?
> - If the HttpClient has a cookie manager, do we automatically add
> cookies to a manually created HttpRequest?
> - Are there other headers that we would want to automatically populate
> if their absent (User-Agent, Accept*, etc.) ?
> - Do we even want to modify a manually created HttpRequest? Should
> this be configurable? If so how?
>
> I don't have answers to these questions which is why I decided to just
> put support for sending raw HttpRequest messages in the HttpConnection
> interface because that's the interface I intended to make available for
> complex use cases (COMET, dealing with large data streams, etc.)
> However, I think we need to find some middle ground. I'm just not sure
> where that middle ground is.
>
> Thanks again for your feedback, Rick.
>
> -Mike
>
> >
> >
> >>
> >>
> >>
> >>> Rick
> >>>
> >>> Mike Heath
Re: Nabble mails disabled ...
Oh I see. We could probably switch to GMANE. Would it make sense? 2008-02-12 (화), 23:50 +0100, Emmanuel Lecharny 쓰시길: > Hi guys, > > we have asked to block any mail received through Nabble, as some spammer > are using it to directly send some offensive mails to the list. Sadly, > those spams don't get moderated, so this was the only solution we had. > > If you are using a nabble address, please consider using an alternative > mail to post to the mailing list. > > I'm trully sorry for this inconvenience, but I'm pretty sure you > understand that this is the price to pay to avoid being flooded with > spams on the MINA mailing list (remember that hundreds of people have > subscribed to this list, and will receive those spams...) > > Thanks ! > -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
Re: NioProcessor select(..) question
The 1 second here is to detect idle sessions, because the granularity of
idle time is 1 second for now. We could change that though.
2008-02-05 (화), 09:25 +0100, Julien Vermillard 쓰시길:
> In NioProcessor .java you got the following select implementation :
>
> @Override
> protected boolean select(int timeout) throws Exception {
>return selector.select(1000) > 0;
> }
>
> The hard-coded 1 sec value smell fishy, it's normal ? if so I think
> I'll place a comment for indicate it's not a mistake.
>
> Julien
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
Re: sessionClosed is not called sometimes in heavy stress test contions.
JH,
Thank you so much for the detailed analysis. Let me take a look into
this issue when I get back home.
2008-02-07 (목), 23:59 -0800, jhcha 쓰시길:
> Thank Mike for replying my question.
>
> I read your answers but...
>
> I think MINA already knew the session was being closed in my questioned
> situation.
> because my server session always close after sending the echo data and
> I debugged MINA source
> org.apache.mina.transport.socket.nio.SocketIoProcessor.Worker.run method
> always call doRemove() at (SocketIoProcessor.java:489 line).
> then doRemove method always call
> session.getServiceListeners().fireSessionDestroyed(session);
> at (SocketIoProcessor.java:188 line).
>
>try {
> key.cancel();
> ch.close();
> } catch (IOException e) {
> session.getFilterChain().fireExceptionCaught(session, e);
> } finally {
> releaseWriteBuffers(session);
> session.getServiceListeners().fireSessionDestroyed(session); <---
> SocketIoProcessor.java:188 line
> }
>
>
> and the above session parameter of the fireSessionDestroyed method was
> always not null.
>
> the orgin of the problem is the sessions having serviceAddress is not in
> managedSessions hashmap
> in fireSessionDestroyed method at (IoServiceListenerSupport.java:192 line)
>
> // Get the session set.
> Set sessions = managedSessions.get(serviceAddress); <---
> IoServiceListenerSupport.java:192 line
> // Ignore if unknown.
> if (sessions == null) {
> return;
> }
>
> The fireSessionDestroyed method call propagation stopped only sometimes
> Because sessions is not gotten from managedSessions at
> (IoServiceListenerSupport.java:192 line).
>
> I used setIdleTimeout with read mode, but
> if sessionClosed method is not called, sessionIdle or sessionClosed method
> will never be called after that.
>
> My question is that the filter chain fireSessionClosed method and listener'
> sessionDestroyed method
> Should not know if the destroying session be not in the managedSessions
> hashmap ?
>
> // Fire session events.
> session.getFilterChain().fireSessionClosed(session); <---
> IoServiceListenerSupport.java:208 line
>
> // Fire listener events.
> try {
> for (IoServiceListener listener : listeners) {
> listener.sessionDestroyed(session); <---
> }
> }
>
>
> If fireSessionDestroyed method were called with the parameter the closing
> session
> but not in managedSessions hashmap, Should filter chain fireSessionClosed
> method and
> listener' sessionDestroyed method not called ?
>
>
> in the following MINA source below the IoServiceListenerSupport.java:147
> line.
>
>
> public void fireSessionCreated(IoSession session) {
> SocketAddress serviceAddress = session.getServiceAddress();
>
> // Get the session set.
> Set s = new IdentityHashSet();
> Set sessions =
> managedSessions.putIfAbsent(serviceAddress,
> Collections.synchronizedSet(s));
> boolean firstSession;
>
> if (null == sessions) {
> sessions = s;
> firstSession = true;
> } else {
> firstSession = false;
> }
>
> // If already registered, ignore.
> if (!sessions.add(session)) { <---
> return;
> }
>
> // If the first connector session, fire a virtual service activation
> event.
> if (session.getService() instanceof IoConnector && firstSession) {
> fireServiceActivated(session.getService(), session
> .getServiceAddress(), session.getHandler(), session
> .getServiceConfig());
> }
>
> // Fire session events.
> session.getFilterChain().fireSessionCreated(session);
> session.getFilterChain().fireSessionOpened(session);
>
> // Fire listener events.
> for (IoServiceListener listener : listeners) {
> listener.sessionCreated(session);
> }
> }
>
>
> I think the code "if (!sessions.add(session))" is always true,
> So filter chain fireSessionCreated method and listener' sessionCreated
> method is
> always called in spite of the heavy unstable tcp stress condition.
>
> I think
> Creaing callback method and destroying callback method should have the same
> calling count.
>
> But creating callback logic and managedSessions hashmap are not related
> directly
> in the above fireSessionCreated method.
>
> "not related directly" means that
> whether sessions put managedSessions hashmap or not, fireSessionCreated and
> sessionCreated are called.
>
> Then destroying callback logic and managedSessions hashmap should be also
> not related directly.
> but MINA has the direct relation with managedSessions hashmap
>
> "direct relation" means that
> as the below code shows, if sessions is not found in managedSessions hashm
[jira] Commented: (DIRMINA-489) Composite IoBuffer
[ https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568424#action_12568424 ] Trustin Lee commented on DIRMINA-489: - Thanks Johannes for the comment. It is very helpful. Please keep posting any new ideas so we can roll out something cool. :) > Composite IoBuffer > -- > > Key: DIRMINA-489 > URL: https://issues.apache.org/jira/browse/DIRMINA-489 > Project: MINA > Issue Type: New Feature > Components: Core >Reporter: David M. Lloyd > Fix For: 2.0.0-M2 > > > Provide a way to create a large IoBuffer from several smaller IoBuffers, > without copying the underlying data. > It would probably be acceptable to constrain the composite buffer in various > ways, for example by disallowing autoexpanding or otherwise changing the > capacity, the implementation could be greatly simplified. > The goal is to be able to process large messages with a minimum of copying. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: connect timeout
Yes, it would be great if users can configure the select timeout.
One small issue that I have, however, is if the select timeout is longer
than the connect timeout. Then it is possible that the connect timeout will
not always be honored because select will not wake up until select timeout
pops.
It is understood that it would happen only if there are no other connect
events happening, but a select timeout that is longer than the connect
timeout will effectively interfere with the proper connect timeout. How
shall we address that situation?
Thanks,
Sangjin
On Feb 12, 2008 8:43 PM, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote:
> Thanks Sanjin for the patch. It looks pretty good. One tiny thing I'd
> like to point out is that it would be much nicer if a user can configure
> the selector timeout parameter. For example, we could leave the default
> '1000', and let people reconfigure that by calling the following
> statement:
>
> connector.setMaxConnectTimeoutCheckInterval(50); // ms
>
> I'm not sure if this property name is good, but it's my idea that we
> need to make it configurable rather than hard-coding it.
>
> In the same context, we could make the idle time check interval also
> configurable. WDYT?
>
> 2008-02-06 (수), 10:09 -0800, Sangjin Lee 쓰시길:
> > I have filed a JIRA issue (
> https://issues.apache.org/jira/browse/DIRMINA-527),
> > and submitted a patch for this.
> >
> > In the patch I added IoConnector.setConnectTimeoutMillis(), and
> deprecated
> > getConnectTimeout()/setConnectTimeout() in favor of the new ones.
> Perhaps
> > one could go as far as removing them? I wasn't sure...
> >
> > Also, the select timeout is now tied to the connect timeout, but still
> is no
> > longer than 1 second.
> >
> > I also imposed a somewhat arbitrary minimum legal connect timeout value
> of
> > 50 ms, but again we could discuss what the right value should be if we
> need
> > one.
> >
> > What do you think?
> >
> > Thanks,
> > Sangjin
> >
> >
> > On Feb 5, 2008 7:46 AM, Sangjin Lee <[EMAIL PROTECTED]> wrote:
> >
> > > Right, that's why I said the connect timeout limitation seems tied to
> the
> > > select timeout...
> > > Hard-coded 1 second select timeout will interfere with sub-second
> connect
> > > timeout value. One obvious suggestion is to set the select timeout to
> be
> > > the same as the connect timeout. That way, we're pretty sure that the
> > > connect timeout will be honored.
> > >
> > > One small drawback is that we'd end up with a busy select loop if the
> > > connect timeout is too small. This could be prevented by having a
> minimum
> > > connect/select timeout value...
> > >
> > > Also, note that the 1-second timeout is pervasive elsewhere (like
> > > processor, etc.). Not sure if we need to change them also. Maybe not
> right
> > > now...
> > >
> > > If you guys don't mind, I'll file a bug (both for 1.1.x and 2.x) and
> > > submit a patch also... How's that sound?
> > >
> > > BTW, what is up with the 1 second sleep in the try-catch clause in the
> > > same code area? We can leave it as is?
> > >
> > > } catch (Throwable e) {
> > >
> > > ExceptionMonitor.getInstance().exceptionCaught(e);
> > >
> > >
> > > try {
> > >
> > > Thread.sleep(1000);
> > >
> > > } catch (InterruptedException e1) {
> > >
> > > ExceptionMonitor.getInstance
> > > ().exceptionCaught(e1);
> > >
> > > }
> > >
> > > }
> > >
> > > Thanks,
> > > Sangjin
> > >
> > >
> > > On Feb 5, 2008 7:29 AM, Julien Vermillard <[EMAIL PROTECTED]>
> wrote:
> > >
> > > > On Tue, 05 Feb 2008 13:55:15 +0100
> > > > Niklas Therning <[EMAIL PROTECTED]> wrote:
> > > > > You would also need to make sure that the current IoConnector
> > > > > implementations can support millisecond timeouts. I think that
> would
> > > > > mean that AbstractPollingIoConnector.Worker needs to be changed.
> > > > > Specifically the line
> > > > >
> > > > > boolean selected = select(1000);
> > > > >
> > > > > To support milliseconds we could simply change this into
> > > > >
> > > > > boolean selected = select(1);
> > > > >
> > > > > but that would be very bad for performance.
> > > > >
> > > > > Instead, one could use an adaptive timeout in the call to select()
> > > > > which depends on the current ConnectRequests' timeouts. Or totally
> > > > > redesign things to use a ScheduledExecutorService or similar
> instead.
> > > > >
> > > >
> > > > Yes Niklas is right, I forgot the impact on worker loop.
> > > >
> > > > At first look an adaptive select timeout or a redesign using some
> kind
> > > > of ExecutorService doesn't look like a trivial move..
> > > >
> > > > Whats the lowest connect timeout needed if it's under 1 seconds ?
> > > >
> > > > Julien
> > > >
> > >
> > >
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
>
Re: connect timeout
We could let the connector automatically adjust the select timeout value
if the current select timeout is greater than the specified connect
timeout.
2008-02-12 (화), 21:16 -0800, Sangjin Lee 쓰시길:
> Yes, it would be great if users can configure the select timeout.
> One small issue that I have, however, is if the select timeout is longer
> than the connect timeout. Then it is possible that the connect timeout will
> not always be honored because select will not wake up until select timeout
> pops.
>
> It is understood that it would happen only if there are no other connect
> events happening, but a select timeout that is longer than the connect
> timeout will effectively interfere with the proper connect timeout. How
> shall we address that situation?
>
> Thanks,
> Sangjin
>
>
> On Feb 12, 2008 8:43 PM, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote:
>
> > Thanks Sanjin for the patch. It looks pretty good. One tiny thing I'd
> > like to point out is that it would be much nicer if a user can configure
> > the selector timeout parameter. For example, we could leave the default
> > '1000', and let people reconfigure that by calling the following
> > statement:
> >
> > connector.setMaxConnectTimeoutCheckInterval(50); // ms
> >
> > I'm not sure if this property name is good, but it's my idea that we
> > need to make it configurable rather than hard-coding it.
> >
> > In the same context, we could make the idle time check interval also
> > configurable. WDYT?
> >
> > 2008-02-06 (수), 10:09 -0800, Sangjin Lee 쓰시길:
> > > I have filed a JIRA issue (
> > https://issues.apache.org/jira/browse/DIRMINA-527),
> > > and submitted a patch for this.
> > >
> > > In the patch I added IoConnector.setConnectTimeoutMillis(), and
> > deprecated
> > > getConnectTimeout()/setConnectTimeout() in favor of the new ones.
> > Perhaps
> > > one could go as far as removing them? I wasn't sure...
> > >
> > > Also, the select timeout is now tied to the connect timeout, but still
> > is no
> > > longer than 1 second.
> > >
> > > I also imposed a somewhat arbitrary minimum legal connect timeout value
> > of
> > > 50 ms, but again we could discuss what the right value should be if we
> > need
> > > one.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > Sangjin
> > >
> > >
> > > On Feb 5, 2008 7:46 AM, Sangjin Lee <[EMAIL PROTECTED]> wrote:
> > >
> > > > Right, that's why I said the connect timeout limitation seems tied to
> > the
> > > > select timeout...
> > > > Hard-coded 1 second select timeout will interfere with sub-second
> > connect
> > > > timeout value. One obvious suggestion is to set the select timeout to
> > be
> > > > the same as the connect timeout. That way, we're pretty sure that the
> > > > connect timeout will be honored.
> > > >
> > > > One small drawback is that we'd end up with a busy select loop if the
> > > > connect timeout is too small. This could be prevented by having a
> > minimum
> > > > connect/select timeout value...
> > > >
> > > > Also, note that the 1-second timeout is pervasive elsewhere (like
> > > > processor, etc.). Not sure if we need to change them also. Maybe not
> > right
> > > > now...
> > > >
> > > > If you guys don't mind, I'll file a bug (both for 1.1.x and 2.x) and
> > > > submit a patch also... How's that sound?
> > > >
> > > > BTW, what is up with the 1 second sleep in the try-catch clause in the
> > > > same code area? We can leave it as is?
> > > >
> > > > } catch (Throwable e) {
> > > >
> > > > ExceptionMonitor.getInstance().exceptionCaught(e);
> > > >
> > > >
> > > > try {
> > > >
> > > > Thread.sleep(1000);
> > > >
> > > > } catch (InterruptedException e1) {
> > > >
> > > > ExceptionMonitor.getInstance
> > > > ().exceptionCaught(e1);
> > > >
> > > > }
> > > >
> > > > }
> > > >
> > > > Thanks,
> > > > Sangjin
> > > >
> > > >
> > > > On Feb 5, 2008 7:29 AM, Julien Vermillard <[EMAIL PROTECTED]>
> > wrote:
> > > >
> > > > > On Tue, 05 Feb 2008 13:55:15 +0100
> > > > > Niklas Therning <[EMAIL PROTECTED]> wrote:
> > > > > > You would also need to make sure that the current IoConnector
> > > > > > implementations can support millisecond timeouts. I think that
> > would
> > > > > > mean that AbstractPollingIoConnector.Worker needs to be changed.
> > > > > > Specifically the line
> > > > > >
> > > > > > boolean selected = select(1000);
> > > > > >
> > > > > > To support milliseconds we could simply change this into
> > > > > >
> > > > > > boolean selected = select(1);
> > > > > >
> > > > > > but that would be very bad for performance.
> > > > > >
> > > > > > Instead, one could use an adaptive timeout in the call to select()
> > > > > > which depends on the current ConnectRequests' timeouts. Or totally
> > > > > > redesign things to use a ScheduledExecutorService or similar
> > instead.
> > > > > >
> > > > >
>
Re: hot deploy IoFilter?
Our JMX integration module in trunk (2.x) provides a way to insert an IoFilter via JMX console easily. One limitation is that the filter should be registered as an MBean already. Because an IoFilter doesn't restrict the signature of its constructor, you will have to implement your own mechanism to instantiate a filter and register it as an MBean. Trustin 2008-02-08 (금), 16:49 -0800, pnguyen42 쓰시길: > Not exactly. By hot deploy I mean add an IoFilter to an IoSession that > doesn't yet exist. The ability to add new IoFilter's to a deployed MINA > application without shutting it down. And without recompiling the MINA app. > I think it's doable but you would have to expose the ability to add an > IoFilter to the filter chain (not IoSession based but IoService based) via > JMX and then use dynamic class loading. Thoughts? Has anyone does this yet? > Or is my interpretation of "hot deployable" wrong? Regardless, I'm going to > do it, I was just hoping someone already has... > > -pn42 > > > Mike Heath-4 wrote: > > > > By hot deploy do you mean adding a filter to a connected IoSession? If > > so, look at IoSession.getFilterChain().add(...) > > > > -Mike > > > > pnguyen42 wrote: > >> I've read the documentation and searched this forum, but can't seem to > >> find > >> doc's on how to hot deploy an IoFilter. Can anyone point me to some > >> documentation for this feature? Thanks in advance... > >> > >> -pn42 > > > > > > > -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
Re: connect timeout
Thanks Sanjin for the patch. It looks pretty good. One tiny thing I'd
like to point out is that it would be much nicer if a user can configure
the selector timeout parameter. For example, we could leave the default
'1000', and let people reconfigure that by calling the following
statement:
connector.setMaxConnectTimeoutCheckInterval(50); // ms
I'm not sure if this property name is good, but it's my idea that we
need to make it configurable rather than hard-coding it.
In the same context, we could make the idle time check interval also
configurable. WDYT?
2008-02-06 (수), 10:09 -0800, Sangjin Lee 쓰시길:
> I have filed a JIRA issue (https://issues.apache.org/jira/browse/DIRMINA-527),
> and submitted a patch for this.
>
> In the patch I added IoConnector.setConnectTimeoutMillis(), and deprecated
> getConnectTimeout()/setConnectTimeout() in favor of the new ones. Perhaps
> one could go as far as removing them? I wasn't sure...
>
> Also, the select timeout is now tied to the connect timeout, but still is no
> longer than 1 second.
>
> I also imposed a somewhat arbitrary minimum legal connect timeout value of
> 50 ms, but again we could discuss what the right value should be if we need
> one.
>
> What do you think?
>
> Thanks,
> Sangjin
>
>
> On Feb 5, 2008 7:46 AM, Sangjin Lee <[EMAIL PROTECTED]> wrote:
>
> > Right, that's why I said the connect timeout limitation seems tied to the
> > select timeout...
> > Hard-coded 1 second select timeout will interfere with sub-second connect
> > timeout value. One obvious suggestion is to set the select timeout to be
> > the same as the connect timeout. That way, we're pretty sure that the
> > connect timeout will be honored.
> >
> > One small drawback is that we'd end up with a busy select loop if the
> > connect timeout is too small. This could be prevented by having a minimum
> > connect/select timeout value...
> >
> > Also, note that the 1-second timeout is pervasive elsewhere (like
> > processor, etc.). Not sure if we need to change them also. Maybe not right
> > now...
> >
> > If you guys don't mind, I'll file a bug (both for 1.1.x and 2.x) and
> > submit a patch also... How's that sound?
> >
> > BTW, what is up with the 1 second sleep in the try-catch clause in the
> > same code area? We can leave it as is?
> >
> > } catch (Throwable e) {
> >
> > ExceptionMonitor.getInstance().exceptionCaught(e);
> >
> >
> > try {
> >
> > Thread.sleep(1000);
> >
> > } catch (InterruptedException e1) {
> >
> > ExceptionMonitor.getInstance
> > ().exceptionCaught(e1);
> >
> > }
> >
> > }
> >
> > Thanks,
> > Sangjin
> >
> >
> > On Feb 5, 2008 7:29 AM, Julien Vermillard <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 05 Feb 2008 13:55:15 +0100
> > > Niklas Therning <[EMAIL PROTECTED]> wrote:
> > > > You would also need to make sure that the current IoConnector
> > > > implementations can support millisecond timeouts. I think that would
> > > > mean that AbstractPollingIoConnector.Worker needs to be changed.
> > > > Specifically the line
> > > >
> > > > boolean selected = select(1000);
> > > >
> > > > To support milliseconds we could simply change this into
> > > >
> > > > boolean selected = select(1);
> > > >
> > > > but that would be very bad for performance.
> > > >
> > > > Instead, one could use an adaptive timeout in the call to select()
> > > > which depends on the current ConnectRequests' timeouts. Or totally
> > > > redesign things to use a ScheduledExecutorService or similar instead.
> > > >
> > >
> > > Yes Niklas is right, I forgot the impact on worker loop.
> > >
> > > At first look an adaptive select timeout or a redesign using some kind
> > > of ExecutorService doesn't look like a trivial move..
> > >
> > > Whats the lowest connect timeout needed if it's under 1 seconds ?
> > >
> > > Julien
> > >
> >
> >
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
Re: WriteTimeoutException immediately following write
2007-11-04 (일), 13:40 -0800, Seth Pollack 쓰시길: > > > Whenever something is > > written, lastWriteTime is updated automatically, and > > WriteTimeoutException is raised only when lastWriteTime has not been > > updated for a certain amount of time. Looking into > > SocketIoProcessor.java, it attempts to write first (i.e. doFlush()) > > and then check timeout (i.e. notifyIdleness()). > > I have a related question. > > Is it possible to ever get a WriteTimeoutException because of something > moving very slowly on the writing app side, or can this only be caused by > the receiving app side moving slowly (i.e. not accepting any bytes for more > than the writeTimeout period)? In the code I saw the comment "// Kernel > buffer is full" in the case where there are bytes to write that can't be > written. What are the possible causes of this condition? It's thrown only when the receiving party is not receiving the data fast enough, which lead the full kernel send buffer. -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
Re: doubt Mina
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/ signature.asc Description: This is a digitally signed message part
Blocking DNS queries (Was: Re: [AsyncWeb] Ideas for client)
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. 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. -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
[jira] Commented: (DIRMINA-499) Bindings for Scala
[ https://issues.apache.org/jira/browse/DIRMINA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568430#action_12568430 ] Trustin Lee commented on DIRMINA-499: - Thank you Rich for your continuous update. I am impressed. I also find Scala a very good language and am learning it step by step. Hopefully I could help you soon... > Bindings for Scala > -- > > Key: DIRMINA-499 > URL: https://issues.apache.org/jira/browse/DIRMINA-499 > Project: MINA > Issue Type: New Feature > Components: Example, Integration >Affects Versions: 2.0.0-M1 >Reporter: Rich Dougherty >Priority: Minor > Attachments: bindings-for-scala.2.patch, bindings-for-scala.patch > > > Here's a contribution of bindings for the Scala language. Since announcing an > initial version six weeks ago, I've taken some time to improve and extend > them. They're now quite different from that first version. They still needs > more documentation and some unit tests, but are generally in a state that I'm > happy with. > Notes: > - Patch is against trunk. > - The bindings are in a new submodule called "integration-scala". > - Scala examples have been added to the "example" submodule. These are also > currently the best documentation for the bindings. > - Code is formatted and indented according to the convention used in the > Scala compiler, which I take to be the "standard" for Scala code. > Warning: This patch approximately doubles the time it takes to perform a "mvn > -Dmaven.test.skip install" on my computer. This time can probably be improved > by trying to run the Scala compiler once within each submodule, rather than > multiple times, but the effect will still be noticeable. If this increase in > build time is problem, then the bindings probably may need to stay outside > MINA's trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: mina and jdk6u4
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/
signature.asc
Description: This is a digitally signed message part
Re: connect timeout
Sounds good. :)
Thanks,
Sangjin
On Feb 12, 2008 9:21 PM, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote:
> We could let the connector automatically adjust the select timeout value
> if the current select timeout is greater than the specified connect
> timeout.
>
> 2008-02-12 (화), 21:16 -0800, Sangjin Lee 쓰시길:
> > Yes, it would be great if users can configure the select timeout.
> > One small issue that I have, however, is if the select timeout is longer
> > than the connect timeout. Then it is possible that the connect timeout
> will
> > not always be honored because select will not wake up until select
> timeout
> > pops.
> >
> > It is understood that it would happen only if there are no other connect
> > events happening, but a select timeout that is longer than the connect
> > timeout will effectively interfere with the proper connect timeout. How
> > shall we address that situation?
> >
> > Thanks,
> > Sangjin
> >
> >
> > On Feb 12, 2008 8:43 PM, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote:
> >
> > > Thanks Sanjin for the patch. It looks pretty good. One tiny thing
> I'd
> > > like to point out is that it would be much nicer if a user can
> configure
> > > the selector timeout parameter. For example, we could leave the
> default
> > > '1000', and let people reconfigure that by calling the following
> > > statement:
> > >
> > > connector.setMaxConnectTimeoutCheckInterval(50); // ms
> > >
> > > I'm not sure if this property name is good, but it's my idea that we
> > > need to make it configurable rather than hard-coding it.
> > >
> > > In the same context, we could make the idle time check interval also
> > > configurable. WDYT?
> > >
> > > 2008-02-06 (수), 10:09 -0800, Sangjin Lee 쓰시길:
> > > > I have filed a JIRA issue (
> > > https://issues.apache.org/jira/browse/DIRMINA-527),
> > > > and submitted a patch for this.
> > > >
> > > > In the patch I added IoConnector.setConnectTimeoutMillis(), and
> > > deprecated
> > > > getConnectTimeout()/setConnectTimeout() in favor of the new ones.
> > > Perhaps
> > > > one could go as far as removing them? I wasn't sure...
> > > >
> > > > Also, the select timeout is now tied to the connect timeout, but
> still
> > > is no
> > > > longer than 1 second.
> > > >
> > > > I also imposed a somewhat arbitrary minimum legal connect timeout
> value
> > > of
> > > > 50 ms, but again we could discuss what the right value should be if
> we
> > > need
> > > > one.
> > > >
> > > > What do you think?
> > > >
> > > > Thanks,
> > > > Sangjin
> > > >
> > > >
> > > > On Feb 5, 2008 7:46 AM, Sangjin Lee <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Right, that's why I said the connect timeout limitation seems tied
> to
> > > the
> > > > > select timeout...
> > > > > Hard-coded 1 second select timeout will interfere with sub-second
> > > connect
> > > > > timeout value. One obvious suggestion is to set the select
> timeout to
> > > be
> > > > > the same as the connect timeout. That way, we're pretty sure that
> the
> > > > > connect timeout will be honored.
> > > > >
> > > > > One small drawback is that we'd end up with a busy select loop if
> the
> > > > > connect timeout is too small. This could be prevented by having a
> > > minimum
> > > > > connect/select timeout value...
> > > > >
> > > > > Also, note that the 1-second timeout is pervasive elsewhere (like
> > > > > processor, etc.). Not sure if we need to change them also. Maybe
> not
> > > right
> > > > > now...
> > > > >
> > > > > If you guys don't mind, I'll file a bug (both for 1.1.x and 2.x)
> and
> > > > > submit a patch also... How's that sound?
> > > > >
> > > > > BTW, what is up with the 1 second sleep in the try-catch clause in
> the
> > > > > same code area? We can leave it as is?
> > > > >
> > > > > } catch (Throwable e) {
> > > > >
> > > > > ExceptionMonitor.getInstance
> ().exceptionCaught(e);
> > > > >
> > > > >
> > > > > try {
> > > > >
> > > > > Thread.sleep(1000);
> > > > >
> > > > > } catch (InterruptedException e1) {
> > > > >
> > > > > ExceptionMonitor.getInstance
> > > > > ().exceptionCaught(e1);
> > > > >
> > > > > }
> > > > >
> > > > > }
> > > > >
> > > > > Thanks,
> > > > > Sangjin
> > > > >
> > > > >
> > > > > On Feb 5, 2008 7:29 AM, Julien Vermillard <[EMAIL PROTECTED]>
> > > wrote:
> > > > >
> > > > > > On Tue, 05 Feb 2008 13:55:15 +0100
> > > > > > Niklas Therning <[EMAIL PROTECTED]> wrote:
> > > > > > > You would also need to make sure that the current IoConnector
> > > > > > > implementations can support millisecond timeouts. I think that
> > > would
> > > > > > > mean that AbstractPollingIoConnector.Worker needs to be
> changed.
> > > > > > > Specifically the line
> > > > > > >
> > > > > > > boolean selected = select(1000);
> > > > > > >
> > > > > > > To support milliseconds we could simply change this into
> > > > > > >
> >
Re: [AsyncWeb] Ideas for client
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 > > Rick > > Mike Heath wrote: >> I posted some use cases here: >> http://cwiki.apache.org/confluence/display/AWEB/ClientUseCases They >> still need some refinement to properly convey what I want but they're a >> decent start. >> >> I've also posted a hypothetical AsyncWeb Client API at >> http://swamp.homelinux.net/mina/asyncweb/client/api/ with the intent to >> further promote discussion and foster more innovative ideas. I would >> love to here some feedback on this API. What do you like, dislike, not >> understand? Where do you see room for improvement? The API is really >> rough in places but for the most part it conveys the ideas I've had over >> the past week or so. Any suggestions for name changes to classes and/or >> methods are welcome. >> >> -Mike >> >> > >
Re: [AsyncWeb] Ideas for client
Hi, I've started an asyncronous DNS client based on MINA for my HTTP caching proxy (also based on MINA: http://alijo.googlecode.com ) The client is based on the code from the DNS server in Apache Directory. The implementations is not complete yes as : * Only returns first IP address in the DNS reply * Only uses first DNS server (primary), as read from /etc/resolv.conf * Can cache DNS addresses, but.. caches forever as no expiration is applied * Does not use aliases I plan to work more on the DNS client. If anyone is interested, the sources can be found here: DNS Codec: http://alijo.googlecode.com/svn/trunk/protocol-dns/ DNS Client: http://alijo.googlecode.com/svn/trunk/alijo/src/main/java/org/mm/proxycache/dns/ Again, the code is not polished , but if there is interest I can work onrefining it and extracting it in a decent form. Regards, Matteo <[EMAIL PROTECTED]> On Feb 12, 2008 3:59 PM, Eero Nevalainen <[EMAIL PROTECTED]> 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? > > -Eero > > > 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. > > > > Rick > > > > Mike Heath wrote: > >> I posted some use cases here: > >> http://cwiki.apache.org/confluence/display/AWEB/ClientUseCases They > >> still need some refinement to properly convey what I want but they're a > >> decent start. > >> > >> I've also posted a hypothetical AsyncWeb Client API at > >> http://swamp.homelinux.net/mina/asyncweb/client/api/ with the intent to > >> further promote discussion and foster more innovative ideas. I would > >> love to here some feedback on this API. What do you like, dislike, not > >> understand? Where do you see room for improvement? The API is really > >> rough in places but for the most part it conveys the ideas I've had over > >> the past week or so. Any suggestions for name changes to classes and/or > >> methods are welcome. > >> > >> -Mike > >> > >> > > > > -- Matteo Merli <[EMAIL PROTECTED]>
Re: [AsyncWeb] Ideas for client
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 complex cases (like doing a PUT with a file, for example.) We need to find a balance of simplicity and function and I'm not sure where that point is at. Some of the issues that need to be addressed with supporting sending raw HttpRequest objects using the HttpClient (the way I've modeled it, that is) are: - If the HttpClient has connection pooling enabled but a request is sent without KeepAlive and Connection headers, do we automatically change the request to turn keepAlive on and use connection pooling or do we create a new connection? - If the HttpClient has a cookie manager, do we automatically add cookies to a manually created HttpRequest? - Are there other headers that we would want to automatically populate if their absent (User-Agent, Accept*, etc.) ? - Do we even want to modify a manually created HttpRequest? Should this be configurable? If so how? I don't have answers to these questions which is why I decided to just put support for sending raw HttpRequest messages in the HttpConnection interface because that's the interface I intended to make available for complex use cases (COMET, dealing with large data streams, etc.) However, I think we need to find some middle ground. I'm just not sure where that middle ground is. Thanks again for your feedback, Rick. -Mike > > >> >> >> >>> Rick >>> >>> Mike Heath wrote: >>> I posted some use cases here: http://cwiki.apache.org/confluence/display/AWEB/ClientUseCases They still need some refinement to properly convey what I want but they're a decent start. I've also posted a hypothetical AsyncWeb Client API at http://swamp.homelinux.net/mina/asyncweb/client/api/ with the intent to further promote discussion and foster more innovative ideas. I would love to here some feedback on this API. What do you like, dislike, not understand? Where do you see room for improvement? The API is really rough in places but for the most part it conveys the ideas I've had over the past week or so. Any suggestions for name changes to classes and/or methods are welcome. -Mike >>> >> >> >> > >
Re: [VOTE] Release Apache MINA 2.0-M1
Julien Vermillard wrote: > On Tue, 12 Feb 2008 01:11:47 -0500 > 이희승 "(Trustin Lee)" <[EMAIL PROTECTED]> wrote: > >> 2008-02-11 (월), 20:35 -0700, Mike Heath 쓰시길: >>> [X]: +1, Release MINA 2.0-M1 >> Nice to see you fire the vote, which means another person will get to >> know how to deal with the whole release procedure, as described in our >> developer's guide. You could ask me or Julien if you have any >> questions. >> >> Cheers, >> Trustin > > +1, > I can help for the release, I need to update the guide a little for add > some configuration details. Any help would be greatly appreciated. My inexperience with cutting a MINA release should help with finding holes in the release guide. As I go through the release process, I'll try to update the release guide where appropriate. I guess I need to vote too. +1 -Mike > Julien >
Re: MINA at JavaOne 2008 - idea wanted
I think it would be also interesting to discuss the higher-level appeal of MINA. For anyone not familiar with it at the talk, I think the amazing thing about MINA is how easily you can create really robust, high performance clients and servers for any protocol extremely quickly -- the advantages of the abstractions in the API. It gives developers incredible latitude to implement existing protocols and/or to create completely new ones. That's a huge gift and a major boost for maximizing the creative potential of developers on the Internet. -Adam On Feb 12, 2008 3:47 AM, Julien Vermillard <[EMAIL PROTECTED]> wrote: > On Tue, 12 Feb 2008 01:18:52 -0500 > 이희승 "(Trustin Lee)" <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > I was invited as a speaker of JavaOne 2008 and will speak about Apache > > MINA there. Please feel free to contact me to give me some idea about > > what you want to hear about MINA if you have any plan to attend this > > year's JavaOne. > > > > Cheers, > > Trustin > > I have no plan to attend to JavaOne :) but here want I would like to > hear : > > # 2.0 new features and API > > # presentation of new Apache apps using MINA : > - FTPServer > - AHC > - Aweb > - ... > -- http://www.littleshoot.org Open Source, Open Standards, Open Data
Re: [VOTE] Release Apache MINA 2.0-M1
[X]: +1, Release MINA 2.0-M1 On Feb 12, 2008 8:52 AM, Niklas Gustavsson <[EMAIL PROTECTED]> wrote: > Mike Heath wrote: > > [ ]: +1, Release MINA 2.0-M1 > > [ ]: 0, Abstain > > [ ]: -1, Don't release MINA 2.0-M1 > > > +1. Basing FtpServer on 2.0-M1-SNAPSHOT has been without any issues, > well, caused by MINA anyways :-) > > /niklas > > -- Brenno Hayden F. Dantas
Re: Blocking DNS queries (Was: Re: [AsyncWeb] Ideas for client)
이희승 (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. -Mike
Re: [AsyncWeb] Ideas for client
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. Rick Mike Heath wrote: I posted some use cases here: http://cwiki.apache.org/confluence/display/AWEB/ClientUseCases They still need some refinement to properly convey what I want but they're a decent start. I've also posted a hypothetical AsyncWeb Client API at http://swamp.homelinux.net/mina/asyncweb/client/api/ with the intent to further promote discussion and foster more innovative ideas. I would love to here some feedback on this API. What do you like, dislike, not understand? Where do you see room for improvement? The API is really rough in places but for the most part it conveys the ideas I've had over the past week or so. Any suggestions for name changes to classes and/or methods are welcome. -Mike
Re: [VOTE] Release Apache MINA 2.0-M1
Mike Heath wrote: [ ]: +1, Release MINA 2.0-M1 [ ]: 0, Abstain [ ]: -1, Don't release MINA 2.0-M1 +1. Basing FtpServer on 2.0-M1-SNAPSHOT has been without any issues, well, caused by MINA anyways :-) /niklas
Re : [VOTE] Release Apache MINA 2.0-M1
[X]: +1, Release MINA 2.0-M1 Cordialement, Regards, -Edouard De Oliveira- http://tedorg.free.fr/en/main.php _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr
Re: [AsyncWeb] Ideas for client
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? -Eero 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. Rick Mike Heath wrote: I posted some use cases here: http://cwiki.apache.org/confluence/display/AWEB/ClientUseCases They still need some refinement to properly convey what I want but they're a decent start. I've also posted a hypothetical AsyncWeb Client API at http://swamp.homelinux.net/mina/asyncweb/client/api/ with the intent to further promote discussion and foster more innovative ideas. I would love to here some feedback on this API. What do you like, dislike, not understand? Where do you see room for improvement? The API is really rough in places but for the most part it conveys the ideas I've had over the past week or so. Any suggestions for name changes to classes and/or methods are welcome. -Mike
Re: MINA at JavaOne 2008 - idea wanted
Jeff Genender wrote: > Yeah I am in agreement with Mike. An architectural overview...and an > example (heck use AHC vs HttpClient) and show how it scales. That will > get ooohs and ahhhs. > Jeff +1, using a protocol that a lot of developers people are actually familiar with would help a lot. -Mike > Mike Heath wrote: >> One of the problems I've had when promoting MINA is that most Java >> developers don't understand the scalability implications of the >> thread-per-connection architecture. If I jump right in with how cool >> MINA is with its separation of concerns, futures, filters, event >> mechanism, simplifies packet fragmentation problems, etc., the audience >> either gets lost or replies with something like, "Using InputStreamsis >> just as flexible as filters but doesn't come with all the difficulties >> of having to build a state machine. MINA just makes things complicated!" >> >> However, if I start out showing how quickly I get an OOM exception when >> using a thread-per-connection architecture and then show how I can >> handle thousands of connections in MINA without consuming loads of >> memory, the audience is able to better understand the main problem that >> MINA solves. Showing how painful it is to use NIO directly is fairly >> simple at this point. The important part is making sure the audience >> understands the need for the functionality that NIO has to offer. >> >> Once the audience understands the problems MINA solves, I've found >> they're usually much more receptive to the coolness that MINA has to >> offer. >> >> Just my $0.02. >> >> -Mike >> >> 이희승 (Trustin Lee) wrote: >>> Hi, >>> >>> I was invited as a speaker of JavaOne 2008 and will speak about Apache >>> MINA there. Please feel free to contact me to give me some idea about >>> what you want to hear about MINA if you have any plan to attend this >>> year's JavaOne. >>> >>> Cheers, >>> Trustin >
