[jira] Created: (DIRMINA-686) Maven jars metadata is corrupted and no longer includes any previous mina-core jars
Maven jars metadata is corrupted and no longer includes any previous mina-core jars --- Key: DIRMINA-686 URL: https://issues.apache.org/jira/browse/DIRMINA-686 Project: MINA Issue Type: Bug Components: Web Site / Documentation Affects Versions: 2.0.0-M5 Reporter: Toli Kuznets It seems that after the 2.0-M5 release, the Maven metadata in all the major repositories is corrupted. It no longer includes the information for the previous Mina jars, but only for the current 2.0-M5 release. For example, the http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/mina/mina-core/maven-metadata.xml file only has the entry for 2.0.0-M5 and not for any prior versions. This means that any code relying on previous versions of Mina dos not compile since maven is not able to find those jars. Would it be possible to redeploy the latest jars while preserving the metadata information? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Vysper as MINA subproject
+1 On Sun, Apr 12, 2009 at 10:04 PM, Mark Webb wrote: > +1 > > On Sun, Apr 12, 2009 at 1:34 PM, Niklas Gustavsson > wrote: > > On Sun, Apr 12, 2009 at 10:32 AM, Julien Vermillard > > wrote: > >> [X] +1 Yes, accept Vysper as a sub-project > > > > /niklas > > > -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org
Re: [VOTE] Vysper as MINA subproject
+1 On Sun, Apr 12, 2009 at 1:34 PM, Niklas Gustavsson wrote: > On Sun, Apr 12, 2009 at 10:32 AM, Julien Vermillard > wrote: >> [X] +1 Yes, accept Vysper as a sub-project > > /niklas >
Re: [DISCUSS] Moving Vysper lab to MINA as a sub-product
On Sun, Apr 12, 2009 at 10:24, Niklas Gustavsson wrote: > On Sat, Apr 11, 2009 at 10:51 PM, Bernd Fondermann > wrote: >> plus some degree of >> mavenization >> >> ugh. :-/ > > We can probably help out with this :-) > >> and headers cleaning would be necessary, >> >> You mean, adding "@author The Apache Directory project"? ;-) >> >> and last, not >> least, a >> general formating (using MINA code formatter) >> >> where can I get that from? >> I have some specific code formatting at some specific lines (where >> XMPP stanzas are built). I'd like to see what it does to them. > > Here's the documented guidelines for MINA: > http://mina.apache.org/developer-guide.html > >> There have been different opinions on this. It has never been executed >> before. So this is the first try. >> >> If the code would have to go through Incubator (via an IP clearance >> vote) this wouldn't be a big thing, too. > > Would you mind starting a discussion over a labs about this? I'll join > the list and follow along. I'll do that as soon as possible. Bernd
TODOs for moving Vysper
Hi, this is a probably incomplete list of things to do to move Vysper over here. MOVE PROJECTS + ratify reception of code (MINA) (vote, pending) + ratify Vysper lab completion on Labs side (vote) + (optional) do additional steps as required to move from Labs to MINA, for example moving through Incubator IP CLEARANCE + check dependencies, NOTICE, LICENSE etc. INFRA + move LABS/Vysper JIRAs + move Vysper svn + move Vysper's cwiki pages CODE (after svn move) + adjust code to MINA conventions (headers etc.) + use maven for build KARMA + grant berndf committer karma for Vysper Anything else? Bernd
Re: Scala bindings
On Sun, Apr 12, 2009 at 10:10 AM, Niklas Gustavsson wrote: > Oh, sure. If we import it I would suggest we put it into the sandbox > until we feel more confident in that it's ready to be part of the core > project. Anyone got an opinion on if we need a Software grant for this contribution? http://www.apache.org/licenses/#grants /niklas
Re: [VOTE] Vysper as MINA subproject
On Sun, Apr 12, 2009 at 10:32 AM, Julien Vermillard wrote: > [X] +1 Yes, accept Vysper as a sub-project /niklas
[jira] Updated: (DIRMINA-477) Update page about differences between 1.x and 2.x
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard updated DIRMINA-477: -- Fix Version/s: (was: 2.0.0-M5) 2.0.0-RC1 > Update page about differences between 1.x and 2.x > - > > Key: DIRMINA-477 > URL: https://issues.apache.org/jira/browse/DIRMINA-477 > Project: MINA > Issue Type: Task > Components: Web Site / Documentation >Reporter: Trustin Lee >Assignee: Trustin Lee > Fix For: 2.0.0-RC1 > > > Our current web site doesn't describe what have been changed in 2.x comparing > to 1.x. We need to carefully put all changes together there so people can > migrate more easily. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-575) Add the missing Javadoc, add some comments
[ https://issues.apache.org/jira/browse/DIRMINA-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard updated DIRMINA-575: -- Fix Version/s: (was: 2.0.0-M5) 2.0.0-RC1 > Add the missing Javadoc, add some comments > -- > > Key: DIRMINA-575 > URL: https://issues.apache.org/jira/browse/DIRMINA-575 > Project: MINA > Issue Type: Task > Components: Web Site / Documentation >Reporter: Emmanuel Lecharny >Priority: Blocker > Fix For: 2.0.0-RC1 > > > If we except the interfaces, the code lacks of javadoc and comments, which > make it complicated for new committers to get into it. > We need to add those missing javadocs, and comments where it's necessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard updated DIRMINA-539: -- Fix Version/s: (was: 2.0.0-M5) 2.0.0-RC1 > NioDatagramConnector doesn't takes the TrafficClass value set to his > DatagramSessionConfig > --- > > Key: DIRMINA-539 > URL: https://issues.apache.org/jira/browse/DIRMINA-539 > Project: MINA > Issue Type: Bug >Affects Versions: 2.0.0-M1 > Environment: WinXP, RHEL5 (probably not important) >Reporter: martin krivosik >Assignee: Emmanuel Lecharny > Fix For: 2.0.0-RC1 > > Original Estimate: 0.33h > Remaining Estimate: 0.33h > > client sending datagrams without taking care to the trafficClas set in the > config, so the ToS byte is not set in the packet sent from client. > client code: > NioDatagramAcceptor acceptor = new NioDatagramAcceptor(); > DatagramSessionConfig dcfg = > ((NioDatagramAcceptor)acceptor).getSessionConfig(); > dcfg.setTrafficClass(tosByte); > InetSocketAddress bindAddrPort = new InetSocketAddress(originatingIP, > port); > acceptor.bind(bindAddrPort); > -> connecting to another computer with NioDatagramConnector. > for me it looks like in the newHandle method of NioDatagramConnector is not > cared about TrafficClass (like it is done in NioDatagramAcceptor.open()) > The server part with the accceptor is OK and the correct ToS byte is set in > the packet. > (the same problem may be in the socket, i have to check it) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-612) Add documentation on SingleSessionIohandler
[ https://issues.apache.org/jira/browse/DIRMINA-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard updated DIRMINA-612: -- Fix Version/s: (was: 2.0.0-M5) 2.0.0-RC1 > Add documentation on SingleSessionIohandler > --- > > Key: DIRMINA-612 > URL: https://issues.apache.org/jira/browse/DIRMINA-612 > Project: MINA > Issue Type: Task > Components: Web Site / Documentation >Affects Versions: 2.0.0-M2 >Reporter: Geert Schuring >Priority: Minor > Fix For: 2.0.0-RC1 > > Original Estimate: 1h > Remaining Estimate: 1h > > A normal multi-session IoHandler can be added to the acceptor using the > "addHandler" method. However, when writing a single-session IoHandler I can't > find any information about how to register it with the acceptor. The > "addHandler" method doesn't accept single-session IoHandlers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-593) Javadoc & documentation for org/apache/mina/filter/reqres
[ https://issues.apache.org/jira/browse/DIRMINA-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard updated DIRMINA-593: -- Fix Version/s: (was: 2.0.0-M5) 2.0.0-RC1 > Javadoc & documentation for org/apache/mina/filter/reqres > - > > Key: DIRMINA-593 > URL: https://issues.apache.org/jira/browse/DIRMINA-593 > Project: MINA > Issue Type: Improvement > Components: Filter, Web Site / Documentation >Affects Versions: 2.0.0-M1 >Reporter: Julien Vermillard > Fix For: 2.0.0-RC1 > > > no javadoc nor doc on the request/response filter, it need some examples too -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-672) CumulativeProtocolDecoder/ DemuxingProtocolDecoder
[
https://issues.apache.org/jira/browse/DIRMINA-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien Vermillard updated DIRMINA-672:
--
Fix Version/s: (was: 2.0.0-M5)
2.0.0-RC1
> CumulativeProtocolDecoder/ DemuxingProtocolDecoder
> --
>
> Key: DIRMINA-672
> URL: https://issues.apache.org/jira/browse/DIRMINA-672
> Project: MINA
> Issue Type: Bug
> Components: Filter
>Affects Versions: 2.0.0-M1, 2.0.0-M2, 2.0.0-M3, 2.0.0-M4
> Environment: JDK / OS independent
>Reporter: James Talmage
>Assignee: Emmanuel Lecharny
> Fix For: 2.0.0-RC1
>
> Attachments: DemuxingProtocolDecoderBugTest.java
>
>
> Excerpt from forum discussion at:
> http://www.nabble.com/Potential-DemuxingProtocolDecoderBug-td22489974.html
> I'm using 2.0.0-M4. Upon inspection of the source code, I can tell it's
> going to be a JDK / OS independent issue. Also upon inspection, I've
> discovered the bug is actually in the CumulativeProtocolDecoder (starting @
> line 125):
> if (!session.getTransportMetadata().hasFragmentation()) {
> doDecode(session, in, out);
> return;
> }
> This breaks the contract with the doDecode method as it is only called once
> (the documentation says it should be called repeatedly until it returns
> false). The following changes makes my previous test case pass, but it's
> probably a little simplistic.
> if (!session.getTransportMetadata().hasFragmentation()) {
> while(in.hasRemaining() && doDecode(session, in, out)){
> //Do nothing
> }
> return;
> }
> The code should probably make sure that if doDecode returns true, some of the
> buffer was actually consumed (as the code for fragmented transports does).
> Also, it may make sense to provide another method (i.e.
> finishNonFragmentedDecode(...)), for handling the remainder of the buffer
> after doDecode returns false.
> I see where the author was headed with this code. Transports (such as UDP)
> that don't support fragmentation probably don't jive with the concept of an
> accumulating buffer (what do we do with the accumulation buffer if we drop a
> UDP packet?). It does however make perfect sense to use such transports with
> the concept of a DemuxingProtocolDecoder. Perhaps it would be better to
> refactor the DemuxingProtocolDecoder so that it's not a subclass of
> CumulativeProtocolDecoder. Create a helper class that handles the fragment
> accumulation aspect. CumulativeProtocolDecoder would always use said helper
> class (throwing an error if the protocol doesn't support fragmentation), but
> DemuxingProtocolDecoder could opt to use it depending on the protocol it
> encounters.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-679) NullPointerException in ProtocolCodecFilter.filterWrite
[ https://issues.apache.org/jira/browse/DIRMINA-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard updated DIRMINA-679: -- Fix Version/s: (was: 2.0.0-M5) 2.0.0-RC1 > NullPointerException in ProtocolCodecFilter.filterWrite > --- > > Key: DIRMINA-679 > URL: https://issues.apache.org/jira/browse/DIRMINA-679 > Project: MINA > Issue Type: Bug >Affects Versions: 2.0.0-M4 >Reporter: John J. Franey > Fix For: 2.0.0-RC1 > > > Looks like filterWrite obtains a reference from the session's attributes, but > the desired attribute is not there. > I am running max of 250 datagram sockets under load test for my application. > Connections last about 60 seconds and released. A new connection is made to > keep the total number of active connections up to 250. > Over a period of two hours running this load test, this exception occured > twice. > org.apache.mina.filter.codec.ProtocolEncoderException: > java.lang.NullPointerException > at > org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:312) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:506) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.access$7(DefaultIoFilterChain.java:501) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:814) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.filterWrite(DefaultIoFilterChain.java:740) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:506) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:498) > at > org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:418) > at > org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:359) > > Caused by: java.lang.NullPointerException > at > org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:297) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:814) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.filterWrite(DefaultIoFilterChain.java:741) > at > org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:498) > at > org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:359) > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-632) WriteFuture.awaitUninterruptibly() or .join() hangs if write() throws Exceptions
[ https://issues.apache.org/jira/browse/DIRMINA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard updated DIRMINA-632: -- Fix Version/s: (was: 2.0.0-M5) 2.0.0-RC1 > WriteFuture.awaitUninterruptibly() or .join() hangs if write() throws > Exceptions > > > Key: DIRMINA-632 > URL: https://issues.apache.org/jira/browse/DIRMINA-632 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 1.0.10, 1.1.7, 2.0.0-M3 >Reporter: Barrie Treloar > Fix For: 2.0.0-RC1 > > Attachments: mina-1.1-handle-write-exceptions-with-test.txt, > mina-2.0-handle-write-exceptions-test.txt, > mina-2.0-handle-write-exceptions.txt, > mina-2.0-memory_monitor-withExceptionNotifier.txt, mina-2.0-memory_monitor.txt > > > This is best shown with UDP since TCP will cause a close session to occur. > If channel.write() throws an exception, e.g. the host becomes unreachable > because of network connection is removed, then > WriteFuture.awaitUninterruptibly() will hang - as it will never have > setWritten(false) or setException() called. > I have modified the MemoryMonitor example to show this happening. > You must manually pull your network cable (or disable your Network Adapter) > while the client is running to see this happen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-673) Build produces invalid jar file
[ https://issues.apache.org/jira/browse/DIRMINA-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard updated DIRMINA-673: -- Fix Version/s: (was: 2.0.0-M5) 2.0.0-RC1 > Build produces invalid jar file > --- > > Key: DIRMINA-673 > URL: https://issues.apache.org/jira/browse/DIRMINA-673 > Project: MINA > Issue Type: Bug >Affects Versions: 2.0.0-M4 >Reporter: Chris Custine > Fix For: 2.0.0-RC1 > > Attachments: DIRMINA-673.patch > > > The build step for adding license files via the ant zip task produces invalid > jar files because the manifest is not guaranteed to be the first file in the > archive (part of the jar spec). This is affecting deployment in OSGi > containers and any other code that uses JarInputStream to read the manifest > prior to deployment because it expects the manifest to be the first file in > the archive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-682) We need a better documentation for the ExecutorFilter [was :Writing more than one message will block until the MessageReceived as been fully proceced]
[
https://issues.apache.org/jira/browse/DIRMINA-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien Vermillard updated DIRMINA-682:
--
Fix Version/s: (was: 2.0.0-M5)
2.0.0-RC1
> We need a better documentation for the ExecutorFilter [was :Writing more than
> one message will block until the MessageReceived as been fully proceced]
> --
>
> Key: DIRMINA-682
> URL: https://issues.apache.org/jira/browse/DIRMINA-682
> Project: MINA
> Issue Type: Improvement
>Affects Versions: 2.0.0-M4
>Reporter: Emmanuel Lecharny
>Priority: Critical
> Fix For: 2.0.0-RC1
>
>
> When a message generates mor ethan one response, then the written responses
> will be sent to the client only when the initial message has been totally
> processed.
> Suppose that we receive one message M, it will be handled by a IoProcessor in
> the process() method, go through the chain to the IoHandler.MessageReceive()
> method. Now, if one want to write more than one response (session.write( R
> )), then those responses will be enqueued until we are back to the process()
> method.
> The issue is due to the fact that the write is done using the IoProcessor
> associated to the current session, leading to a problem : we can't ask the
> IoProcessor instance to unqueue the written message until it is done with the
> current processing( it's running in one single thread).
> The consequences are painfull :
> - if one tries to write two responses, waiting for the first responses to be
> written, this will end with a DeadLock, as we are waiting on the processor we
> are holding
> - if we don't care about waiting for the write to be done, then all the
> responses will be enqueued and stored in memory, until the IoProcessor exit
> from the read processing and start processing the writes, leading to OOM
> Exception
> One solution would be to have to sets of IoProcessors, one for the read, and
> one for the writes. Or to pick a random Processor to process the writes, as
> soon as the processor is not the same as the one processing the reads.
> Here is a sample exhibiting the problem. Just launch it, and use 'telnet
> localhost 8080' in a console, type something, it should write twice the typed
> message, but it just generates an exception - see further - and write back
> the message once. Removing the wait will work, but the messages will be sent
> only when the read has been processed in the
> AbstractPollingIoProcessor.process(T session) method :
> /**
> * Deal with session ready for the read or write operations, or both.
> */
> private void process(T session) {
> // Process Reads
> if (isReadable(session) && !session.isReadSuspended()) {
> read(session);
> }
> // Process writes
> if (isWritable(session) && !session.isWriteSuspended()) {
> scheduleFlush(session);
> }
> }
> The sample code :
> package org.apache.mina.real.life;
> import java.net.InetSocketAddress;
> import org.apache.mina.core.buffer.IoBuffer;
> import org.apache.mina.core.future.WriteFuture;
> import org.apache.mina.core.service.IoHandlerAdapter;
> import org.apache.mina.core.session.IoSession;
> import org.apache.mina.filter.logging.LoggingFilter;
> import org.apache.mina.transport.socket.SocketAcceptor;
> import org.apache.mina.transport.socket.nio.NioSocketAcceptor;
> /**
> * (Entry point) Echo server
> *
> * @author The Apache MINA Project (dev@mina.apache.org)
> */
> public class Main {
> private static class EchoProtocolHandler extends IoHandlerAdapter {
> public void messageReceived(IoSession session, Object message)
> throws Exception {
> System.out.println(new String(((IoBuffer)message).array()));
> // Write the received data back to remote peer
> WriteFuture wf = session.write(((IoBuffer) message).duplicate());
>
> // Here, we will get a Deadlock detection
> wf.awaitUninterruptibly();
>
> // Do a second write
> session.write(((IoBuffer) message).duplicate());
> }
> }
> /** Choose your favorite port number. */
> private static final int PORT = 8080;
> public static void main(String[] args) throws Exception {
> SocketAcceptor acceptor = new NioSocketAcceptor();
>
> // Add a logging filter
> acceptor.getFilterChain().addLast( "Logger", new LoggingFilter() );
>
> // Bind
> acceptor.setHandler(new EchoProtocolHandler());
> acceptor.bind(new InetSocketAddress(PORT));
> System.out.println("Listening on por
Re: [VOTE] Vysper as MINA subproject
+1 Julien Le Sun, 12 Apr 2009 10:32:15 +0200, Julien Vermillard a écrit : > Hi guys, > > Bernd Fondermann has written a XMPP server based on MINA in Apache > labs. As discussed earlier we all see interest in making Vysper a MINA > sub-project, do let's vote : > > [] +1 Yes, accept Vysper as a sub-project > [] +/-0 I don't really care > [] -1 Nope, MINA is not the place for Vysper > > Julien signature.asc Description: PGP signature
Re: [VOTE] Vysper as MINA subproject
On Sun, Apr 12, 2009 at 10:32, Julien Vermillard wrote: > Hi guys, > > Bernd Fondermann has written a XMPP server based on MINA in Apache labs. > As discussed earlier we all see interest in making Vysper a MINA > sub-project, do let's vote : [X] +1 Yes, accept Vysper as a sub-project (happy but non-binding) Bernd
Re: [VOTE] Vysper as MINA subproject
+1 On Apr 12, 2009, at 2:32 AM, Julien Vermillard wrote: Hi guys, Bernd Fondermann has written a XMPP server based on MINA in Apache labs. As discussed earlier we all see interest in making Vysper a MINA sub-project, do let's vote : [] +1 Yes, accept Vysper as a sub-project [] +/-0 I don't really care [] -1 Nope, MINA is not the place for Vysper Julien
Re: Scala bindings
On Sun, Apr 12, 2009 at 8:11 PM, Niklas Gustavsson wrote:
> On Sat, Apr 11, 2009 at 5:22 AM, Rich Dougherty wrote:
>> That sounds great. The main issue that (IMO) needs resolving is flow
>> control. At the moment, MINA events are converted to actor messages. It
>> might be possible for events to arrive too quickly and use up all memory. I
>> think there needs to be some sort of communication back from the actor so
>> that MINA can hold off sending new events until it is ready.
>
> Isn't this the general issue about flow control in MINA, with or without
> Scala?
I think it's a slightly different issue. I'm talking about the fact
that the IoHandler implementation for the Scala bindings basically
does something like:
def messageReceived(session: IoSession, message: Any) = {
...
sessionActor ! MessageReceived(message)
}
There is no acknowledgement back from the sessionActor at all. As far
as the rest of MINA knows, the message has been handled as soon as the
messageReceived method returns. But all we've done is sent an
asynchronous notification to the session actor; we don't know when it
will actually be processed. MINA's existing flow control code would
not be able to know whether or not the message has been handled.
Cheers
Rich
--
http://blog.richdougherty.com/
Re: [VOTE] Vysper as MINA subproject
[X] +1 Yes, accept Vysper as a sub-project On 4/12/09, Julien Vermillard wrote: > Hi guys, > > Bernd Fondermann has written a XMPP server based on MINA in Apache labs. > As discussed earlier we all see interest in making Vysper a MINA > sub-project, do let's vote : > > [] +1 Yes, accept Vysper as a sub-project > [] +/-0 I don't really care > [] -1 Nope, MINA is not the place for Vysper > > Julien > -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
[VOTE] Vysper as MINA subproject
Hi guys, Bernd Fondermann has written a XMPP server based on MINA in Apache labs. As discussed earlier we all see interest in making Vysper a MINA sub-project, do let's vote : [] +1 Yes, accept Vysper as a sub-project [] +/-0 I don't really care [] -1 Nope, MINA is not the place for Vysper Julien signature.asc Description: PGP signature
Re: [DISCUSS] Moving Vysper lab to MINA as a sub-product
On Sat, Apr 11, 2009 at 10:51 PM, Bernd Fondermann wrote: > plus some degree of > mavenization > > ugh. :-/ We can probably help out with this :-) > and headers cleaning would be necessary, > > You mean, adding "@author The Apache Directory project"? ;-) > > and last, not > least, a > general formating (using MINA code formatter) > > where can I get that from? > I have some specific code formatting at some specific lines (where > XMPP stanzas are built). I'd like to see what it does to them. Here's the documented guidelines for MINA: http://mina.apache.org/developer-guide.html > There have been different opinions on this. It has never been executed > before. So this is the first try. > > If the code would have to go through Incubator (via an IP clearance > vote) this wouldn't be a big thing, too. Would you mind starting a discussion over a labs about this? I'll join the list and follow along. /niklas
Re: [DISCUSS] Moving Vysper lab to MINA as a sub-product
On Sat, Apr 11, 2009 at 12:54 AM, Emmanuel Lecharny wrote: > Niklas Gustavsson wrote: > http://mail-archives.apache.org/mod_mbox/incubator-general/200809.mbox/%3c48c64112.4020...@rowe-clan.net%3e So it seems like we could just move the code over, given that MINA formally accepts it as a sub project. Should we start a formal vote? >> If we can, I'll be happy to help out with the practicalities. Also, I >> assume Bernd would need to be voted in as a MINA committer, right? > > Right ! I guess this is better done after the project is voted into MINA. /niklas
Re: Scala bindings
On Sat, Apr 11, 2009 at 5:22 AM, Rich Dougherty wrote: > That sounds great. The main issue that (IMO) needs resolving is flow > control. At the moment, MINA events are converted to actor messages. It > might be possible for events to arrive too quickly and use up all memory. I > think there needs to be some sort of communication back from the actor so > that MINA can hold off sending new events until it is ready. Isn't this the general issue about flow control in MINA, with or without Scala? /niklas
Re: Scala bindings
On Sat, Apr 11, 2009 at 12:56 AM, Emmanuel Lecharny wrote: > Niklas Gustavsson wrote: >> Rich Dougherty has developed MINA bindings for Scala >> (https://issues.apache.org/jira/browse/DIRMINA-499) that was >> previously rejected from inclusion into MINA due to the lack of >> committer support. > > It was not rejected. The patch is still pending in JIRA : > https://issues.apache.org/jira/browse/DIRMINA-499 Rejected might have been to wrong wording. "Not accepted for the time being" might be a better choice :-) >> I would now be happy to provide that support. Rich, >> would you still be interested in contributing the bindings to the MINA >> project? The rest of you, would you find bringing these into the main >> project a good idea? >> > > That's fine as soon as some one document it up to a point it can be > maintained... Oh, sure. If we import it I would suggest we put it into the sandbox until we feel more confident in that it's ready to be part of the core project. Btw, aren't your out sailing or something? :-) /niklas
