Le 21/06/2018 à 12:42, Guillaume Nodet a écrit :
> So I can't explain exactly why, but the problem comes from the removal of
> the following variable:
>
> https://github.com/apache/mina/commit/60cb619b6f0a940e7a6b18c060158270c227255b#diff-e3418ff2f83464c155b780cdbfb9e4aaL754
Hmmm...
public
Le 21/06/2018 à 18:30, Guillaume Nodet a écrit :
> Sorry, my link does not work.
> I pinned it down to the removal of the SslHandler#handshakeStatus variable.
Ok, that makes more sense :-)
Can you test a 2.0.19 with this change reverted ?
I can easily cut a 2.0.20 fast. (makes me think that
Hi Guillaume,
I have reverted the change. Can you give it a try ? If it's ok, I can
cut a release right away.
Thanks !
--
Emmanuel Lecharny
Symas.com
directory.apache.org
pEpkey.asc
Description: application/pgp-keys
Hi guys,
the new release policy requires that we remove MD5 signature from the
www.apache.org/dist repository for our projects :
" -- for past releases :
-- you are not required to change anything ;
-- it would be nice if you fixed your dist area ;
-- start with :
Le 14/08/2018 à 19:54, Lyor Goldstein a écrit :
> While going over the MINA SSHD code in order to try and break it down
> further to smaller modules, I encountered quite a few utility classes that
> duplicate (exactly or closely) code that already exists in other very
> popular "3rd party"
Le 16/07/2018 à 01:47, Reijhanniel Jearl Campos a écrit :
> Hi!
>
> I was recently working on a test that involves setting up an embedded XMPP
> server with Vysper, and Smack[1]. I encountered an issue[2] and posted on
> the Smack forum, and a developer pointed out that it might be a server
>
Le 06/07/2018 à 23:15, Jonathan Valliere a écrit :
> There are no 2.1 releases are there?
No, there are none. There is a branch I created, but no release so far.
Maybe 3.0 should be reserved for some
> incompatible refactor.
3.0 does exist, and we have releases for it, but it's currently
Le 06/07/2018 à 16:29, Jonathan Valliere a écrit :
> Any objections to setting up a 2.X branch which serves as the master then
> create the explicit numerical branches when releases are done? The 2.0
> used to be the master but now there is 2.1. Just looking to make it easier
> to understand.
Le 06/03/2018 à 18:20, Jonathan Valliere a écrit :
> So many warnings…
Yes...
There are a few puzzling ones, like the synchronized( buf ) where buf is
a parameter...
I think we should focus on blockers and critical level issues atm.
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Le 11/03/2018 à 08:41, Jonathan Valliere a écrit :
> Isn’t this a committee vote? Unless I read it wrong all votes are limited
> to committee members. Shouldn’t this be posted on the pmc mailing list?
We do vote release in the open. Every one - including users - can vote.
Only PMC members
Hi,
Here is the list of fixed issues :
Bugs :
--
[DIRMINA-844] - Http Proxy Authentication failed to complete (see
description for exact point of failure)
[DIRMINA-1002] - Mina IoHandlerEvents missing inputClosed enum item.
[DIRMINA-1051] - The MD5withRSA cipher is not anymore
Hi guys,
I just ran Sonarqube analysis on the current 2.0.17 branch, and there
are a few things we might want to fix.
Please have a look at
https://sonarcloud.io/project/issues?id=org.apache.mina%3Amina-parent%3A2=false
Thanks !
--
Emmanuel Lecharny
Symas.com
directory.apache.org
/2018 à 07:23, Emmanuel Lecharny a écrit :
> Hi guys,
>
> please don't forget to spend 5 minutes to review and vote this release !
>
> Many thanks !
>
> On Tue, Mar 6, 2018 at 3:09 PM, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
>
>> Hi,
>>
>>
ing to choke down the whole chain with
> special exceptions via flags in setAttributes. Make a lot of the design
> easier. IMHO, I think the biggest problem is the design of SSL filter and
> the limitations of the Filter API.
>
> On Thu, Apr 5, 2018 at 9:22 AM, Emmanuel Lécharny &l
Le 09/04/2018 à 17:17, Jonathan Valliere a écrit :
> I’d be interested in the diff. Why not propagate the sent down the chain
> instead of just to the handler?
I do propagate the event down teh chain. Ultimately, the IoHandler is
responsible for handling it.
I have attached the diff, nit
Hi guys,
as a follow up of a discussion we have had with Jonathan, I would like
to suggest we add the 'secured()' event in the IoHandler. Th idea is to
make it simpler for MINA users to be informed when teh TLS handshake has
been completed.
Currently, one need to add the USE_NOTIFICATION
Le 05/04/2018 à 14:18, Jonathan Valliere a écrit :
> I am concerned that it is bad precedent to add handler methods based on
> specific filters. The purpose of the filter system is that each filter has
> no direct knowledge of what is before or after it. Maybe there could be a
> generic
Le 05/04/2018 à 15:42, Jonathan Valliere a écrit :
> Yes, its different in that it may act like a buffer, in some phases, but
> doesn’t necessarily break the pattern of filter use. What your FilterChain
> needs is fire(index) options so the SSL can fire writes relative to itself,
> in response
f just to the handler? I have a generic event system that I use
> to notify users fo server events, like pending shutdown or app reloads.
>
> On Sun, Apr 8, 2018 at 11:56 AM, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
>
>> Ok, I have some kind of 'elegan
Sent to the dev list, where it belongs...
Message transféré
Subject: Re: Adding a secured() event in the IoHandler
To: Emmanuel Lécharny <elecha...@gmail.com>
If nextFilter.fire is called within messageReceived then it will send the
event to SSL Filter + 1; if nextFilte
Hi guys,
I'd like to ask your opinion about what we should do with the FtpServer
project.
There is little activity around it, and in the last 3 years, I was the
only one committig patches and code to the source base.
OTOH, I know this project is being used, as we have bug reports
periodically.
Hi guys,
I'd like to ask your opinion about what we should do with the FtpServer
project.
There is little activity around it, and in the last 3 years, I was the
only one committig patches and code to the source base.
OTOH, I know this project is being used, as we have bug reports
periodically.
Hi guys,
I'd like to ask your opinion about what we should do with the FtpServer
project.
There is little activity around it, and in the last 3 years, I was the
only one committig patches and code to the source base.
OTOH, I know this project is being used, as we have bug reports
periodically.
Hi guys,
I'll be MIA for the coming week, starting tomorrow morning. I will left
my computer at home during these vacations, so don't expect any code to
be committed in the following days.
I'll have my phone though, so I will check the mail from time to time,
don't worry :-)
--
Emmanuel
Le 19/04/2018 à 18:29, Jonathan Valliere a écrit :
> I’m guessing that the expected behavior is to disconnect from idle
> sessions?
I think so.
--
Emmanuel Lecharny
Symas.com
directory.apache.org
pEpkey.asc
Description: application/pgp-keys
Hi guys,
I have registred MINA on the SonarQube server we have at Apache. The
result can be seen here :
https://builds.apache.org/analysis/component_measures/?id=MINA
It gets generated every time a build is launched, ie, when a commit is
pushed.
--
Emmanuel Lecharny
Symas.com
Hi Lyor,
Le 18/03/2018 à 19:26, Lyor Goldstein a écrit :
> Looks interesting is there a guide as to how to register a project (I was
> thinking about SSHD...)
I have created the config for SSHD.
The result can be found here:
https://builds.apache.org/analysis/overview?id=MINA_SSHD
Now, the
>> interface contract
>> [DIRMINA-1076] - Leaking NioProcessors/NioSocketConnectors hanging
>> in call to dispose
>> [DIRMINA-1077] - Threads hanging in dispose() on SSLHandshakeException
>>
>> Improvement :
>> -
>>
>> [DI
Le 19/03/2018 à 18:20, Lyor Goldstein a écrit :
> Thanks a lot Emmanuel...
>
> As far as the build failure it is strange indeed as it passes on both my
> Windows and Linux machines. However, since it states:
>
> [INFO] Rat check: Summary over all files. Unapproved: 2
>
> it means that the
xception
>>
>> Improvement :
>> -
>>
>> [DIRMINA-1061] - When AbstractPollingIoProcessor read nothing, free
>> the temporary buffer should be better
>>
>> Task :
>> --
>>
>> [DIRMINA-1058] - Add the missing Javadoc
>>
>> We recommend all users to upgrade to this release. We consider this a
>> stable and production ready release.
>>
>>
>> The Apache MINA PMC
>>
>>
>> Thanks !
>>
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Hi,
Le 20/03/2018 à 21:47, Markus Rathgeb a écrit :
> Hi,
>
> has this been the wrong mailing list?
Nope.
> I know there exist also "users" and "ftpserver-users", but isn't it more or
> less a developer question and so should be sent to the "dev" list?
That's correct.
The thing is that we
Sorry, this was supposed to be sent on priv...@mina.apache.org...
Le 20/03/2018 à 19:12, Lyor Goldstein a écrit :
> +1
>
> I fully agree that " Guillaume is a very nice and talended
> person " and thank him for volunteering...
>
>>> Vote Guillaume Nodet as the new MINA chairman :
>
>>> [ ] +1
Hi,
I'm trying to build MINA 2.0 with the latest changes made by Jonathan,
and I get some random error in a test :
[ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
11.378 s <<< FAILURE! - in org.apache.mina.example.echoserver.ConnectorTest
[ERROR]
Le 03/03/2018 à 21:15, Jonathan Valliere a écrit :
> Emmanuel,
>
> IMHO ConnectorTest, from a quick glance, suffers from some pretty bad
> concurrency problems in how it waits on the handler and manipulates the
> buffer independent of whatever the IoProcessor is doing. I would expect it
> to
Le 03/03/2018 à 22:54, Christoph John a écrit :
> BTW, is there a reason why **/Abstract* and **/*RegressionTest* are
> excluded fromthe surefire plugin? This leads to some tests not executed,
> in my case specifically the tests for AbstractIoService.
Those excludes have been present since
Le 26/02/2018 à 17:06, Jonathan Valliere a écrit :
> Just a thought…
>
> At work, we always have a release target similar to 2.0-NEXT which always
> represents the next release. When a new release is completed, the target
> is renamed to the correct version number and a new 2.0-NEXT release is
Hi Guys,
thanks to Jonathan and Christopher work, some big issues have been fixed
in the 2.0 branch. I will start to cut a release today.
Keep tuned !
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Le 22/06/2018 à 14:01, Jonathan Valliere a écrit :
> At what point is the SSL going to be redesigned and anyone using it will be
> forced to update their code?
Sadly, we have thousands of peope using MINA as it is.
Mina 3.0 was an effort we started a few years ago to redesign this piece
of
Le 29/06/2018 à 13:10, Guillaume Nodet a écrit :
> Sorry for the delay.
> I gave it another try and unfortunately, the problem persists with my local
> build of 2.20-SNAPSHOT.
Ah, crap :/
> I'll try to find a fix next week.
Okiedo. What is surprizing is that I fixed the change you pointed, so
Le 27/09/2018 à 15:07, Lyor Goldstein a écrit :
> Hi Emmanuel,
>
>>> I just used the link Guillaume provided
> https://repository.apache.org/content/repositories/orgapachemina-1038/
>
> The link contains only binaries -
Nope, it also contains a source package :
Le 30/09/2018 à 20:37, Guillaume Nodet a écrit :
> #2 is not an option imho. Given the amount of work that would be needed to
> manually re-package and re-sign the distributions artifacts, i'd go for #1
> if this is considered a blocker.
As soon as we know why it fails when we try to build
Thanks, Jonathan,
Le 11/10/2018 à 18:07, Jonathan Valliere a écrit :
> I was having a conversation with a colleague last week about the cost of
> automatic casting due to the use of generics in java; so, I decided to
> write a benchmark. Since everyone wants their networking code to run as
>
Le 11/10/2018 à 19:03, Jonathan Valliere a écrit :
> One explaination I came up was that Java is performing a full upcast when
> encountering the generic-based interface. Unchecked and checked genetics
> perform identically.
Here is the bytecode for the strictMethod() :
0: aload_0
1:
Hi Lyor,
a few hints, onsidering I haven't reviewed the code...
Le 19/10/2018 à 07:00, Lyor Goldstein a écrit :
> Here is the issue in a nutshell - a client might open an SSH tunnel, send
> some data and close (normally) its side of the tunnel before the channel to
> the other side has been
Sounds good to me.
I think we should reboot the Vysper and FtpServer move to attic
discussion...
Le 09/10/2018 à 09:14, Guillaume Nodet a écrit :
> Below is the draft board report we need to submit for the next board
> meeting in a week.
> If you have anything to add / modify, let me know, else
Le 09/10/2018 à 14:49, Jonathan Valliere a écrit :
> I was willing to be the default maintainer for FtpServer.
That works :-)
Vysper seems a bit of a lost case, IMHO..
--
Emmanuel Lecharny
Symas.com
directory.apache.org
pEpkey.asc
Description: application/pgp-keys
Le 01/10/2018 à 09:10, Lyor Goldstein a écrit :
>>> Lyor, would you mind writing the release annoucement ? I'll publish the
>>> artifacts
> this morning, so we can send it later today.
>
> Sure - I'll send it to your private mail for proof-reading and any
> last-minute modifications you see
Le 30/09/2018 à 16:21, Lyor Goldstein a écrit :
>>> Also Github is own by a private company, we should not depend on them, they
> can easily shutdown their service, or stopping offering it for
> free.
>
> Very good point - however, why shouldn't Apache run its own GIT repository
> (which it
Le 03/10/2018 à 16:25, Mondain a écrit :
> I was looking into an issue reported in our use of UDP sessions in Mina
> 2.0.19. The IoSession.getScheduledWriteMessages() seemed to give very odd
> and varying results when more than one session existed. It seems that the
> scheduledWriteMessages
Sorry for the delay, I will take some time tonite or tomorrow to vote
this release !
Le 17/09/2018 à 10:35, Guillaume Nodet a écrit :
> I've staged a candidate release for Mina SSHD 2.1.0 at
> https://repository.apache.org/content/repositories/orgapachemina-1038/
>
> This release contains the
Compiled the package, compiled from source, check the N files.
Weird enough, everything works fine with source grabbed from the git
repo, but the package consistently fails with those errors :
...
[ERROR] Tests run: 6, Failures: 2, Errors: 4, Skipped: 0, Time elapsed:
0.476 s <<< FAILURE! - in
On 18/01/2019 23:22, Jonathan Valliere wrote:
I suggest creating the 2.X branch and continue that as the master for all 2
releases. Tag everything else.
we have a 2.0 branch that is the working branch for 2.0 x releases, and
a 2.1.0 branch for the next iteration (that plus a trunk that is
Hi !
sure, feel free to do so ! We haven't tested it with Java > 8, so that
would clearly help.
Thanks !
On 02/12/2018 18:43, Sina Kashipazha wrote:
Dear Community members
I'm graduated CS student with computer network and operating system experience.
I want to help open source
before calling messageSent
- fix the tests that may fail because of this change
Note that it may impact MINA users who expect the message to be reset,
when message is an IoBuffer, and when the IoHandler implements
messageSent().
Thoughts ?
On Wed, Mar 20, 2019 at 11:05 AM Emmanuel Lécharny
All tests are now passing green with my last commit in the write request
branch.
Feel free to have a look at it.
On 25/03/2019 19:12, Emmanuel Lécharny wrote:
Ok, I know what's the cause of this failure.
What happens when we process the handshake is that the SslFilter
exchange some
On 25/03/2019 02:10, Jonathan Valliere wrote:
I’m going to look at this starting Tuesday. Emmanuel do you mind creating
a branch for this Jira issue so I can track what you’re working on?
Sure
On 25/03/2019 02:10, Jonathan Valliere wrote:
I’m going to look at this starting Tuesday. Emmanuel do you mind creating
a branch for this Jira issue so I can track what you’re working on?
The branch name is 'mina-write-request'. It's from MINA 2.1.
on?
On Sun, Mar 24, 2019 at 3:54 AM Emmanuel Lécharny
wrote:
Things are complicated :/
Ok, after two days of investigation, my take is that the original sin
was to use a IoBuffer to propagate a message across the filters.
IoBuffers can be consumed (ie, when you read them, their position
change
And here are the SSL debug traces :
...
0update handshake state: change_cipher_spec
0upcoming handshake states: server finished[20]
10: 01 00 D5 D2 05 1B C0 51 13 A6 40 EC 80 9F 2A 4C ...Q..@...*L
0020: EC D3 BF 1A 5B 4C 57 87 E3 D9 0B 35 2F 32 20 64 [LW5/2 d
0030: DE 93 74 81
.
I'll keep the list informed.
On 22/03/2019 13:35, Emmanuel Lécharny wrote:
Ok, I have a version that works better with the CompressionFilter.
Here is what I have changed :
- the session.write( ) method will inject the original
message into the WriteRequest
- any filterWrite filter
On 03/04/2019 14:37, Jonathan Valliere wrote:
"Both Mina SSHD and Mina Core subprojects have only two active committers"
Two active committers each or total?
Each.
On Wed, Apr 3, 2019 at 8:01 AM Guillaume Nodet wrote:
Please find below the report I intend to send to board at the
in the messageSent
SSLMFilter handler.
Working on that atm.
On 25/03/2019 07:48, Emmanuel Lécharny wrote:
And here are the SSL debug traces :
...
0update handshake state: change_cipher_spec
0upcoming handshake states: server finished[20]
10: 01 00 D5 D2 05 1B C0 51 13 A6 40 EC 80 9F 2A 4C ...Q
with 2
different versions :/ ).
Thanks !
On 21/02/2019 12:06, Emmanuel Lécharny wrote:
Hi !
I'm calling for a vote of Apache MINA 2.0.20 release.
It's a bug fix release. Here are the list of bugs that have been fixed :
DIRMINA-1092: Removed a spurious printstacktrace
DIRMINA-1098
Hi guys,
after having cut MINA 2.0.20, I tried to cut MINA 2.1.0 (which is just
MINA 2.0.20 with a slight API change). Sadly, I can't have the package
moved to Nexus.
I'm trying to figure out what's wrong, but there is nothing obvious. It
should work, the pom.xml hasn't change that much...
On 20/02/2019 14:14, Jonathan Valliere wrote:
Is there some automated release process or is it entirely manual?
I use a link checker, then I fix it manually. There are 1423 links, out
of which 161 were broken when I started cleaning them up. I'm down to
87, but many are false positive
Hi guys,
yesterday evening, I cut a MINA 2.0.20 release (vote to come). Then I
tested it with Ftpserver (all is good), and SSHD. I get some test failures :
[INFO]
[ERROR] Errors:
[ERROR] PortForwardingTest.testLocalForwarding:467->createSession:802 »
JSch java.net
[ERROR]
Hi guys,
for some unknown reasons, I can't find any trace of the SSHD 1.3.0 and
1.4.0 packages and signatures in https://archive.apache.org/dist/mina/sshd/
The 'old versions' download pages yet list those versions as available
(http://mina.apache.org/downloads-sshd.html)
ATM, I have
On 05/03/2019 01:25, Jonathan Valliere wrote:
I just checked git, looks like 2.1.0 was updated with changes through
2.0.20. Is this correct?
correct
Is the plan to maintain 2.0.X separate from
2.1.X and just port the changes?
Yep.
Hi !
I'm calling for a vote of Apache MINA 2.1.0 release.
It's a branched version diverging from Apache MINA 2.0.17, with some
difference in the API. Otherwise, every changes made in 2.0.18/19/20
have been ported to this version.
The API change is that the IoFilter interface now propagates
On 05/03/2019 14:19, Jonathan Valliere wrote:
What in 2.1.X is not compatible with products build around 2.0.X?
The difference lies in the API change in IoFilter interface (which
should not impact your code), and in the IoHandler interface, where the
addition of the event() method has been
On 05/03/2019 15:54, Jonathan Valliere wrote:
Why not backport the IoFilter changes and go all out with a whole new SSL
design for 2.1.X?
We can't backport the changes made in 2.1 to 2.0, it breaks things in
other projects, this is why we released 2.0.19. The idea is to move
forward with a
On 05/03/2019 17:26, Jonathan Valliere wrote:
I thought the IoFilter changes didn’t break anything.
Me too:/ Sadly, I can tell you that Apache LDAP API had to rollback to
2.0.18 when 2.0.19 was released, because of some breakages. This is
because we rollbacked the changes in 2.0.19, and
Hi guys,
sorry for those following the commits@mina.a.o, I'm been quite active
those last days.
I have resurrected all the older MINA release with their associated
javadoc, and updated the web site with them
(http://mina.apache.org/mina-project/downloads_old.html).
I also wrote a blurb
Hi !
Now that we are done with the releases, I'm looking at two areas that
could be improved.
We have two scenario to co,nsider :
1) a SslFilter is used without any Executor filter in the chain
In this case, as each message is fully processed by a single thread
(IoProcressor), there is
Hi guys !
I'm closing this vote, with 3 binding +1:
Jeff, Jonathan and me.
I will push the packages and make the announcement?.
Thanks !
On 05/03/2019 01:04, Emmanuel Lécharny wrote:
Hi !
I'm calling for a vote of Apache MINA 2.1.0 release.
It's a branched version diverging from Apache
t try to reset a message when it's not a IoBuffer
Emmanuel Lécharny
Tue, 16 Feb 2016 14:38:14 + (15:38 +0100)
Greg
On Tue, 19 Mar 2019 at 17:17, Jonathan Valliere
wrote:
I’m trying to look it up in gitbox and it doesn’t show the ids. What was
the date / first few words of commit message?
On
}
mark is now -1, so setting a position on it will produce the error you get.
Sounds like a bug to me...
On 19/03/2019 23:04, Emmanuel Lécharny wrote:
Hi Greg, Jonathan,
it was 3 years ago, and I don't remember what was the root cause of
this change. However, reading the diff, what
I can reproduce the issue with a much simpler application (using the
'chat' example).
I will try to get a fix asap.
On 19/03/2019 23:33, Emmanuel Lécharny wrote:
Ok, looking at the CompressionFilter, here is what I see:
@Override
protected Object doFilterWrite(NextFilter nextFilter
On 20/03/2019 15:30, Jonathan Valliere wrote:
The offending code is in AbstractPollingIoProcessor. Are you agreeing that
AbstractPollingIoProcessor has no place modifying the buffer positions?
Removing buf.reset() would probably fix the problem.
The reason we reset the buffer is that we
*
modify it. It could replace it, but not reset/flip/whatever.
I suspect there is some attempt to avoid creating a new buffer at some
point, for performance reasons. We shoudl review all the filters to
check that they are not doing such a thing...
On Wed, Mar 20, 2019 at 10:01 AM Emmanuel Lécharny
Hi guys,
following the MINA 2.0.20 and 2.1.0 releases, I'm updating the sites so
that one can see both packages, and both javadocs.
I'm also going a bit further: we can't get older javadocs, the only
version we can see is the last one. I'm fixing this, by injecting older
javadocs in a
in all, the MINA code is much simpler and should be faster too, as
we spare spurious calls to messageSent and filterWrite with an Empty
message.
More to come soon.
On 22/03/2019 04:58, Emmanuel Lécharny wrote:
Hmmpp
I have traced the calls when a session.write( ) is done.
It's all
Hmmpp
I have traced the calls when a session.write( ) is done.
It's all a kind of a hack.
In order to be able to send the messageSent() event, the protocolFilter
will call the nextFilter.filterWrite() method twice :
public void filterWrite(NextFilter nextFilter, IoSession
On 08/02/2019 15:22, Jonathan Valliere wrote:
You mean that you want to pass messages from one thread to another?
Or from one session to another one ?
On Fri, Feb 8, 2019 at 9:02 AM Kevin Kal wrote:
Dear Sir/Madam,
I've been trying to find out how to send loopback messages on a
On 08/02/2019 15:22, Jonathan Valliere wrote:
You mean that you want to pass messages from one thread to another?
Or from one session to another one ?
On Fri, Feb 8, 2019 at 9:02 AM Kevin Kal wrote:
Dear Sir/Madam,
I've been trying to find out how to send loopback messages on a
I still don't get it.
Your IoHandler will be called everytime an event occurs (message
received, message written, session created/closed/idling, exception).
You have the opportunity to execute some action at this moment.
Beside that, I don't see a use case. I'm probably missing something...
that It would be a deferred action that could only happen after
the IO processor is done? Maybe you could explain the reason why you want
to do this?
On Thu, Feb 14, 2019 at 10:40 AM Emmanuel Lécharny
elecharny@
wrote:
I still don't get it.
Your IoHandler will be called everytime an event occurs (message
On 14/02/2019 17:28, kevintjuh93 wrote:
Yes, I am aware that's what happens. And in these cases I can make it execute
at the end of a messageReceived. But my case is that I do something from a
non io-processor thread, but what it does needs to be synced with the
io-processor.
Ok, now that
On 14/02/2019 17:42, Jonathan Valliere wrote:
On a side note, this is the developers mailing list. We're filling the
inboxes of other developers that probably don't want to be a part of this
conversation. We should move it to the us...@mina.apache.org mailing list.
True.
Although I
Thanks for the headsup !
All the site has been updated.
On 06/02/2019 00:19, Jonathan Valliere wrote:
We need to update all the website pages to point to gitbox. All of the
projects continue to list git-wip-us.apache.org
On Sat, Jan 12, 2019 at 6:10 AM Lyor Goldstein
wrote:
The
Hi guys,
I finally found a bit of time to prepare the MINA 2.0.20 release. I'm
currently cleaning up the site, (cf DIRMINA-1089), and there are *many*
broken links (161 this morning). Most of them are related to links to
the dist directory, which does not contain any of the old versions
Hi !
I think it's time to cut a new release for MINA 2.1.X branch. We have
some important fix for a problem that hits this branch (a 100% CPU
utilization, due to a mistake made while redesigning the way messages
are propagated back to messageSent()), plus a few minor other fixes.
If
On 28/05/2019 04:32, Jonathan Valliere wrote:
I would like to see DIRMINA-1110 reverted. IMHO, I do not think it fixes
any known problems and potentially introduces new deadlock opportunities.
Np. I'll do that.
Hi !
I'm calling for a vote of Apache MINA 2.1.3 release.
This fixes a few issues that were found since the last release, mainly a
100% CPU peak caused by some changes in the way we process the
messageSent() event. The 4 JIRA tickets that are fixed by this release
are available on :
Hi !
I'm closing this vote with 3 binding +1 :
Jeff, Jonathan and me.
I'll push the packages today and update the site.
Many thanks !
On 29/05/2019 15:19, Emmanuel Lécharny wrote:
Hi !
I'm calling for a vote of Apache MINA 2.1.3 release.
This fixes a few issues that were found since
Hi Janathan,
On 10/05/2019 16:30, Jonathan Valliere wrote:
Emmanuel,
I know you're busy but I would like to figure out why mvn in FTPSERVER
is complaining and not building due to errors. I'm not a maven expert.
DescriptionResourcePathLocationType
Plugin execution not covered by lifecycle
On 20/05/2019 18:17, Jonathan Valliere wrote:
Oh, two mirrors. How do we remove the bad one?
I guess we should ask infra...
On 20/05/2019 18:02, Jonathan Valliere wrote:
The GitHub Mirror of FTPSERVER is not automatically updating from Gitbox.
How do we fix this?
I think it does, but there are 2 mirrors, one being ftpserver and has
stalled, and the other one being mina-ftpserver and seems to be
up-to-date with
On 10/05/2019 17:52, Jonathan Valliere wrote:
Maven commands work but Maven-Eclipse integration seems to have a problem
with the plugins.
Ok, same error for me.
Just select QuickFix and 'Mark goal check as ignored' for each project
in eclipse. That will build, and you won't see any error.
Hi guys,
I would need one more vote for this release to be out ! I'm leaving for
a week vacation tomorrow morning, so it's a bit tight schedule :-)
Thanks !
On 17/04/2019 14:48, Emmanuel Lécharny wrote:
Hi !
I'm calling for a vote of Apache MINA 2.1.2 release.
It's a bug fix release
701 - 800 of 993 matches
Mail list logo
