Re: Fwd: Google Summer of Code: Bring out your projects
Hello,
I am interested about this project for GSoC.
I've started writing a PoC for this. I want to ask you if I'm going in
the right direction.
It would be nice if the server could handle both standard XMPP clients
(5222) and xbosh (443 or 80). So MINA binds to 2 ports in TCPEndpoint
(for this I added an extra xbosh configurable port in TCPEndpoint).
The HTTP headers are decoded by XMLStreamTokenizer as XMLText
(XMLRawToFragmentConverter#convert).
So when receiving HTTP there would be 2 options:
1) To use the current XMLStreamTokenizer decoder and add a new
o.a.v.xmpp.Stanza (ignoring the XMLText headers)
2) To have another decoder that decodes HTTP (having access to
headers) and then process the .
I know that xbosh says that we should ignore all the headers (except
maybe Accept-Encoding), but maybe there is some use for them.
Another option would be to parse the XMLText thrown in
XmppIoHandlerAdapter#messageReceivedNoStanza, but I incline to think
that this is not the right place.
I chose option 2) with the decoder option chosen like this:
public ProtocolDecoder getDecoder(IoSession s) throws Exception {
if (((InetSocketAddress) s.getLocalAddress()).getPort() ==
xboshPort) {
return new XBoshDecoder(new XMLStreamTokenizer(new
StanzaBuilderFactory()));
} else {
return new XMLStreamTokenizer(new
StanzaBuilderFactory());
}
}
And the XBoshDecoder uses the Apache AsyncWeb HTTP codec that does a
nice job at parsing HTTP.
Do you think this is overkill? I have some doubts, but I like that all
the HTTP information is available.
For SSL encryption I am thinking of putting the SSL filter by default
if the port 443 is configured for xbosh. To configure 2 IO filter
chains in MINA I don't know any other way but just to create a new
NioSocketAcceptor with a different chain.
I'll write more when I'll advance with the implementation.
Thanks,
Bogdan
On Tue, Mar 16, 2010 at 11:02 AM, Niklas Gustavsson
wrote:
> On Tue, Mar 16, 2010 at 8:31 AM, Ashish wrote:
>> Which project are we submitting?
>
> I've added the BOSH/WebSockets project:
> https://issues.apache.org/jira/browse/VYSPER-189
>
> /niklas
>
Re: [VOTE] Move Vysper out of sandbox
> >> [X] +1, move Vysper out of the sandbox >> > > And when it's done, let's bring the champagne ! +1, I am going to miss the champagne :( but will celebrate. Happy B'day Vysper :)
Re: FTPServer handling of multiple concurrent connections.
Since changing everything over to MINA could be quite a bit of work, and the issue we have is somewhat serious, we should come up with a short term solution first and release a patch. Perhaps this patch would do the following: Option 1: Have Max Threads as a configurable option at the server level. Each listener would share the same thread pool. Option 2: Have Max Threads as a configurable option at the listener (acceptor) level. I prefer option 1 as most people would look at the server level rather than listener level. In other words, my server should be able to handle 200 concurrent users. If Max Threads is not specified, may be we should default it to maxUsers/connections that we have. Not sure what the current keep-alive time for the threads is, but perhaps having a shorter keep-alive time may help in some cases, or make it as a configurable option. What do you think? Regards, Sai Pullabhotla On Tue, Mar 30, 2010 at 8:33 AM, Niklas Gustavsson wrote: > On Tue, Mar 30, 2010 at 2:22 PM, David Latorre wrote: >> I would rather go for a solution that make it impossible to block >> FTPServer rather than making it 'more difficult'. >> For this, we might limit the total number of data connections which >> wouldn't be perfect but might help... or maybe we can enforce a rule >> that MaxUsers < MaxThreads. > > Depending on your user profiles, I think there might be different > configurations that suites you best. So, I think we should supply both > the max concurrent users option (that we do today) and a max threads > option. Then, we need to provide reasonable defaults and documentation > on how to best use them. > >> - We could have a filter that limited bandwidth usage, although I >> don't think there is anything like that in FTPServer. > > We already do bandwidth limitation in our blocking data connections. > > /niklas >
Re: [VOTE] Move Vysper out of sandbox
+1 On Tue, Mar 30, 2010 at 15:41, Bernd Fondermann < bernd.fonderm...@googlemail.com> wrote: > Hi everyone, > > Vysper came from Labs to the MINA sandbox. > > Meanwhile, we were able to improve the codebase, but it's clear we're > not where we would like to be. > We identified that the areas documentation, javadoc and website need more > work. > > On the plus side, we were able to complete the first release of Vysper > a few hours ago. > > However, I think it's time to promote Vysper out of sandbox, so I call > for a vote: > > [ ] +1, move Vysper out of the sandbox > [ ] +-0, I'm not sure, playing in the sand can be great fun sometimes > [ ] -1, Vysper is not ready yet, leave this strange stanza-emitting > machine where it belongs > > The vote will not close before 2010-04-07T12:00 UTC, due to the > upcoming holidays in some parts of the world. > > Thanks for voting, > > Bernd > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Move Vysper out of sandbox
+1 On Tue, Mar 30, 2010 at 5:10 PM, Julien Vermillard wrote: > Le Tue, 30 Mar 2010 15:41:42 +0200, > Bernd Fondermann a écrit : > > > Hi everyone, > > > > Vysper came from Labs to the MINA sandbox. > > > > Meanwhile, we were able to improve the codebase, but it's clear we're > > not where we would like to be. > > We identified that the areas documentation, javadoc and website need > > more work. > > > > On the plus side, we were able to complete the first release of Vysper > > a few hours ago. > > > > However, I think it's time to promote Vysper out of sandbox, so I call > > for a vote: > > > > [ ] +1, move Vysper out of the sandbox > > [ ] +-0, I'm not sure, playing in the sand can be great fun sometimes > > [ ] -1, Vysper is not ready yet, leave this strange stanza-emitting > > machine where it belongs > > > > The vote will not close before 2010-04-07T12:00 UTC, due to the > > upcoming holidays in some parts of the world. > > > > Thanks for voting, > > > > Bernd > > +1 > keep up the good work. > > -- > Julien Vermillard > > Archean Technologies > http://www.archean.fr > -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [VOTE] Move Vysper out of sandbox
Le Tue, 30 Mar 2010 15:41:42 +0200, Bernd Fondermann a écrit : > Hi everyone, > > Vysper came from Labs to the MINA sandbox. > > Meanwhile, we were able to improve the codebase, but it's clear we're > not where we would like to be. > We identified that the areas documentation, javadoc and website need > more work. > > On the plus side, we were able to complete the first release of Vysper > a few hours ago. > > However, I think it's time to promote Vysper out of sandbox, so I call > for a vote: > > [ ] +1, move Vysper out of the sandbox > [ ] +-0, I'm not sure, playing in the sand can be great fun sometimes > [ ] -1, Vysper is not ready yet, leave this strange stanza-emitting > machine where it belongs > > The vote will not close before 2010-04-07T12:00 UTC, due to the > upcoming holidays in some parts of the world. > > Thanks for voting, > > Bernd +1 keep up the good work. -- Julien Vermillard Archean Technologies http://www.archean.fr signature.asc Description: PGP signature
Re: [VOTE] Move Vysper out of sandbox
[X] +1, move Vysper out of the sandbox And when it's done, let's bring the champagne ! -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com
Re: [VOTE] Move Vysper out of sandbox
On Tue, Mar 30, 2010 at 2:41 PM, Bernd Fondermann wrote: > [X] +1, move Vysper out of the sandbox /niklas
Re: [VOTE] Move Vysper out of sandbox
[X ] +1, move Vysper out of the sandbox Bernd
[VOTE] Move Vysper out of sandbox
Hi everyone, Vysper came from Labs to the MINA sandbox. Meanwhile, we were able to improve the codebase, but it's clear we're not where we would like to be. We identified that the areas documentation, javadoc and website need more work. On the plus side, we were able to complete the first release of Vysper a few hours ago. However, I think it's time to promote Vysper out of sandbox, so I call for a vote: [ ] +1, move Vysper out of the sandbox [ ] +-0, I'm not sure, playing in the sand can be great fun sometimes [ ] -1, Vysper is not ready yet, leave this strange stanza-emitting machine where it belongs The vote will not close before 2010-04-07T12:00 UTC, due to the upcoming holidays in some parts of the world. Thanks for voting, Bernd
Re: FTPServer handling of multiple concurrent connections.
On Tue, Mar 30, 2010 at 2:22 PM, David Latorre wrote: > I would rather go for a solution that make it impossible to block > FTPServer rather than making it 'more difficult'. > For this, we might limit the total number of data connections which > wouldn't be perfect but might help... or maybe we can enforce a rule > that MaxUsers < MaxThreads. Depending on your user profiles, I think there might be different configurations that suites you best. So, I think we should supply both the max concurrent users option (that we do today) and a max threads option. Then, we need to provide reasonable defaults and documentation on how to best use them. > - We could have a filter that limited bandwidth usage, although I > don't think there is anything like that in FTPServer. We already do bandwidth limitation in our blocking data connections. /niklas
Re: FTPServer handling of multiple concurrent connections.
2010/3/30 Niklas Gustavsson : > On Tue, Mar 30, 2010 at 10:33 AM, Sai Pullabhotla > wrote: >> I don't think that was intended. If this is in fact an issue, we >> should probably consider adding a configuration option such as >> maxThreads as the default max we choose may not be the best in all >> cases. > > I think David is correct, and I agree with your proposed solution > (defaulting the value higher than 16 thou). We should also look into > moving the data connection over to using MINA, if someone got the > time. I would rather go for a solution that make it impossible to block FTPServer rather than making it 'more difficult'. For this, we might limit the total number of data connections which wouldn't be perfect but might help... or maybe we can enforce a rule that MaxUsers < MaxThreads. Regarding the move of the data connection to MINA, I understand Sai's position that is using blocking-IO here is probably lighter ( It would be nice if we could have the same 'MINA pipeline' accepting on several ports...). Still I see an advantage if we used MINA - filters: - We could have different filters for ASCII mode, binary mode, 'Z' mode or other modes of encoding we or the users might think of (Although it is easy to have custom streams that do this for us with the current implementation). - We can include a fine grained monitoring of current transfers, a filter might inform via JMX or other means of e.g., the amount of data transferred - A filter could limit the quota for a user, for a session, for a week/month for this user in 'real time'. There are other ways to do this as well... - We could have a filter that limited bandwidth usage, although I don't think there is anything like that in FTPServer. Still, several of the possibilities we can think of seem not that useful since we should have multiple 'chains' for data connections. > /niklas >
Re: FTPServer handling of multiple concurrent connections.
On Tue, Mar 30, 2010 at 1:39 PM, Sai Pullabhotla wrote: > What would be the benefit of using MINA compared to the traditional > sockets, especially for passive connections? That we don't get one thread for each one socket. Perhaps this is not such a big issue, at least not as far as your not planning for thousands of concurrent data connections. /niklas
Re: FTPServer handling of multiple concurrent connections.
What would be the benefit of using MINA compared to the traditional sockets, especially for passive connections? Regards, Sai Pullabhotla On Tue, Mar 30, 2010 at 7:33 AM, Niklas Gustavsson wrote: > On Tue, Mar 30, 2010 at 10:33 AM, Sai Pullabhotla > wrote: >> I don't think that was intended. If this is in fact an issue, we >> should probably consider adding a configuration option such as >> maxThreads as the default max we choose may not be the best in all >> cases. > > I think David is correct, and I agree with your proposed solution > (defaulting the value higher than 16 thou). We should also look into > moving the data connection over to using MINA, if someone got the > time. > > /niklas >
Re: FTPServer handling of multiple concurrent connections.
On Tue, Mar 30, 2010 at 10:33 AM, Sai Pullabhotla wrote: > I don't think that was intended. If this is in fact an issue, we > should probably consider adding a configuration option such as > maxThreads as the default max we choose may not be the best in all > cases. I think David is correct, and I agree with your proposed solution (defaulting the value higher than 16 thou). We should also look into moving the data connection over to using MINA, if someone got the time. /niklas
Re: svn commit: r928769 - in /mina/ftpserver/trunk/core/src: main/java/org/apache/ftpserver/config/spring/ main/java/org/apache/ftpserver/ipfilter/ main/java/org/apache/ftpserver/listener/ main/java
On Mon, Mar 29, 2010 at 10:41 PM, Sai Pullabhotla wrote: > BTW, do you know why Hudson is complaining about the test failure on > trunk? I did not get that error locally. I reran the build after it failed, but still no luck. It runs fine on my laptop as well. I think it's a Hudson slave machine hickup, so let's give it some time. /niklas
Re: FTPServer handling of multiple concurrent connections.
I don't think that was intended. If this is in fact an issue, we should probably consider adding a configuration option such as maxThreads as the default max we choose may not be the best in all cases. Regards, Sai Pullabhotla On Tue, Mar 30, 2010 at 3:29 AM, David Latorre wrote: > Hello, > > When inspecting http://issues.apache.org/jira/browse/FTPSERVER-359 I > noticed that we might have an issue with threading in Ftpserver. > > I think we are using a 'fixed size thread pool' with max-threads=16 > for the Executor threadpool in which commands are executed. This would > mean that if we had 16 data transfers currently running , FTPServer > would be blocked until some of these data transfers ended- Is my > understanding correct? > > Is this behaviour desirable for us? I don't think that 16 data > transfers are that many, and some users might need to send huge files. >
Re: svn commit: r928769
Cool, thanks. Regards, Sai Pullabhotla On Tue, Mar 30, 2010 at 3:21 AM, Dave Roberts wrote: > On 29/03/2010 22:35, Sai Pullabhotla wrote: >> >> Of course, a Source Code Formatter posted to the MINA web site would >> definitely be a plus as I do want to format and still keep the >> unchanged stuff as is. > > http://mina.apache.org/developer-guide.data/ImprovedJavaConventions.xml > > Or, go to the MINA home page, click on Developers Guide on the left, > then find the Coding Convention section > > "We follow Sun's standard Java coding convention except that we > always use spaces instead of tabs. Please download the Eclipse Java > formatter settings file before you make any changes to the code." >
FTPServer handling of multiple concurrent connections.
Hello, When inspecting http://issues.apache.org/jira/browse/FTPSERVER-359 I noticed that we might have an issue with threading in Ftpserver. I think we are using a 'fixed size thread pool' with max-threads=16 for the Executor threadpool in which commands are executed. This would mean that if we had 16 data transfers currently running , FTPServer would be blocked until some of these data transfers ended- Is my understanding correct? Is this behaviour desirable for us? I don't think that 16 data transfers are that many, and some users might need to send huge files.
Re: svn commit: r928769
On 29/03/2010 22:35, Sai Pullabhotla wrote: > > Of course, a Source Code Formatter posted to the MINA web site would > definitely be a plus as I do want to format and still keep the > unchanged stuff as is. http://mina.apache.org/developer-guide.data/ImprovedJavaConventions.xml Or, go to the MINA home page, click on Developers Guide on the left, then find the Coding Convention section "We follow Sun's standard Java coding convention except that we always use spaces instead of tabs. Please download the Eclipse Java formatter settings file before you make any changes to the code."
Re: svn commit: r928769 - in /mina/ftpserver/trunk/core/src: main/java/org/apache/ftpserver/config/spring/ main/java/org/apache/ftpserver/ipfilter/ main/java/org/apache/ftpserver/listener/ main/java
Regarding this issue, I downloaded the "common formatter" for Eclipse from the website a while back and (I think!) I'm using it. I use the 'autoformat' feature all the time so I hope that's the one which should be used for FTPServer as well, is it? Otherwise I think it would be great if we defined one so we can get rid of these problems. 2010/3/29 Sai Pullabhotla : > BTW, do you know why Hudson is complaining about the test failure on > trunk? I did not get that error locally. > > Regards, > Sai Pullabhotla > > > > > > On Mon, Mar 29, 2010 at 4:06 PM, Niklas Gustavsson > wrote: >> On Mon, Mar 29, 2010 at 9:39 PM, Emmanuel Lecharny >> wrote: >>> Otherwise, if you think that the coding conventions don't fit, then we can >>> discuss openly here. >> >> I don't mind what coding conventions we use, as long as they are consistent >> :-) >> >> /niklas >> >
[jira] Commented: (FTPSERVER-361) Provide more information on command execution to Ftplets - especially file created in STOU
[ https://issues.apache.org/jira/browse/FTPSERVER-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851302#action_12851302 ] David Latorre commented on FTPSERVER-361: - We can do this but my suggestion is that you do not rely on the provided DefaultFtpLet. In our case, we ended up 'cloning' DefaultFtpLet, but changing some method bodies / signatures in order to fit our needs and this is quite common a need for other users as well. > Provide more information on command execution to Ftplets - especially file > created in STOU > -- > > Key: FTPSERVER-361 > URL: https://issues.apache.org/jira/browse/FTPSERVER-361 > Project: FtpServer > Issue Type: Improvement > Components: Ftplets >Affects Versions: 1.0.4 >Reporter: Richard Evans > > To monitor file uploads, I can configure an Ftplet and override onUploadEnd > and onUploadUniqueEnd in DefaultFtplet. However I cannot find a way to > determine the real file that was written in the upload. > For a non-unique upload I can get the argument and resolve it against the > working directory in the file system view; but this seems unnecessarily > complex and does not for for unique uploads (STOU) because the random file > name is not available. > Browsing the code I can see the file observer stuff, but these are non-public > APIs and there can be only one observer at a time whilst I can have many > independent Ftplets implementing the onUpload APIs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ASk for a feedback
On Tue, Mar 30, 2010 at 06:31, G.W.G.K.N. Udayanga wrote: > Hello Bernard Sir, > Thank you very much for your support.I know that the time to discuss about > the project is now over. Is it? Why? > But if you can please consider about following > things. > > > You question:What would you want to remove? What would be unwanted stanzas? > What do you think is a stanza at all? > > *Stanza is same as xml.(actually another name use in xmpp world). Actually no. Stanza is a data structure, carrying special XMPP semantics, while XML is the syntax to express XMPP stanzas. An analogy: XMPP are the words, stanzas are the sentences. XMPP only uses a subset of XML. > *Here as the removable stanzas i mean xml tags such as , > , and so on which are used for initial handshaking when > dealing with xmpp. Don't know. Presence, IQ, Messages are used all over the place. I don't see any reason to remove anything. > Another one that i didn't get answer from your reply. > > Ajax clients send requests by using url encrypting also(other than the types > of xml document)But for the bosh protocol only xml is allowable as > payload.So do we need to process url encryped requst of ajax client as a > xml formatted one before using bosh protocol? Sorry, I don't understand that question. I think the specs are pretty clear about what has to be send. HTTP from browser to webserver, request payload is mostly XML whether encrypted or not. Bernd
