[jira] Updated: (DIRMINA-497) Thread safety issue: incorrect usage of Collections.synchronizedMap in DefaultIoSessionDataStructureFactory.DefaultIoSessionAttributeMap
[ https://issues.apache.org/jira/browse/DIRMINA-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David M. Lloyd updated DIRMINA-497: --- Attachment: DIRMINA-497-1.patch A patch that uses regular synchronization instead of Collections.synchronizedMap(). Thread safety issue: incorrect usage of Collections.synchronizedMap in DefaultIoSessionDataStructureFactory.DefaultIoSessionAttributeMap Key: DIRMINA-497 URL: https://issues.apache.org/jira/browse/DIRMINA-497 Project: MINA Issue Type: Bug Components: Core Reporter: David M. Lloyd Attachments: DIRMINA-497-1.patch In trunk, the DefaultIoSessionAttributeMap.setAttributeIfAbsent() synchronizes on the attributes map in order to synchronize access with the other get/setAttribute methods. However, Collections.synchronizedMap does NOT synchronize on the map itself, but rather an internal object! So, setAttributeIfAbsent() still contains a race condition. A good solution for 2.x would be to simply use a ConcurrentMap, which has putIfAbsent(). For 1.0.x, which has to run on JDK 1.4 (correct?), I'd recommend to just drop Collections.synchronizedMap() and synchronize directly on the Map reference itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David M. Lloyd updated DIRMINA-495:
---
Attachment: (was: IoConnector.patch)
IoConnector needs a way to store information into the IoSession before the
IoHandler gets ahold of it
-
Key: DIRMINA-495
URL: https://issues.apache.org/jira/browse/DIRMINA-495
Project: MINA
Issue Type: New Feature
Components: Core
Reporter: David M. Lloyd
Assignee: Mike Heath
Fix For: 2.0.0-M1
Attachments: DIRMINA-495-3.patch, IoConnector.patch
It is often necessary to pass information into the IoHandler associated with
an IoConnector. Sometimes this information is needed even as early as
IoSession creation time. A mechanism is needed to pass information in to the
IoSession at the time you call IoConnector.connect(). Discussing this with
Mike Heath, we determined that a logical approach could be to have variants
of the connect() methods that accept information that can be attached to the
IoSession when it is created.
One option is to simply pass a Map in to the connect method. The contents of
the Map would be copied into the IoSession's attribute map after it is
constructed but before the IoHandler.sessionCreated method is created. In
addition, it seems likely that in many cases only one entry would need to be
added - in this case the user could simply do this:
ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
Another option would be to use variable argument lists to accept any number
of key-value pairs. The pairs could be represented by a class -
AttributePair for example. It could look like this:
public final class AttributePairK, V {
private final K key;
private final V value;
private AttributePair(K key, V value) { this.key = key; this.value =
value; }
public static K, V AttributePairK,V pair(K key, V value) { return
new AttributePairK, V(key, value); }
}
Then the user can use static imports to pull in the pair method. The
connect() method on IoConnector could accept a variable list of AttributePair
objects, so the user could write code like this:
ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
myValue2));
Though this approach is somewhat more complicated than just using a Map.
Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Heath updated DIRMINA-495:
---
Attachment: DIRMINA-295-mikeheath.patch
Here is the callback solution I've implemented. Any feedback would be
appreciated. If I don't hear any objects, I'll commit these changes in 72
hours.
IoConnector needs a way to store information into the IoSession before the
IoHandler gets ahold of it
-
Key: DIRMINA-495
URL: https://issues.apache.org/jira/browse/DIRMINA-495
Project: MINA
Issue Type: New Feature
Components: Core
Reporter: David M. Lloyd
Assignee: Mike Heath
Fix For: 2.0.0-M1
Attachments: DIRMINA-295-mikeheath.patch, DIRMINA-495-3.patch,
IoConnector.patch
It is often necessary to pass information into the IoHandler associated with
an IoConnector. Sometimes this information is needed even as early as
IoSession creation time. A mechanism is needed to pass information in to the
IoSession at the time you call IoConnector.connect(). Discussing this with
Mike Heath, we determined that a logical approach could be to have variants
of the connect() methods that accept information that can be attached to the
IoSession when it is created.
One option is to simply pass a Map in to the connect method. The contents of
the Map would be copied into the IoSession's attribute map after it is
constructed but before the IoHandler.sessionCreated method is created. In
addition, it seems likely that in many cases only one entry would need to be
added - in this case the user could simply do this:
ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
Another option would be to use variable argument lists to accept any number
of key-value pairs. The pairs could be represented by a class -
AttributePair for example. It could look like this:
public final class AttributePairK, V {
private final K key;
private final V value;
private AttributePair(K key, V value) { this.key = key; this.value =
value; }
public static K, V AttributePairK,V pair(K key, V value) { return
new AttributePairK, V(key, value); }
}
Then the user can use static imports to pull in the pair method. The
connect() method on IoConnector could accept a variable list of AttributePair
objects, so the user could write code like this:
ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
myValue2));
Though this approach is somewhat more complicated than just using a Map.
Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551900
]
mheath edited comment on DIRMINA-495 at 12/14/07 11:12 AM:
---
Here is the callback solution I've implemented (the DIRMAIN-495-mikeheath.patch
file). Any feedback would be appreciated. If I don't hear any objects, I'll
commit these changes in 72 hours.
was (Author: mheath):
Here is the callback solution I've implemented. Any feedback would be
appreciated. If I don't hear any objects, I'll commit these changes in 72
hours.
IoConnector needs a way to store information into the IoSession before the
IoHandler gets ahold of it
-
Key: DIRMINA-495
URL: https://issues.apache.org/jira/browse/DIRMINA-495
Project: MINA
Issue Type: New Feature
Components: Core
Reporter: David M. Lloyd
Assignee: Mike Heath
Fix For: 2.0.0-M1
Attachments: DIRMINA-295-mikeheath.patch, DIRMINA-495-3.patch,
IoConnector.patch
It is often necessary to pass information into the IoHandler associated with
an IoConnector. Sometimes this information is needed even as early as
IoSession creation time. A mechanism is needed to pass information in to the
IoSession at the time you call IoConnector.connect(). Discussing this with
Mike Heath, we determined that a logical approach could be to have variants
of the connect() methods that accept information that can be attached to the
IoSession when it is created.
One option is to simply pass a Map in to the connect method. The contents of
the Map would be copied into the IoSession's attribute map after it is
constructed but before the IoHandler.sessionCreated method is created. In
addition, it seems likely that in many cases only one entry would need to be
added - in this case the user could simply do this:
ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
Another option would be to use variable argument lists to accept any number
of key-value pairs. The pairs could be represented by a class -
AttributePair for example. It could look like this:
public final class AttributePairK, V {
private final K key;
private final V value;
private AttributePair(K key, V value) { this.key = key; this.value =
value; }
public static K, V AttributePairK,V pair(K key, V value) { return
new AttributePairK, V(key, value); }
}
Then the user can use static imports to pull in the pair method. The
connect() method on IoConnector could accept a variable list of AttributePair
objects, so the user could write code like this:
ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
myValue2));
Though this approach is somewhat more complicated than just using a Map.
Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551900
]
mheath edited comment on DIRMINA-495 at 12/14/07 11:12 AM:
---
Here is the callback solution I've implemented (the DIRMINA-495-mikeheath.patch
file, er... DIRMINA-295-mikeheath.patch - Where did I learn how to type? :) ).
Any feedback would be appreciated. If I don't hear any objects, I'll commit
these changes in 72 hours.
was (Author: mheath):
Here is the callback solution I've implemented (the
DIRMAIN-495-mikeheath.patch file). Any feedback would be appreciated. If I
don't hear any objects, I'll commit these changes in 72 hours.
IoConnector needs a way to store information into the IoSession before the
IoHandler gets ahold of it
-
Key: DIRMINA-495
URL: https://issues.apache.org/jira/browse/DIRMINA-495
Project: MINA
Issue Type: New Feature
Components: Core
Reporter: David M. Lloyd
Assignee: Mike Heath
Fix For: 2.0.0-M1
Attachments: DIRMINA-295-mikeheath.patch, DIRMINA-495-3.patch,
IoConnector.patch
It is often necessary to pass information into the IoHandler associated with
an IoConnector. Sometimes this information is needed even as early as
IoSession creation time. A mechanism is needed to pass information in to the
IoSession at the time you call IoConnector.connect(). Discussing this with
Mike Heath, we determined that a logical approach could be to have variants
of the connect() methods that accept information that can be attached to the
IoSession when it is created.
One option is to simply pass a Map in to the connect method. The contents of
the Map would be copied into the IoSession's attribute map after it is
constructed but before the IoHandler.sessionCreated method is created. In
addition, it seems likely that in many cases only one entry would need to be
added - in this case the user could simply do this:
ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
Another option would be to use variable argument lists to accept any number
of key-value pairs. The pairs could be represented by a class -
AttributePair for example. It could look like this:
public final class AttributePairK, V {
private final K key;
private final V value;
private AttributePair(K key, V value) { this.key = key; this.value =
value; }
public static K, V AttributePairK,V pair(K key, V value) { return
new AttributePairK, V(key, value); }
}
Then the user can use static imports to pull in the pair method. The
connect() method on IoConnector could accept a variable list of AttributePair
objects, so the user could write code like this:
ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
myValue2));
Though this approach is somewhat more complicated than just using a Map.
Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Revisiting logging in MINA 2.0
On Thursday 13 December 2007 18:26:38 Trustin Lee wrote: On Dec 14, 2007 2:05 AM, Luc Willems [EMAIL PROTECTED] wrote: On Thursday 13 December 2007 03:50:14 Trustin Lee wrote: This issue is becoming a real headache even a bottle of tylenol can't fix, along with the reentrant logging issue: http://xrl.us/bctaa I think these two issues should be considered together to resolve the issues related with logging. Let me summarize current situation: 1) There are people (A) who don't want to use SLF4J but java.util.logging. 2) There are people (B) who like to use SLF4J and they say SLF4J supports java.util.logging along with log4j. 3) People A say java.util.logging can also do the same by employing a proper LogManager implementation. 4) There is a logger reentrance problem in MINA, which means it is difficult to write a MINA-based appender for the most logging frameworks that doesn't allow reentrance. This problem can be worked around by turning off logging in MINA, but this is not reasonable. to make the picture a bit complexer . there is also a dependancy to apache commons-logging if you use the JMX classes. IoServiceBean depends on beanutils which uses commons-logging. i don't know how hard this dependancy is to beanutils. if we could remove this dependancy , it would reduce the dependancy list. It would be great that we had 1 logging framework to setup (which could be used with JDK java.util.loggig or log4j) I thought I got rid of that dependency recently, no? Thanks for the feed back anyway, Trustin the HttptestCase java that if created uses the JMX classes to monitor the traffic. i use bean-utils 1.8.beta (latest release)
Re: Revisiting logging in MINA 2.0
Hello all, On Dec 13, 2007 3:50 AM, Trustin Lee [EMAIL PROTECTED] wrote: This issue is becoming a real headache even a bottle of tylenol can't fix, along with the reentrant logging issue: http://xrl.us/bctaa I think these two issues should be considered together to resolve the issues related with logging. Let me summarize current situation: 1) There are people (A) who don't want to use SLF4J but java.util.logging. 2) There are people (B) who like to use SLF4J and they say SLF4J supports java.util.logging along with log4j. 3) People A say java.util.logging can also do the same by employing a proper LogManager implementation. 4) There is a logger reentrance problem in MINA, which means it is difficult to write a MINA-based appender for the most logging frameworks that doesn't allow reentrance. This problem can be worked around by turning off logging in MINA, but this is not reasonable. about (4) : I thought the deadlock is caused by a bug in log4j (namely that it doesn't use proper synchronization) ? If that's the case I think we should not try to fix it in MINA. about (1) and (3) : I have (almost) no experience with java.util.logging but I from the info in this thread I understand that is necessary to set a system property to use a custom LogManager. This means two webapps deployed on the same tomcat instance MUST share the same LogManager ? One could argue that this is tomcat's fault, because it should have separate system properties per webapp ... Without considering the item #4, it might look like a debate about choosing the default logging framework for MINA 2. However, taking the item #4 into picture, it leads me to think we need a thin built-in layer for logging that is dedicated to MINA. Moreover, such a layer could satisfy both party (people A and B). Also, we could make the SLF4J dependency optional by making java.util.logging the default logger. This will potentially reduce the barrier of configuring SLF4J which is frequently asked. I don't understand the so-called barrier of configuring SLF4J. There is NO configuration, just using the jar of your choice. And optionally configuring the framework of your choice. And I don't understand why people have problems with a dependency on SLF4J ? I don't like the idea of a thin layer inside MINA, why would that be any better than depend on SLF4J ? Would people A find it more acceptable if the SLF4J classes where included inside the mina jar ? (this doesn't make sense to me, but then they wouldn't SEE the SLF4J dependency) SLF4J has a richer API than JUL (MDC, Marker, varargs, ...) Using java.util.logging directly in MINA means we would lose the ability to use this API. So many projects are using SLF4J, do they get the same questions ? From the poll we did in september, only one person (out of 19) was using java.util.logging. I wonder how many MINA users REALLY have a problem with SLF4J. Of course, this doesn't mean that users have to use that logging layer to log their application messages but it means only the classes under org.apache.mina should use that layer for all logging. Does my idea make sense? Or do you have any better idea? I am clearly part of people B :-) To be short, I fail to see the problem (under the assumpton that (4) is a problem in log4j not in Mina) We are all obssessed in logging right? :D I am not! :D regards, Maarten
Re: Revisiting logging in MINA 2.0
On Fri, 14 Dec 2007 19:26:13 +0100 Maarten Bosteels [EMAIL PROTECTED] wrote: about (1) and (3) : I have (almost) no experience with java.util.logging but I from the info in this thread I understand that is necessary to set a system property to use a custom LogManager. This means two webapps deployed on the same tomcat instance MUST share the same LogManager ? One could argue that this is tomcat's fault, because it should have separate system properties per webapp ... Yes, but the LogManager is the container's responsibility. It doesn't really matter that there's only one. You can still set separate handlers for each webapp if you want to. I don't understand the so-called barrier of configuring SLF4J. There is NO configuration, just using the jar of your choice. And optionally configuring the framework of your choice. And I don't understand why people have problems with a dependency on SLF4J ? The problem is not applications. The problem is other frameworks that want to use MINA as the underlying transport handler. Many of these frameworks must then depend on more than one log facade jar. I don't like the idea of a thin layer inside MINA, why would that be any better than depend on SLF4J ? Would people A find it more acceptable if the SLF4J classes where included inside the mina jar ? (this doesn't make sense to me, but then they wouldn't SEE the SLF4J dependency) Yes, that would be better - but then the slf4j classes have to be relocated under another package (perhaps something like jarjar could help with this). Otherwise other projects doing the same thing may conflict. SLF4J has a richer API than JUL (MDC, Marker, varargs, ...) Using java.util.logging directly in MINA means we would lose the ability to use this API. Using a wrapper class solves these issues. - DML
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551910
]
David M. Lloyd commented on DIRMINA-495:
It's missing the SessionCallback interface, so it won't compile.
IoConnector needs a way to store information into the IoSession before the
IoHandler gets ahold of it
-
Key: DIRMINA-495
URL: https://issues.apache.org/jira/browse/DIRMINA-495
Project: MINA
Issue Type: New Feature
Components: Core
Reporter: David M. Lloyd
Assignee: Mike Heath
Fix For: 2.0.0-M1
Attachments: DIRMINA-295-mikeheath.patch, DIRMINA-495-3.patch,
IoConnector.patch
It is often necessary to pass information into the IoHandler associated with
an IoConnector. Sometimes this information is needed even as early as
IoSession creation time. A mechanism is needed to pass information in to the
IoSession at the time you call IoConnector.connect(). Discussing this with
Mike Heath, we determined that a logical approach could be to have variants
of the connect() methods that accept information that can be attached to the
IoSession when it is created.
One option is to simply pass a Map in to the connect method. The contents of
the Map would be copied into the IoSession's attribute map after it is
constructed but before the IoHandler.sessionCreated method is created. In
addition, it seems likely that in many cases only one entry would need to be
added - in this case the user could simply do this:
ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
Another option would be to use variable argument lists to accept any number
of key-value pairs. The pairs could be represented by a class -
AttributePair for example. It could look like this:
public final class AttributePairK, V {
private final K key;
private final V value;
private AttributePair(K key, V value) { this.key = key; this.value =
value; }
public static K, V AttributePairK,V pair(K key, V value) { return
new AttributePairK, V(key, value); }
}
Then the user can use static imports to pull in the pair method. The
connect() method on IoConnector could accept a variable list of AttributePair
objects, so the user could write code like this:
ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
myValue2));
Though this approach is somewhat more complicated than just using a Map.
Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Heath updated DIRMINA-495:
---
Attachment: (was: DIRMINA-295-mikeheath.patch)
IoConnector needs a way to store information into the IoSession before the
IoHandler gets ahold of it
-
Key: DIRMINA-495
URL: https://issues.apache.org/jira/browse/DIRMINA-495
Project: MINA
Issue Type: New Feature
Components: Core
Reporter: David M. Lloyd
Assignee: Mike Heath
Fix For: 2.0.0-M1
Attachments: DIRMINA-495-3.patch, IoConnector.patch
It is often necessary to pass information into the IoHandler associated with
an IoConnector. Sometimes this information is needed even as early as
IoSession creation time. A mechanism is needed to pass information in to the
IoSession at the time you call IoConnector.connect(). Discussing this with
Mike Heath, we determined that a logical approach could be to have variants
of the connect() methods that accept information that can be attached to the
IoSession when it is created.
One option is to simply pass a Map in to the connect method. The contents of
the Map would be copied into the IoSession's attribute map after it is
constructed but before the IoHandler.sessionCreated method is created. In
addition, it seems likely that in many cases only one entry would need to be
added - in this case the user could simply do this:
ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
Another option would be to use variable argument lists to accept any number
of key-value pairs. The pairs could be represented by a class -
AttributePair for example. It could look like this:
public final class AttributePairK, V {
private final K key;
private final V value;
private AttributePair(K key, V value) { this.key = key; this.value =
value; }
public static K, V AttributePairK,V pair(K key, V value) { return
new AttributePairK, V(key, value); }
}
Then the user can use static imports to pull in the pair method. The
connect() method on IoConnector could accept a variable list of AttributePair
objects, so the user could write code like this:
ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
myValue2));
Though this approach is somewhat more complicated than just using a Map.
Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Heath updated DIRMINA-495:
---
Attachment: DIRMINA-495-mikeheath.patch
DIRMINA-495-mikheath.patch should compile this time. And it's spelled
correctly too. Any feedback is appreciated.
IoConnector needs a way to store information into the IoSession before the
IoHandler gets ahold of it
-
Key: DIRMINA-495
URL: https://issues.apache.org/jira/browse/DIRMINA-495
Project: MINA
Issue Type: New Feature
Components: Core
Reporter: David M. Lloyd
Assignee: Mike Heath
Fix For: 2.0.0-M1
Attachments: DIRMINA-495-3.patch, DIRMINA-495-mikeheath.patch,
IoConnector.patch
It is often necessary to pass information into the IoHandler associated with
an IoConnector. Sometimes this information is needed even as early as
IoSession creation time. A mechanism is needed to pass information in to the
IoSession at the time you call IoConnector.connect(). Discussing this with
Mike Heath, we determined that a logical approach could be to have variants
of the connect() methods that accept information that can be attached to the
IoSession when it is created.
One option is to simply pass a Map in to the connect method. The contents of
the Map would be copied into the IoSession's attribute map after it is
constructed but before the IoHandler.sessionCreated method is created. In
addition, it seems likely that in many cases only one entry would need to be
added - in this case the user could simply do this:
ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
Another option would be to use variable argument lists to accept any number
of key-value pairs. The pairs could be represented by a class -
AttributePair for example. It could look like this:
public final class AttributePairK, V {
private final K key;
private final V value;
private AttributePair(K key, V value) { this.key = key; this.value =
value; }
public static K, V AttributePairK,V pair(K key, V value) { return
new AttributePairK, V(key, value); }
}
Then the user can use static imports to pull in the pair method. The
connect() method on IoConnector could accept a variable list of AttributePair
objects, so the user could write code like this:
ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
myValue2));
Though this approach is somewhat more complicated than just using a Map.
Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[New Committer] Everyone let's give a warm welcome to Jeff Genender
Hi all, We have a new committer, Jeff Genender, who's a committer other projects here at the ASF and a member of the foundation as well. He's great guy and has been working on some of the http client code and is pretty excited about MINA ... let me stop putting words in his mouth though. Jeff go ahead and tell us about yourself if you have a minute. Welcome! Alex
Re: Newbie Questions
Steve Johns wrote:
Thanks for Mina. It is a great project.
After I am trying out the Mina, I had some questions.
1) If the server session.write() a message, however client network is really
SLOW. Will mina keep trying to send
out the message until timeout?(I guess session.settimeout() is applied
here). If so, how IoHandler get notified from this
event message? (Through exceptionCaught, close session?). Why NOT
accumulated writeQueue size user defined size and exception?
MINA only passes the message on to the OS once. It is the OS'
responsibility to manage TCP timeouts and resend dropped packets. If
the TCP connection timesout, an exception will be thrown and it can be
handled in IoHandler.exceptionCaught.
2) If the server wants to send the same message to all 1000 sessions, should
I encode the same message 1000 times
in the encoder extend the messageEncoder? If so, that kinda affects the
performance.
If you send the message as a Java Object, it will have to be encoded
1,000 times. If you're going to be broadcasting a message to lots of
clients, I would recommend encoding it once, and then doing something like:
for (IoSession session : allRecipients) {
session.write(myEncodedBuffer.duplicate());
}
or if you're using MINA TRUNK, you could just use IoUtil.broadcast.
3) In Mina web document, source code 1.1.x-main
the WORK class link under org.apache.mina.transport.socket.nio is wrong.
I'm sorry. I don't understand where this link problem is. Please
clarify on this.
Finally, thanks Trustin.
Yes, Trustin is my hero.
-Mike
Re: Mina 1 vs Mina 2 current
If the committers are recommending using trunk, that suggests it is time for a release. Seriously. -Brian On Dec 14, 2007, at 1:35 PM, Mike Heath wrote: mclovis wrote: mclovis wrote: We currently have NIO server code working based on our own current design. Looking at the Mina code we feel we could simplify things somewhat by switching to Mina. We are also currently in a refactoring phase. That being said it looks like you will release Mina2 -M1 soon and have promised GA by summer. In your opinion, could we refactor to Mina1 for production quality and later upgrade with some changes to Mina2 , or wait to M2. If we are going to refactor using Mina in the near future, now is the time for us. I am posting this trying gain some understanding of Mina1 to Mina2 features as well as compatibility. Any insights will be appreciated. If there are any code committers following this thread any insights from them would also be appreciated. I'm a committer on MINA and I would recommend using MINA TRUNK for new projects. There are a lot of really nice improvements to MINA TRUNK in terms of both performance and a better API. I'm using MINA TRUNK on a few projects right now. These projects are still in development so changes to MINA haven't been much of an issue. We would also like to get as much feedback before cutting a MINA 2.0 release so the more people using MINA TRUNK the better. -Mike
Re: Mina 1 vs Mina 2 current
mclovis wrote: mclovis wrote: We currently have NIO server code working based on our own current design. Looking at the Mina code we feel we could simplify things somewhat by switching to Mina. We are also currently in a refactoring phase. That being said it looks like you will release Mina2 -M1 soon and have promised GA by summer. In your opinion, could we refactor to Mina1 for production quality and later upgrade with some changes to Mina2 , or wait to M2. If we are going to refactor using Mina in the near future, now is the time for us. I am posting this trying gain some understanding of Mina1 to Mina2 features as well as compatibility. Any insights will be appreciated. If there are any code committers following this thread any insights from them would also be appreciated. I'm a committer on MINA and I would recommend using MINA TRUNK for new projects. There are a lot of really nice improvements to MINA TRUNK in terms of both performance and a better API. I'm using MINA TRUNK on a few projects right now. These projects are still in development so changes to MINA haven't been much of an issue. We would also like to get as much feedback before cutting a MINA 2.0 release so the more people using MINA TRUNK the better. -Mike
Re: [New Committer] Everyone let's give a warm welcome to Jeff Genender
Thank you and I am honored. ;-) I am a big fan of Mina and have been for quite a while and am excited to step up and help out. About me...I am a Apache junkie of sorts as I am a committer on Geronimo, OpenEJB, ServiceMix, and CXF. more or less a Java dude (Ill bet ya couldn't tell). Thanks again! Jeff Alex Karasulu wrote: Hi all, We have a new committer, Jeff Genender, who's a committer other projects here at the ASF and a member of the foundation as well. He's great guy and has been working on some of the http client code and is pretty excited about MINA ... let me stop putting words in his mouth though. Jeff go ahead and tell us about yourself if you have a minute. Welcome! Alex
Re: [New Committer] Everyone let's give a warm welcome to Jeff Genender
Jeff Genender wrote: Thank you and I am honored. ;-) Nah, we are honored to have you within us ! I am a big fan of Mina and have been for quite a while and am excited to step up and help out. About me...I am a Apache junkie of sorts as I am a committer on Geronimo, OpenEJB, ServiceMix, and CXF. more or less a Java dude (Ill bet ya couldn't tell). Oh, really ? So strange :) Btw, CXF rocks ! Thanks again! You're welcome ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Newbie Questions
On Dec 15, 2007 5:52 AM, Mike Heath [EMAIL PROTECTED] wrote:
Steve Johns wrote:
Thanks for Mina. It is a great project.
After I am trying out the Mina, I had some questions.
1) If the server session.write() a message, however client network is
really
SLOW. Will mina keep trying to send
out the message until timeout?(I guess session.settimeout() is applied
here). If so, how IoHandler get notified from this
event message? (Through exceptionCaught, close session?). Why NOT
accumulated writeQueue size user defined size and exception?
MINA only passes the message on to the OS once. It is the OS'
responsibility to manage TCP timeouts and resend dropped packets. If
the TCP connection timesout, an exception will be thrown and it can be
handled in IoHandler.exceptionCaught.
I may not make myself clear. If I send 100 bytes length of packets, however,
only 50 bytes are sent. (int sentBytes = socket.write(bytes[])). I meant if
Mina will put the left 50 bytes back to the queue and send them again?
2) If the server wants to send the same message to all 1000 sessions,
should
I encode the same message 1000 times
in the encoder extend the messageEncoder? If so, that kinda affects the
performance.
If you send the message as a Java Object, it will have to be encoded
1,000 times. If you're going to be broadcasting a message to lots of
clients, I would recommend encoding it once, and then doing something
like:
for (IoSession session : allRecipients) {
session.write(myEncodedBuffer.duplicate());
}
Which means I have to do the Encode part in the IoHandlerAdapter but NOT in
my encoder, right? That really mixes up the communication and business
logic.
or if you're using MINA TRUNK, you could just use IoUtil.broadcast.
Sounded great.
3) In Mina web document, source code 1.1.x-main
the WORK class link under org.apache.mina.transport.socket.nio is
wrong.
I'm sorry. I don't understand where this link problem is. Please
clarify on this.
Finally, thanks Trustin.
Yes, Trustin is my hero.
You are my hero, too. :)
-Mike
