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
[
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
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
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 MIN
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
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
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,
>
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 h
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
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
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 plan
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
>>
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 ca
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 releas
[X ] +1, move Vysper out of the sandbox
Bernd
On Tue, Mar 30, 2010 at 2:41 PM, Bernd Fondermann
wrote:
> [X] +1, move Vysper out of the sandbox
/niklas
[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
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 websi
+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 wou
+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 docu
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
>
>> [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 :)
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
23 matches
Mail list logo