Re: MIA for a few days

[Mondain]

Wish you the best on the computer issue. Once you get a new drive, it might
better to try accessing the original drive via external connectors. There
are also paid recovery options as well but they are quite expensive :(

Good luck,
Paul

On Tue, Nov 6, 2018, 14:42 Emmanuel Lecharny  wrote:

> Hi!
>
> My computer just died this morning, it does not see the disk anymore :-/ it
> will be a matter of days to either get it repaired or worse, to buy a new
> one. I hope to be able to get back the data, as I have some substantial
> pending modifications to push - and yeah, next time I’ll push them to a git
> branch...-
>
> In the mean time, I’m pretty incapable to Participate, beside mails.
>
> I hope it win’t last too long.
>
> Thanks, Emmanuel
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

Mina and UDP Multicast

[Mondain]

I have a need for UDP multicast and I was wondering what the status of
https://issues.apache.org/jira/browse/DIRMINA-438 is? Especially since it
mentions Mina 3, but the last update to the ticket was a few years ago. If
there's enough information or examples in the ticket, I may be able to
contribute a working solution, especially if there isn't one already in
2.0.19 and Trustin's discovery as clear as it seems.

Regards,
Paul

Getting scheduled write message count is inaccurate for UDP sessions

[Mondain]

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 stat comes from the acceptor, which in our case is
"shared" so the value will be inaccurate per individual session; stat
updates in AbstractIoSession here:

/**
 * Increase the number of scheduled message to write
 */
public final void increaseScheduledWriteMessages() {
scheduledWriteMessages.incrementAndGet();

if (getService() instanceof AbstractIoService) {
((AbstractIoService)
getService()).getStatistics().increaseScheduledWriteMessages();
}
}

/**
 * Decrease the number of scheduled message written
 */
private void decreaseScheduledWriteMessages() {
scheduledWriteMessages.decrementAndGet();
if (getService() instanceof AbstractIoService) {
((AbstractIoService)
getService()).getStatistics().decreaseScheduledWriteMessages();
}
}

If all this is accurate and by-design, what would be the best way to
determine how many writes are scheduled for an individual session?

Best Regards,
Paul

UDP packet handling strategies

[Mondain]

I wonder if any of my fellow community members have thoughts or experience
with UDP in Mina as far as responding to load conditions; whether it be
flooded outgoing packet queues, high cpu load, or network throttling. We're
considering an IoFilter similar to the old Mina bandwidth throttle example,
but would like to hear from the community. Ideally we want to drop packets
if xyz condition is met.

Best Regards,
Paul

Re: leaking NioProcessors/NioSocketConnectors hanging in call to dispose

[Mondain]

Chris,
Take a look at the compareAndSet and getAndSet methods of AtomicBoolean;
they use "compare and swap" or CAS and you should never run into a
situation where a value is mishandled due to the nature of CAS using a
single CPU operation.


Paul

On Thu, Jul 27, 2017 at 8:13 AM Christoph John 
wrote:

>
>
> On 27/07/17 10:56, Emmanuel Lécharny wrote:
> > Le 27/07/2017 à 10:25, Christoph John a écrit :
> >> One question that comes to my mind after looking at our code: there is
> >> a Boolean attribute get/set on the IoSession in various places
> >> (SessionConnector.QFJ_RESET_IO_CONNECTOR). We get/set this from
> >> different locations and threads. But we neither synchronize on the
> >> IoSession nor the get/set of the attribute. So IMHO it could happen
> >> that the attribute is set to a different value than actually expected,
> >> triggering unexpected behaviour.
> >> I only searched briefly but could not find anything in the MINA code
> >> that makes getting/setting the attribute thread-safe.
> > Attributes within a session are not protected : it's up to you to make
> > sure they are not modified concurently. Now, for a boolean, using an
> > AtomicBoolean would certainly help.
> OK, but to make sure that every thread works with the same value of the
> attribute I need to
> synchronize the get/set, correct? Even if I put an AtomicBoolean there, it
> could happen that one
> thread does not "see" it immediately.
> But that only as a side note. I have tested it even with synchronization
> and the behaviour stays the
> same. So the error must be somewhere else in the code.
>
> I have now a test which tries to connect several FIX sessions with enabled
> SSL filter. The
> connection is established and then dropped because of an
> SSLHandshakeException. This is done for
> about a minute and leads to the mentioned problem with the connectors
> hanging in dispose.
> When I change the test to not use SSL I can see no "old" connectors
> hanging around. Is there
> something that I must specifically do when using the SSL filter? E.g. when
> there is an exception
> caught? First destroy all filters in the chain and then close the session?
>
> Thanks,
> Chris.
>
>
>
>
> --
> Christoph John
> Development & Support
> Direct: +49 241 557080-28 <+49%20241%2055708028>
> Mailto:christoph.j...@macd.com
>
>
>
> http://www.macd.com 
>
> 
>
>
> 
> MACD GmbH
> Oppenhoffallee 103
> D-52066 Aachen
> Tel: +49 241 557080-0 | Fax: +49 241 557080-10 <+49%20241%2055708010>
>  Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
>
> Geschäftsführer: George Macdonald
>
> 
>
>
> 
>
> take care of the environment - print only if necessary
>

Re: [VOTE] MINA 2.0.14 release

[Mondain]

Not that I count, but +1 from me :)

On Mon, Aug 29, 2016 at 9:25 AM Guillaume Nodet  wrote:

> +1
>
> 2016-08-25 16:16 GMT+02:00 Emmanuel Lécharny :
>
> > Hi,
> >
> > Here is a new release, MINA 2.0.14. It fixes many issues, some of them
> > being a real burden for SSHD DIRMINA-1021). Some patches were also
> applied
> > (thanks to Maria Petridan).
> >
> > Here are the fixed issues :
> >
> > Bugs :
> > --
> >
> > [DIRMINA-760 ]
> >  Client fails to detect disconnection
> > [DIRMINA-976 ]
> >  ScheduledWriteBytes Increases after Exception on Writing
> > [DIRMINA-1021 ]
> > MINA-CORE does not remove sessions if exceptions occur while closing
> > [DIRMINA-1025 ] A
> > call to session.closed(true) may still flush messages.
> > [DIRMINA-1028 ] The
> > supported ciphers configuration might not be used
> > [DIRMINA-1029 ] The
> > sent buffer is reset to its original position when using the SSL Filter
> > after a session.write()
> > [DIRMINA-1037 ]
> Throw
> > exception in NioProcessor.write if the session is closing
> > [DIRMINA-1039 ]
> > Response messages queue up on the server side waiting to be written to
> > socket, while the server continues to read more request messages, causing
> > out of heap memory
> > [DIRMINA-1042 ]
> Epoll
> > spinning causes memory leak
> >
> >
> > Task :
> > --
> >
> > DIRMINA-986 ] Update
> > the web site to reflect the switch to git for the release process
> >
> >
> >
> > A temporary tag has been created (it can be removed if the vote is not
> > approved):
> >
> > Updated Tags:  refs/tags/2.0.14 [created] 34bed70ca
> >
> > Project: http://git-wip-us.apache.org/repos/asf/mina/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/mina/commit/9ed90e0d
> > Tree: http://git-wip-us.apache.org/repos/asf/mina/tree/9ed90e0d
> > Diff: http://git-wip-us.apache.org/repos/asf/mina/diff/9ed90e0d
> >
> > - Nexus repository: https://repository.apache.org/content/repositories/
> > orgapachemina-1023
> >
> > - Binaries and sources: https://dist.apache.org/repos/
> > dist/dev/mina/mina/2.0.14/
> >
> > Let us vote :
> > [ ] +1 | Release MINA 2.0.14
> > [ ] ± | Abstain
> > [ ] -1 | Do **NOT**  release MINA 2.0.14
> >
> > Thanks !
> >
>
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

Mina 2.0.14-SNAPSHOT

[Mondain]

Emmanuel,
Would you mind deploying a snapshot for version 2.0.14 when you have a
moment?

Thanks in advance,
Paul

Re: Mina build JDK

[Mondain]

Since I can't seem to comment,
https://issues.apache.org/jira/browse/DIRMINA-1034 is a direct result of
building with JDK 8 and using on JDK 7. Its not due to or resolved by your
runtime classpath; the problem is caused by the compiled bytecode. This
issue / bug has been posted all over the internet since shortly after JDK 8
came out.

Paul

On Wed, Mar 9, 2016 at 2:24 PM Emmanuel Lécharny 
wrote:

> Le 09/03/16 20:20, Emmanuel Lécharny a écrit :
> > Le 09/03/16 19:53, Mondain a écrit :
> >> The "catch" here is that you can't build with JDK8 for JDK7; if you do
> >> this, users on JDK7 will see the concurrent keyset error.
> > Damn... The problem is that Java 7 is not available anymore for download
> > since April 2015...
> >
> Ah, hopefully, I have a Java 7 installed :
>
> localhost:mina-2.0 elecharny$ mvn -version
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T17:41:47+01:00)
> Maven home: /opt/apache-maven-3.3.9
> Java version: 1.7.0_55, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: US-ASCII
> OS name: "mac os x", version: "10.9.5", arch: "x86_64", family: "mac"
>
>
>

Re: Mina build JDK

[Mondain]

The "catch" here is that you can't build with JDK8 for JDK7; if you do
this, users on JDK7 will see the concurrent keyset error.

On Wed, Mar 9, 2016 at 11:45 AM, Emmanuel Lécharny 
wrote:

> Le 09/03/16 17:32, Mondain a écrit :
> > Will the jdk7 build artifacts have a different name?
>
> No, the idea would be to build with JDK7 as a target. I don't know why I
> haven't done that, it's clearly a mistake.
>
>
>


-- 
http://gregoire.org/
https://github.com/Red5 <http://code.google.com/p/red5/>

Re: Mina build JDK

[Mondain]

Will the jdk7 build artifacts have a different name? or will the public
ones stay on jdk8? Asking because I had to create my own jdk7 builds for a
private project; the ones pulled from central were built with jdk8.

On Wed, Mar 9, 2016 at 12:07 AM Emmanuel Lécharny 
wrote:

> Le 08/03/16 23:08, Mondain a écrit :
> > I noticed that the last couple builds were done with JDK8; is this the
> > trend from now on for Mina?
> >
> > Paul
> >
> No. We will continue support Java 7.
>

Mina build JDK

[Mondain]

I noticed that the last couple builds were done with JDK8; is this the
trend from now on for Mina?

Paul

Re: CumulativeProtocolDecoder and UDP

[Mondain]

Ashish, just be aware that with UDP, some of your data may never arrive;
that's the nature of the protocol.

Paul

On Tue, Mar 1, 2016 at 1:48 PM Ashish  wrote:

> TCP handles fragmentation at its level, but for UDP you have to do it
> at application layer meaning UDP data has to carry message sequences
> and then you merge them at receiving end. Here you packets can come in
> different order do you got to keep them somewhere before complete
> message is constructed.
>
>
>
> On Tue, Mar 1, 2016 at 7:58 AM, tunca  wrote:
> > Our customer has strange requirement about merging multiple udp/TCP
> packages
> > to create a single  message.
> > There is a well defined protocol that defines message boundaries.
> > The decoder is working good with TCP packages.  It can create a single
> > message from multiple TCP packages.
> > However when a message is fragmented into multiple packages the do
> doDecode
> > method always gives the same ioBuffer.
> > I'll try 2.0.13 next day.
> > Thanks
> >
> >
> >
> >
> > --
> > View this message in context:
> http://apache-mina.10907.n7.nabble.com/CumulativeProtocolDecoder-and-UDP-tp18927p50274.html
> > Sent from the Apache MINA Developer Forum mailing list archive at
> Nabble.com.
>
>
>
> --
> thanks
> ashish
>
> Blog: http://www.ashishpaliwal.com/blog
> My Photo Galleries: http://www.pbase.com/ashishpaliwal
>

Building a snapshot with bundles for private repo

[Mondain]

I'm having a lot of trouble trying to get a set of files that can be pushed
to my own private repository; I've been through the docs and I've tried
messing with felix, but alas I'm coming up short. Here's my latest command
which produces no .bundle files.

mvn -Pserial
-DaltDeploymentRepository=jmrs::default::file:///home/mondain/workspace/temp
-Dmaven.test.skip=true clean deploy

Best Regards,
Paul

Re: [VOTE] MINA 2.0.11 release

[Mondain]

+1


On Fri, Jan 22, 2016 at 1:05 PM Jeff Genender  wrote:

> +1
>
> Jeff
>
> > On Jan 22, 2016, at 10:33 AM, Emmanuel Lécharny 
> wrote:
> >
> > Hi,
> >
> > Here is a vote for a new bug fix release of Mina : 2.0.11.
> >
> > This mainly fixes a bug in the SslHandler, which might cause a loop in
> some corner cases.
> >
> > The Javadoc has also be improved so that all the missing annotations
> (@param, @return)
> > are now present.
> >
> > Here is the list of fixed issues :
> >
> > Bugs :
> > --
> >
> > [DIRMINA-1023 ]
> Infinite loop in SslHandler when the AppBuffer is too small
> > 
> > [DIRMINA-1022 ]
> The IoBuffer.fill(byte, int) method does not work when byte > 0x7F
> >
> >
> > A temporary tag has been created (it can be removed if the vote is not
> > approved):
> >
> > - GIT tag : "2.0.11" SHA-1 : "0b348ccd3aa8ed2776b4d0de1f477c90b4ba51f9"
> >
> > Project: http://git-wip-us.apache.org/repos/asf/mina/repo
> > Commit:http://git-wip-us.apache.org/repos/asf/mina/commit/0b348ccd
> > Tree:http://git-wip-us.apache.org/repos/asf/mina/tree/0b348ccd
> >
> >
> > - Nexus repository:
> https://repository.apache.org/content/repositories/orgapachemina-1017
> >
> > - Binaries:http://people.apache.org/~elecharny
> >
> > Let us vote :
> > [ ] +1 | Release MINA 2.0.11
> > [ ] ± | Abstain
> > [ ] -1 | Do **NOT**  release MINA 2.0.11
> >
> > Thanks !
> >
> > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
> >
>
>

Building Mina 2.0.10-SNAPSHOT

[Mondain]

I'm unable to build the latest snapshot for the 2.0 branch today, the build
"hangs" with this last line on the console:

Running org.apache.mina.example.echoserver.ConnectorTest

I've tried with and without "-Pserial"; ex. mvn clean install -Pserial
If anyone has any idea why this happens, please reply; in the interim, I'll
just kip the tests (which is not ideal).

Environment:
Ubuntu 14.04 x64
Java 1.8.0_66 (64-bit)
Maven 3.2.1

Regards,
Paul

Re: [VOTE] MINA 2.0.8

[Mondain]

+1 for sure!

On Wed, Sep 17, 2014 at 8:07 AM, Jeff MAURY  wrote:

> +1
>
> Ran the build, plus Apache Camel and Google Gerrit builds modified to use
> 2.0.8
>
> Jeff
>
> On Tue, Sep 16, 2014 at 1:01 PM, Ashish  wrote:
>
> > +1
> >
> > Ran the build, works fine, all test cases pass
> >
> > Got 404 for http://people.apache.org/~elecharny/mina-2.0.8, downloaded
> src
> > from http://people.apache.org/~elecharny/
> >
> > On Tue, Sep 16, 2014 at 4:48 AM, Emmanuel Lécharny 
> > wrote:
> >
> > > Hi,
> > > It's 2 years we haven't had a release of MINA 2.0, it's about time.
> > >
> > >
> > > We have tried to fix as much issues as we could in the last 2 weeks.
> As a
> > > result, we have closed around 90 JIRAs.
> > >
> > > There is one change that might break the build for those switching from
> > > MINA 2.0.7 to MINA 2.0.8 : the IoHandler interface now has a method
> > called
> > > inputClosed(), so either you have to implement this method if you are
> > > directly implementing the IoHandler interface, or better, you can
> extends
> > > IoHandlerAdapter, which implements a placeholder for this method.
> > >
> > > Changelog:
> > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20DIRMINA%20AND%20fixVersion%20%3D%202.0.8%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC
> > >
> > > A temporary tag has been created (it can be removed if the vote is not
> > > approved):
> > >
> > > - GIT tag : "2.0.8" SHA-1 : "50e417e8116ea1d0b6fe6b8c970e0594ef89f743"
> > >
> > > Project: http://git-wip-us.apache.org/repos/asf/mina/repo
> > > Commit:
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=mina.git;a=commit;h=50e417e8116ea1d0b6fe6b8c970e0594ef89f743
> > > Tree:
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=mina.git;a=tree;h=ef06b2f03cfe979f35af98aa2af194e877b8fd5c;hb=50e417e8116ea1d0b6fe6b8c970e0594ef89f743
> > >
> > >
> > > - Nexus repository:
> > > https://repository.apache.org/content/repositories/orgapachemina-1005
> > >
> > > -Binaries:
> > > http://people.apache.org/~elecharny/mina-2.0.8
> > >
> > > Let us vote :
> > > [ ] +1 | Release MINA 2.0.8
> > > [ ] ± | Abstain
> > > [ ] -1 | Do *NOT*  release MINA 2.0.8
> > >
> > > Thanks !
> > > --
> > > Emmanuel Lécharny
> > >
> > >
> >
> >
> > --
> > thanks
> > ashish
> >
> > Blog: http://www.ashishpaliwal.com/blog
> > My Photo Galleries: http://www.pbase.com/ashishpaliwal
> >
>
>
>
> --
> Jeff MAURY
>
>
> "Legacy code" often differs from its suggested alternative by actually
> working and scaling.
>  - Bjarne Stroustrup
>
> http://www.jeffmaury.com
> http://riadiscuss.jeffmaury.com
> http://www.twitter.com/jeffmaury
>



-- 
http://gregoire.org/
http://code.google.com/p/red5/

Status of DIRMINA-934 and Mina 3.0

[Mondain]

Is https://issues.apache.org/jira/browse/DIRMINA-934 dead or just
forgotten? I'm still using a patched version in Red5 and would love to see
it committed. Lastly, whats the current status of a 3.0 release? I'd like
to get started porting the our I/O code to work with it.

Regards,
Paul

-- 
http://gregoire.org/
http://code.google.com/p/red5/

Re: Maven repo build jdk version

[Mondain]

I'm emailing them back to make sure they didn't grab my jdk7 compiled
2.0.8-SNAPSHOT.



On Wed, Feb 27, 2013 at 8:14 AM, Mondain  wrote:

> Details:
>
> nested exception is java.lang.UnsupportedClassVersionError:
> org/apache/mina/core/buffer/IoBuffer : Unsupported major.minor version 51.0
>
> OS: Ubuntu 10.0.4
> Java version: 1.6.0_27
> OpenJDK Runtime Environment (IcedTea6 1.12.3) (6b27-1.12.3-0ubuntu1~10.04)
> OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)
>
>
>
> On Wed, Feb 27, 2013 at 8:12 AM, Mondain  wrote:
>
>> Get reports of UnsupportedClassVersionError for Mina classes on the Red5
>> list; seemed odd to me. They are using JDK 6 on their app.
>>
>> Paul
>>
>>
>> On Wed, Feb 27, 2013 at 8:06 AM, Emmanuel Lécharny 
>> wrote:
>>
>>> Le 2/27/13 4:23 PM, Mondain a écrit :
>>> > Just a quick question since I don't recall seeing anything on the list.
>>> > Have the builds for publish to the Maven repository been switched to
>>> JDK 7?
>>>
>>> Hmmm, I don't think so. Why ?
>>>
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>>
>>>
>>
>>
>> --
>> http://gregoire.org/
>> http://code.google.com/p/red5/
>>
>
>
>
> --
> http://gregoire.org/
> http://code.google.com/p/red5/
>



-- 
http://gregoire.org/
http://code.google.com/p/red5/

Re: Maven repo build jdk version

[Mondain]

Details:

nested exception is java.lang.UnsupportedClassVersionError:
org/apache/mina/core/buffer/IoBuffer : Unsupported major.minor version 51.0

OS: Ubuntu 10.0.4
Java version: 1.6.0_27
OpenJDK Runtime Environment (IcedTea6 1.12.3) (6b27-1.12.3-0ubuntu1~10.04)
OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)



On Wed, Feb 27, 2013 at 8:12 AM, Mondain  wrote:

> Get reports of UnsupportedClassVersionError for Mina classes on the Red5
> list; seemed odd to me. They are using JDK 6 on their app.
>
> Paul
>
>
> On Wed, Feb 27, 2013 at 8:06 AM, Emmanuel Lécharny wrote:
>
>> Le 2/27/13 4:23 PM, Mondain a écrit :
>> > Just a quick question since I don't recall seeing anything on the list.
>> > Have the builds for publish to the Maven repository been switched to
>> JDK 7?
>>
>> Hmmm, I don't think so. Why ?
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>>
>
>
> --
> http://gregoire.org/
> http://code.google.com/p/red5/
>



-- 
http://gregoire.org/
http://code.google.com/p/red5/

Re: Maven repo build jdk version

[Mondain]

Get reports of UnsupportedClassVersionError for Mina classes on the Red5
list; seemed odd to me. They are using JDK 6 on their app.

Paul


On Wed, Feb 27, 2013 at 8:06 AM, Emmanuel Lécharny wrote:

> Le 2/27/13 4:23 PM, Mondain a écrit :
> > Just a quick question since I don't recall seeing anything on the list.
> > Have the builds for publish to the Maven repository been switched to JDK
> 7?
>
> Hmmm, I don't think so. Why ?
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>


-- 
http://gregoire.org/
http://code.google.com/p/red5/

Re: Opinion on this Java IO bug

[Mondain]

I'll see if I can get some unit tests together to possibly locate anything
that may be leaking in Mina 2.0.8.


On Thu, Jan 31, 2013 at 8:57 AM, Emmanuel Lécharny wrote:

> Le 1/31/13 5:52 PM, Mondain a écrit :
> > I was talking to Jon Valliere this morning about GC with IOPS and I
> > wondered what the opinion of the Mina dev team is on this issue:
> >
> http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=ca40fa265e28a3ccb91527b258ff?bug_id=6924217
> > How well is this handled by 2.x or 3.x? I personally use 2.0.8 with the
> > -XX:+UseParNewGC JVM option and it seems to work ok; but I'm fairly sure
> > there are still some leaks.
> The bugs just says that there are a lot of GCs, not that there is a leak
> anywhere.
>
> Is that a real problem ?
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>


-- 
http://gregoire.org/
http://code.google.com/p/red5/

Re: So where would I find 2.0.8?

[Mondain]

I pulled from git and built; what I have now is 3.0-Snapshot, not the 2.0.8
that i was looking for.


On Sat, Jan 12, 2013 at 9:30 AM, Emmanuel Lécharny wrote:

> Le 1/12/13 11:14 AM, sebb a écrit :
> > On 12 January 2013 07:11, Emmanuel Lécharny  wrote:
> >> Le 1/12/13 7:05 AM, Mondain a écrit :
> >>> Do I need to pull it from Git or is it still available in SVN?
> >> Definitively from git.
> >>
> >> We can't update the site yet to inform people about this, because the
> >> site is stored in SVN and the SVN repo has been switched to read-only,
> >> but we don't have the site repo on git available yet :/
> > AIUI, the site will always have to be served from SVN.
> > AFAIK there are no plans to implement the equivalent of svnpubsub using
> Git.
> >
> > So if you are waiting for that to happen, the updated site will never
> happen.
> >
> > The PMC needs to decide what flavour of svnpubsub is to be used, and
> > ask Infra (via JIRA) to set it up.
> We already decided to go for CMS, and switched back in december. The pb
> is that the SVN repo is read only atm, so whatever modification we do
> can't be saved...
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>


-- 
http://gregoire.org/
http://code.google.com/p/red5/

Re: So where would I find 2.0.8?

[Mondain]

Thank you! Keep up the great work.


On Fri, Jan 11, 2013 at 11:11 PM, Emmanuel Lécharny wrote:

> Le 1/12/13 7:05 AM, Mondain a écrit :
> > Do I need to pull it from Git or is it still available in SVN?
> Definitively from git.
>
> We can't update the site yet to inform people about this, because the
> site is stored in SVN and the SVN repo has been switched to read-only,
> but we don't have the site repo on git available yet :/
>
> Right now, you can get the 2.0.8 source doing :
>
> git clone http://git-wip-us.apache.org/repos/asf/mina.git
>
> Hope it helps...
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>


-- 
http://gregoire.org/
http://code.google.com/p/red5/

Re: Red5 (was Re: ConnectFuture confusion)

[Mondain]

The projects compliment each other I think. Great servers are built on great
libraries.

Paul

On Mon, Mar 1, 2010 at 11:29 AM, Niklas Gustavsson wrote:

> On Mon, Mar 1, 2010 at 7:11 PM, Mondain  wrote:
> > I agree with Norman, as a Red5 core developer we depend on Mina a great
> > deal.
>
> As a Red5 user (in a project at work), I was thrilled to find MINA
> among the dependencies. Red5 is a very cool project, glad to have you
> along :-)
>
> /niklas
>



-- 
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/

Re: ConnectFuture confusion

[Mondain]

I wouldn't say I'm a Mina expert and I didn't initially code it into Red5,
but I personally like how easy it is to write protocol handlers and I/O
filters. Oh and theres the speed..

Paul

On Mon, Mar 1, 2010 at 11:35 AM, Alan D. Cabrera wrote:

> Cool!
>
> So, you've gone through the 2.0 codebase and found it acceptable?  What
> features do you like about 2.0 that are not in 1.0 that you find compelling.
>  Just curious.
>
>
> Regards,
> Alan
>
>
> On Mar 1, 2010, at 10:11 AM, Mondain wrote:
>
>  I agree with Norman, as a Red5 core developer we depend on Mina a great
>> deal. We are certainly awaiting a release of 2.0 to go along with our
>> own forthcoming 1.0 release. Although I have no proof, I do think that
>> some
>> our own server issues are related to Mina itself and the fixes you have
>> mentioned may help us.
>>
>> Keep up the outstanding work!
>> Paul
>>
>>
>>
>> On Mon, Mar 1, 2010 at 10:06 AM, Norman Maurer  wrote:
>>
>>  Hi all,
>>>
>>> I think it worth to break the API if it's needed to fix things , as
>>> long as you assist users while migrating...
>>>
>>> Just my 2 cent as a Mina user
>>>
>>> bye
>>> Norman
>>> 2010/3/1, Emmanuel Lecharny :
>>>
>>>> On 3/1/10 6:30 PM, Alan D. Cabrera wrote:
>>>>
>>>>>
>>>>> On Mar 1, 2010, at 9:20 AM, Emmanuel Lecharny wrote:
>>>>>
>>>>>  On 3/1/10 6:10 PM, Alan D. Cabrera wrote:
>>>>>>
>>>>>>>
>>>>>>> On Mar 1, 2010, at 8:04 AM, Emmanuel Lecharny wrote:
>>>>>>>
>>>>>>>  On 3/1/10 4:38 PM, Alan D. Cabrera wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Feb 26, 2010, at 9:03 AM, Ashish wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>  Thoughts ?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Unless it breaks the system, i would say lets not loose our sleep
>>>>>>>>>> over this.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> While I share the same opinion about the IoFuture hierarchy as you
>>>>>>>>> I have the same sentiments as Ashish.
>>>>>>>>>
>>>>>>>> I'm afraid that we might have to fix the issue in 2.0 Trust me,
>>>>>>>> i'm not pleased with this !
>>>>>>>>
>>>>>>>
>>>>>>> Fixing a bug is one thing.  Reorganizing a code base a few days
>>>>>>> after an attempted vote on its initial release is another.
>>>>>>>
>>>>>>
>>>>>> I know :/ This is why I created a branch, in a desesperate attempt to
>>>>>> get rid of all those futures, instead of doing that in trunk. Now, it
>>>>>> was the end of a long and painful week, chasing many bugs in many
>>>>>> places, and I was turning in circle.
>>>>>>
>>>>>> I *wish* we can fix the bug, without having to rewrite this part.
>>>>>>
>>>>>
>>>>> Another alternative is to totally abandon 2.x.  It was never
>>>>> officially released.  Just leave it as it is and work on the new 2.x
>>>>>
>>>> I'm also considering this option...
>>>>
>>>> --
>>>>
>>>> Regards,
>>>> Cordialement,
>>>> Emmanuel Lécharny
>>>> www.nextury.com
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> http://gregoire.org/
>> http://code.google.com/p/red5/
>> http://code.google.com/p/blue5/
>>
>
>


-- 
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/

Re: ConnectFuture confusion

[Mondain]

I agree with Norman, as a Red5 core developer we depend on Mina a great
deal. We are certainly awaiting a release of 2.0 to go along with our
own forthcoming 1.0 release. Although I have no proof, I do think that some
our own server issues are related to Mina itself and the fixes you have
mentioned may help us.

Keep up the outstanding work!
Paul



On Mon, Mar 1, 2010 at 10:06 AM, Norman Maurer  wrote:

> Hi all,
>
> I think it worth to break the API if it's needed to fix things , as
> long as you assist users while migrating...
>
> Just my 2 cent as a Mina user
>
> bye
> Norman
> 2010/3/1, Emmanuel Lecharny :
> > On 3/1/10 6:30 PM, Alan D. Cabrera wrote:
> >>
> >> On Mar 1, 2010, at 9:20 AM, Emmanuel Lecharny wrote:
> >>
> >>> On 3/1/10 6:10 PM, Alan D. Cabrera wrote:
> 
>  On Mar 1, 2010, at 8:04 AM, Emmanuel Lecharny wrote:
> 
> > On 3/1/10 4:38 PM, Alan D. Cabrera wrote:
> >>
> >> On Feb 26, 2010, at 9:03 AM, Ashish wrote:
> >>
> >>>
>  Thoughts ?
> >>>
> >>> Unless it breaks the system, i would say lets not loose our sleep
> >>> over this.
> >>
> >> While I share the same opinion about the IoFuture hierarchy as you
> >> I have the same sentiments as Ashish.
> > I'm afraid that we might have to fix the issue in 2.0 Trust me,
> > i'm not pleased with this !
> 
>  Fixing a bug is one thing.  Reorganizing a code base a few days
>  after an attempted vote on its initial release is another.
> >>>
> >>> I know :/ This is why I created a branch, in a desesperate attempt to
> >>> get rid of all those futures, instead of doing that in trunk. Now, it
> >>> was the end of a long and painful week, chasing many bugs in many
> >>> places, and I was turning in circle.
> >>>
> >>> I *wish* we can fix the bug, without having to rewrite this part.
> >>
> >> Another alternative is to totally abandon 2.x.  It was never
> >> officially released.  Just leave it as it is and work on the new 2.x
> > I'm also considering this option...
> >
> > --
> >
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.nextury.com
> >
> >
> >
>



-- 
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/

Re: RC ?

[Mondain]

Yes, please! Red5 would love an RC! :)

On Mon, Oct 12, 2009 at 6:15 AM, Ashish  wrote:

> On Mon, Oct 12, 2009 at 5:22 PM, Julien Vermillard
>  wrote:
> > Hi,
> >
> > Look like we are not receiving much bug reports on the last release.
> >
> > The only bug I can see is
> > https://issues.apache.org/jira/browse/DIRMINA-679
> > and it's not really easy to reproduce. I think it's the result of some
> > kind of strange executor filter combination.
> >
> > Personally I'm running M7 in production without any problems.
> >
> > WDYT about firing a vote ?
>
> +1
> Think everyone is waiting for an RC :-)
>
>
> >
> > Julien
> >
>
>
>
> --
> thanks
> ashish
>
> Blog: http://www.ashishpaliwal.com/blog
> My Photo Galleries: http://www.pbase.com/ashishpaliwal
>



-- 
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/

Re: Building snapshot from trunk

[Mondain]

Thank you :)

On Wed, Jul 29, 2009 at 10:03 AM, Emmanuel Lecharny wrote:

> Mondain wrote:
>
>> This may sound dumb, but I would like to know how to build a snapshot of
>> Mina trunk whether or not the tests fail. I'm not a Maven user so I am not
>> familiar with its options. After I get the latest from svn I issue "mvn
>> clean install" and lately this fails to build the target jars due to an
>> Mdc
>> test failing. What should I do in this case
>>
>>
>
> I will commit a fix (ignoring the failing tests) right now, so you'll be
> able to build from trunk.
>
> Otherwise, you can also do :
>
> mvn clean install -Dmaven.test.skip=true
>
> it should do the trick.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>


-- 
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/

Building snapshot from trunk

[Mondain]

This may sound dumb, but I would like to know how to build a snapshot of
Mina trunk whether or not the tests fail. I'm not a Maven user so I am not
familiar with its options. After I get the latest from svn I issue "mvn
clean install" and lately this fails to build the target jars due to an Mdc
test failing. What should I do in this case
Paul

-- 
http://gregoire.org/
http://code.google.com/p/red5/
http://code.google.com/p/blue5/

Re: [VOTE] Release MINA 2.0.0-M6

[Mondain]

Thanks for the heads-up Shawn. Also thanks to the team for an excellent
library!

On Tue, May 26, 2009 at 12:17 PM, Maarten Bosteels
wrote:

> +1
>
> Maarten
>
> On Tue, May 26, 2009 at 8:58 PM, Jeff Genender 
> wrote:
>
> > +1
> >
> >
> >
> > On May 26, 2009, at 12:52 PM, Niklas Gustavsson wrote:
> >
> >  On Tue, May 26, 2009 at 3:08 PM, Emmanuel Lecharny <
> elecha...@apache.org>
> >> wrote:
> >>
> >>> I didn't produced any package, as the mavn assembly plugin is deeply
> >>> bugged
> >>>
> >>
> >> Binaries available at http://people.apache.org/~ngn/mina/2.0.0-M6/<
> http://people.apache.org/%7Engn/mina/2.0.0-M6/>
> >>
> >>  [X] +1: Yes, release MINA-2.0.0-M6
> >>>
> >>
> >> /niklas
> >>
> >
> >
>



-- 
http://gregoire.org/
http://osflash.org/red5

Re: [VOTE] Release MINA 2.0.0-M6

[Mondain]

Guys,I've had no response to my query about the exception that i get in M6
but not in M5. It is critical to setting up the Acceptors and if I have
missed something please let me know; I would hate to see M6 go out with such
an obvious difference.
java.lang.NoSuchMethodError:
org.apache.mina.transport.socket.SocketAcceptor.bind([Ljava/net/SocketAddress;)V

Paul

On Tue, May 26, 2009 at 6:57 AM, Emmanuel Lecharny wrote:

> My vote ...
>
>> [X] +1: Yes, release MINA-2.0.0-M6
>>
>>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>


-- 
http://gregoire.org/
http://osflash.org/red5

Re: Question about trunk

[Mondain]

I've just tested the M6 branch and it still shows the same exception, is the
branch not based on M5?
Paul

Question about trunk

[Mondain]

Is trunk safe for testing? I built it yesterday but it comes up as version
"2.0.0-RC2-SNAPSHOT" why RC2?? Using the created jars with my M5 compliant
code throws this error:java.lang.NoSuchMethodError:
org.apache.mina.transport.socket.SocketAcceptor.bind([Ljava/net/SocketAddress;)V

Did I miss some important details on the list regarding the 2.0 version?

Paul

http://pastebin.com/m170fb4af

-- 
http://gregoire.org/
http://osflash.org/red5

Re: What about a quick 2.0.0-M6 release ?

[Mondain]

>From the peanut gallery.. yes please! :)I would be happy to replace M5 in
Red5 right away!

Paul

On Thu, May 14, 2009 at 8:38 AM, Maarten Bosteels
wrote:

> +1
>
> On Thu, May 14, 2009 at 2:34 PM, Ashish  wrote:
>
> > On Thu, May 14, 2009 at 1:30 PM, Emmanuel Lecharny  >
> > wrote:
> > > Hi guys,
> > >
> > > 2.0.0-M5 released introduced two regressions, one in the API (a method
> > has
> > > been removed by mistake) and another in the OrderedThreadPool, which is
> a
> > > bad one.
> > >
> > > What about releasing a quick 2.0.0-M6 to solve those two issues ?
> > >
> >
> > +1
> >
> > --
> > thanks
> > ashish
> >
> > Blog: http://www.ashishpaliwal.com/blog
> > My Photo Galleries: http://www.pbase.com/ashishpaliwal
> >
>



-- 
http://gregoire.org/
http://osflash.org/red5

Re: [ANNOUNCE] Apache MINA 2.0.0-M5 released

[Mondain]

Yay!! I was waiting for this release... btw was the old "spring" string
dropped from one of the jars, in favor of just "beans"?
Paul

On Wed, Apr 15, 2009 at 2:06 PM, Niklas Gustavsson  wrote:

> The Apache MINA project team is proud to announce the new Milestone
> of Apache MINA version 2.0.0-M5, a bug fix release. Next version
> will be a Release Candidate.
>
> Apache MINA is a network application framework which helps users
> develop high performance and high scalability network applications
> easily by providing an abstract, event-driven, asynchronous API over
> various transports such as TCP/IP and UDP/IP vis Java NIO.
>
> The Apache MINA project website includes resources such as
> introductory presentation slides, tutorials, and examples to help you
> learn MINA as soon as possible.
>
> The changeLog is provided at the end of this mail
>
> Download :
> ==
> * http://mina.apache.org/downloads.html
>
> Quick links:
> 
> * Homepage - http://mina.apache.org/
> * FAQ - http://mina.apache.org/faq.html
> * Testimonials - http://mina.apache.org/testimonials.html
> * Documentation - http://mina.apache.org/documentation.html
> * Performance - http://mina.apache.org/performance-test-reports.html
>
>
> The Apache MINA project team is always open for your feedback.  Please
> let us know what you think about MINA via our mailing list and support
> forum: http://mina.apache.org/contact.html
>
> Thank you !
>
> Release Notes - MINA - Version 2.0.0-M5
> ---
> Bug
>
>* [DIRMINA-626] - Compilation Error in
> org.apache.mina.transport.serial.DefaultSerialSessionConfig
>* [DIRMINA-646] - More than required data sent on serial port
> through serial transport
>* [DIRMINA-647] - WriteFuture.isWritten() never returns true even
> when data is actually sent on the serial port using serial transport
>* [DIRMINA-648] - Typo in LoggingFilter-API
>* [DIRMINA-652] -
> Socks5LogicHandler.encodeProxyRequestPacket(final SocksProxyRequest
> request) should check that the result of request.getEndpointAddress()
> is resolved before using it
>* [DIRMINA-653] - IoSession.write not thread-safe? Loosing
> messages under heavy multi-threaded write on same session.
>* [DIRMINA-658] - BufferedWriteFilter does not pass session closed
> or exception caught events up the filter chain
>* [DIRMINA-664] - EMPTY_* IoBuffer constants can be made mutable
> and cause data errors
>* [DIRMINA-665] - AbstractIoSession#getId() can cause collisions
> which lead to sessionClosed calls without sessionCreated
>* [DIRMINA-667] - NioDatagramConnector.newHandle leaks
> DatagramChannels on bind exception
>* [DIRMINA-674] - Mina xbean module requires mina-core for compile scope
>* [DIRMINA-675] - Duplicate data from decoder
>* [DIRMINA-676] - ObjectMBean throws NullPointerException when
> accessing non-existing attributes
>* [DIRMINA-677] - AbstractIoSession sometimes throws
> java.lang.Error in toString()
>
> Improvement
>
>* [DIRMINA-594] - Javadoc & documentation for APR transport
>* [DIRMINA-605] - Add documentation for using and building serial
> port connection
>* [DIRMINA-644] - OSGi exported packages should contain the mina version
>* [DIRMINA-649] - The OSGi exported packages should contain the
> version number of the package
>
> New Feature
>
>* [DIRMINA-520] - DemuxingIoHandler for SingleSessionIoHandlers
>
> Task
>
>* [DIRMINA-32] - Revise JavaDoc, PPT, and Tutorial
>
>
> The Apache MINA PMC.
>



-- 
http://gregoire.org/
http://osflash.org/red5

Re: MINA 3.0

[Mondain]

Ok, I see this mention of 3.0.. When is 2.0 going to be final? I really want
to upgrade Red5 from 1.1.7.
Paul

On Tue, Mar 10, 2009 at 1:30 AM, Emmanuel Lecharny wrote:

> Julien Vermillard wrote:
>
>> Le Mon, 9 Mar 2009 22:20:13 -0400,
>> Mark Webb  a écrit :
>>
>>
>>
>>> I see that there are JIRA entries for MINA 3.0.  Is there a branch for
>>> this yet, or are we still using the trunk for that?
>>>
>>> Sorry, I've been away for a while.  New job and grad school are taking
>>> up alot of time.
>>>
>>> --Mark
>>>
>>>
>>
>> Hi,
>> TRUNK is still the future 2.0RC1,  the 3.0 brnach is not started yet.
>>
>> Julien
>>
>>
> We just created a place where we can inject our wishes for the next version
> :)
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>


-- 
http://gregoire.org/
http://osflash.org/red5