Re: Send Message Failure

[Steve Johns]

On Dec 18, 2007 3:15 PM, Trustin Lee <[EMAIL PROTECTED]> wrote:

> On Dec 17, 2007 5:20 PM, Steve Johns <[EMAIL PROTECTED]> wrote:
> 
>
> > > > Can you give more hints about what the CACHE is?
> > >
> > > In you encoder, you could maintain a Map whose key is some message key
> > > and whose value is encoded ByteBuffer (or byte[]).  It could probably
> > > be a LRUMap implementation that is provided by 3rd party collections
> > > API such as Apache Commons Collections.  You could query the map if
> > > there's already an encoded form of the message, and reuse the encoded
> > > data if there's one in your encoder implementation.
> >
> > Thanks. Trustin. I totally understood. However, where I do the message -
> >
> > byte[]  part? Is that supposed to be in the Encoder? But what suggested
> > seems doing the encoding message -> byte[] part in IoHandlerAdapter or
> > Busniess logic.
>
Actually this issue bothered me for quite a while, I am working on a
financial quotation server which broadcasts the quot data to all the end
users connected. It seemed there is no choice than encoding message->byte[]
in my IoHandlerAdapter in my case. If I do encoding in this way, I don't
even need a cache and just send the byte[] to all the sessions with a LOOP(
bytebuffer.duplicat() of course). Thanks. Anyways.

>
>
> Yes, you are supposed to do that in the ProtocolEncoder.  It doesn't
> mean that you can't do that in the IoHandlerAdaptor or business logic,
> but it's not recommended in most cases.  That's why I suggested you to
> use cache in the encoder.
>
> HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>

Re: Send Message Failure

[Trustin Lee]

On Dec 17, 2007 5:20 PM, Steve Johns <[EMAIL PROTECTED]> wrote:


> > > Can you give more hints about what the CACHE is?
> >
> > In you encoder, you could maintain a Map whose key is some message key
> > and whose value is encoded ByteBuffer (or byte[]).  It could probably
> > be a LRUMap implementation that is provided by 3rd party collections
> > API such as Apache Commons Collections.  You could query the map if
> > there's already an encoded form of the message, and reuse the encoded
> > data if there's one in your encoder implementation.
>
> Thanks. Trustin. I totally understood. However, where I do the message - >
> byte[]  part? Is that supposed to be in the Encoder? But what suggested
> seems doing the encoding message -> byte[] part in IoHandlerAdapter or
> Busniess logic.

Yes, you are supposed to do that in the ProtocolEncoder.  It doesn't
mean that you can't do that in the IoHandlerAdaptor or business logic,
but it's not recommended in most cases.  That's why I suggested you to
use cache in the encoder.

HTH,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: WriteFuture.join() hangs when called in IoHandler.sessionOpened() in Datagram transport.

[Trustin Lee]

Hi Qi,

It's not a bug but a kind of dead lock caused by misuse of the API.

You are usually not supposed to call IoFuture.join() within an
IoHandler because the IoHandler methods might be being executed in the
same thread with the I/O processor thread.  You wrote something and
you call join() to wait for the I/O processor thread to finish the
write operation in the I/O processor thread, then join() won't return
at all.  MINA 2 detects this kind of situation automatically and emits
advisory exception, but it's not in MINA 1.x unfortunately.

The alternative to join() is adding an IoFutureListener.

HTH,
Trustin

On Dec 17, 2007 4:48 PM, Qi <[EMAIL PROTECTED]> wrote:
>
> Hi there,
>
> I've just found a possible bug in MINA Datagram transport.
>
> In my handler class, I was trying to write some messages once the
> sessionOpened event is fired, while the program will hang if I get the
> writeFuture and call join() on it.
> If I call join with a timeout parameter, after the operation gets timeout,
> WriteFuture.isWritten returns false.
> (Same senario would go through if it's via SocketConnector transport, as
> showing in the sumup example.)
>
>
> However, if I don't place the write operation inside sessionOpened();
> instead, I placed they after DatagramConnector.connect(), then writes will
> successfully go though.
>
> I'm using MINA 1.1.5 and JRE 1.6.
>
> Source code that demostrate the problem is attached.
> http://www.nabble.com/file/p14370126/BroadcastSender.java
> BroadcastSender.java
> --
> View this message in context: 
> http://www.nabble.com/WriteFuture.join%28%29-hangs-when-called-in-IoHandler.sessionOpened%28%29-in-Datagram-transport.-tp14370126s16868p14370126.html
> Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
>
>



-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Revisiting logging in MINA 2.0

[Alex Karasulu]

On Dec 17, 2007 11:13 PM, Trustin Lee <[EMAIL PROTECTED]> wrote:

> On Dec 18, 2007 3:40 AM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
> > On Dec 17, 2007 11:29 AM, Maarten Bosteels <[EMAIL PROTECTED]>
> wrote:
> > > IMO, that is a rather weak argument for resorting to our own "thin
> > > layer for logging".
> >
> > Yes I agree completely.  It's unnecessary to add yet another logging
> layer.
> >
> > I know several JBoss people are resentful with having to use SLF4J while
> now
> > using MINA but there is no reason why we should push forward with that.
>
> You understood plain wrong.  It's not about JBoss people but about any
> possible users who want to build their own framework on top of MINA.
> Do you think I am pushing this because I am working for JBoss?  Never.


No I am not saying you are "pushing this because [you are] working for
JBoss".  You have jumped to the wrong conclusion. Let me tell you what I
know about the present situation and what I am thinking or fearing:

(1) I am aware of a few things regarding JBoss:
(a) I know David Lloyd is a JBoss employee.   Yes the other guy with
your same opinion.
(b) I know you, Trustin, are a JBoss employee.
(c) I know that you guys interact outside of this list through office
channels.
(d) I have friends at JBoss who have asked several times before JBoss
hired you if I can work on you to drop SLF4J. They should know no one can
work on  you :).  I refused to do that since they can make their points
themselves on the list directly with you.

NOTE: I've always liked people in both JBoss and Geronimo communities.
Because of these relations and my association with both Apache and JBoss I
have always remained neutral and unbiased to both.  That will always remain
the case.

(2) I know you and David are the minority pushing for the same logging API
in MINA.  Just look at the email trail [0]. There are many more who are
opposed to this idea.

(3) You pushed this same agenda in the past before you were a JBoss employee
[1].  (How can I suggest JBoss is making you do this?)

(4) I won't go into detail to keep some things private but I know you wanted
to find this thread [1] because it was one which you suspected was a veto
against you.  You explicitly searched for and found this thread after some
recent events.

(5) I know you mean the best for MINA since it is somewhat a source of
recognition for you (and there is nothing wrong with that since you should
benefit from your hard effort on MINA). Also you may change employers but
will always keep your association with MINA.


So because of #3 specifically, (and #5) I am aware that you're not doing
this because of JBoss pressure.  That's not the main point I was trying to
make.  I know you genuinely think this is the best for MINA. I know of
others besides you employed by JBoss and these were the people I was
referring too.  These were the people in #1 (d).  You incorrectly presumed I
was referring to you.

However, regarding this thread coming back to life, it occurred right after
you explicitly searched for it.  You wanted to bring it up again, primarily
because it was an outstanding issue that you felt was legitimate.  Most
importantly, it did not unfold in the manner you wanted it to be addressed.
This is all fine, but I'm wondering why David kicked it off and joined in.
I'm not suggesting we have a "follow the leader" situation but the
possibility is starting to occur regularly in my head.  This is happening
because I fear having the merits of my points undermined by back channel
coordination.  Again I am not accusing you of it.  I am stating it as a
concern and something that my reasoning points to as a possibility.

Thankfully, the majority, of individuals on thread [0], naturally opposed
the emergence of yet another logging API.  If they did not, then my voice or
any other opposing voice, would be drowned out. As a well respected and
empowered member of this community, you should try to prevent your over
whelming stature from drowning out fainter voices of reason.  Sometimes
there is no absolute right or wrong decision and it's a trade off.  So, when
you possess so much influence, the responsible thing to do is to look out
for those that have less influence but are trying to make a point for the
benefit of the project.

The majority has expressed it's disinterest with this idea and sometimes you
need to yield to the community over your own beliefs of what is the best
route.  Let the community find out for itself if it is wrong. Besides, they
got your message.  They already have the information for your approach
imprinted twice now in the archives.  If the rest of us is wrong we can
revisit the topic.  It's fair to say, the majority is still not interested
in pursuing yet another logging API to be maintained by MINA.  So can we
drop this, please?

Alex

-
[0] - http://mina.markmail.org/search/?q=Revisiting+logging+in+MINA+2.0
[1] - http://mina.markmail.org/search/?q=Is+

Re: Revisiting logging in MINA 2.0

[Alex Karasulu]

Trustin,

If MINA uses it's own logging, and logs critical related messages on a
separate channel, then an application written with MINA yet using another
framework will channel log messages to potentially different targets.

Sometimes you just don't get the best of both worlds.  There are trade
offs.  This is clearly one of those.  Here we just have to pick one logging
framework and stick to it.  Several people have objected to this repeatedly
and you keep bringing it up in short intervals.  Let's just give it a year
and come back to consider it again.  Sometimes it's about timing right?

Alex

On Dec 17, 2007 11:13 PM, Trustin Lee <[EMAIL PROTECTED]> wrote:

> On Dec 18, 2007 3:40 AM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
> > On Dec 17, 2007 11:29 AM, Maarten Bosteels <[EMAIL PROTECTED]>
> wrote:
> > > On Dec 17, 2007 6:25 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> > ...
> > > We can ask Log4J team to fix this issue and it will be fixed, but,
> > > > again, considering that people wants to use the older version of
> Log4J
> > > > or doesn't want to upgrade the Log4J due to some reason (e.g. custom
> > > > patch) won't see this problem resolved in Log4J.
> > > > And.. that's why I am suggesting a thin layer for logging.
> > >
> > > Suppose that the log4j team fixes this issue in their next release,
> > > then the only people who would need this thin layer
> > > are people who
> > > a) want to use a MINA based appender (which is not yet part of
> > > standard log4j as far as I know)
> > > b) AND don't want to upgrade to a newer log4j version
> > >
> > > IMO, that is a rather weak argument for resorting to our own "thin
> > > layer for logging".
> >
> > Yes I agree completely.  It's unnecessary to add yet another logging
> layer.
> >
> > I know several JBoss people are resentful with having to use SLF4J while
> now
> > using MINA but there is no reason why we should push forward with that.
>
> You understood plain wrong.  It's not about JBoss people but about any
> possible users who want to build their own framework on top of MINA.
> Do you think I am pushing this because I am working for JBoss?  Never.
>  I got this kind of request more than 10 times in my previous company.
>  What does that mean?  There are much more people than you expect who
> care about the number of JARs and complication related with using many
> logging frameworks at the same time.
>
> > Why not just work with Ceki or see if you can get karma on that project
> to
> > fix these problems and/or facilitate the advance of a release with the
> fix?
> > Ceki, I am sure would appreciate that.  Plus the work you do there can
> > benefit other projects using this framework.  I have CC'd Ceki to get
> his
> > attention so we can do something sane about this.
>
> SLF4J cannot help this problem because SLF4J itself doesn't have any
> problem.
>
> > ...
> >
> > > Our application depends on JCL (because of spring,) and on SLF4J
> > > (because of MINA) and we let both facades point to log4j.
> > > Works pefectly. Really, I do not see the problem.
> >
> > There are many people in this situation.  Adding yet another framework
> > whether mini or not is going to add to the confusion.
>
> It's also often true that people get confused with configuring SLF4J.
> Yeah, it's brain-dead easy once understood, but it adds a lot of
> confusion to novice.  Anyways, we have the dedicated page for logging
> configuration so 'the confusion' you are referring to is not a problem
> at all.  As you already know, it's just adding one line of code to
> switch the preferred logging framework from users' point of view and I
> don't think that's really a big burden comparing to adding two JARs in
> the classpath.
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>

[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it

[Trustin Lee (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552622
 ] 

Trustin Lee commented on DIRMINA-495:
-

I have renamed its method from initSession to initializeSession, which looks 
more beautiful (just kidding :).  I'd like to avoid shorten words whenever 
possible.

> 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 AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value = 
> value; }
>public static  AttributePair pair(K key, V value) { return 
> new AttributePair(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

[Trustin Lee]

On Dec 18, 2007 3:40 AM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
> On Dec 17, 2007 11:29 AM, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> > On Dec 17, 2007 6:25 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> ...
> > We can ask Log4J team to fix this issue and it will be fixed, but,
> > > again, considering that people wants to use the older version of Log4J
> > > or doesn't want to upgrade the Log4J due to some reason (e.g. custom
> > > patch) won't see this problem resolved in Log4J.
> > > And.. that's why I am suggesting a thin layer for logging.
> >
> > Suppose that the log4j team fixes this issue in their next release,
> > then the only people who would need this thin layer
> > are people who
> > a) want to use a MINA based appender (which is not yet part of
> > standard log4j as far as I know)
> > b) AND don't want to upgrade to a newer log4j version
> >
> > IMO, that is a rather weak argument for resorting to our own "thin
> > layer for logging".
>
> Yes I agree completely.  It's unnecessary to add yet another logging layer.
>
> I know several JBoss people are resentful with having to use SLF4J while now
> using MINA but there is no reason why we should push forward with that.

You understood plain wrong.  It's not about JBoss people but about any
possible users who want to build their own framework on top of MINA.
Do you think I am pushing this because I am working for JBoss?  Never.
 I got this kind of request more than 10 times in my previous company.
 What does that mean?  There are much more people than you expect who
care about the number of JARs and complication related with using many
logging frameworks at the same time.

> Why not just work with Ceki or see if you can get karma on that project to
> fix these problems and/or facilitate the advance of a release with the fix?
> Ceki, I am sure would appreciate that.  Plus the work you do there can
> benefit other projects using this framework.  I have CC'd Ceki to get his
> attention so we can do something sane about this.

SLF4J cannot help this problem because SLF4J itself doesn't have any problem.

> ...
>
> > Our application depends on JCL (because of spring,) and on SLF4J
> > (because of MINA) and we let both facades point to log4j.
> > Works pefectly. Really, I do not see the problem.
>
> There are many people in this situation.  Adding yet another framework
> whether mini or not is going to add to the confusion.

It's also often true that people get confused with configuring SLF4J.
Yeah, it's brain-dead easy once understood, but it adds a lot of
confusion to novice.  Anyways, we have the dedicated page for logging
configuration so 'the confusion' you are referring to is not a problem
at all.  As you already know, it's just adding one line of code to
switch the preferred logging framework from users' point of view and I
don't think that's really a big burden comparing to adding two JARs in
the classpath.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Revisiting logging in MINA 2.0

[Trustin Lee]

On Dec 18, 2007 3:34 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> Trustin Lee wrote:
> > 
>
> > 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.
> Please, don't ! This is MINA, a Network framework, not a Logger
> framework ! We already have so many meta-meta-meta-loger around there:)

Yeah, it's a framework and I don't want it to force others to use the
logging framework of our preference.  Why should we do that?  Because
we are satisfied with SLF4J?  Yes I am, but it simply doesn't make any
sense to other people.

As David said, what would people think if he or she has mina-core.jar,
slf4j-log4j12.jar, log4j.jar and commons-logging.jar?

Moreover, what I am suggesting is not about embeding another logging
framework but adding a few logger classes, which is minimal, and it
will not be used anywhere outside of MINA code itself.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

[jira] Resolved: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it

[Mike Heath (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Heath resolved DIRMINA-495.


Resolution: Fixed

I went with the name IoSessionInitializer for the callback interface.  This 
code has been committed.  David, please review the fix and close the issue when 
you've verified that it works.

> 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 AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value = 
> value; }
>public static  AttributePair pair(K key, V value) { return 
> new AttributePair(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

[Emmanuel Lecharny]

David M. Lloyd wrote:

My point is, as a framework, MINA should work to avoid imposing this
preference upon the consumer of the framework.  That's just "friendly"
programming practice: make as few assumptions as possible about the
user's environment, and impose as few constraints as possible.
  
What about completly remove logs from MINA? Anyway, logs are for dummies 
: real programmer not only don't eat quiches, but also don't need logs 
because their code is bulletproof.


As Marteen perfectly said : live with it. I assure you that it worth the 
try. I think almost all of the Apache projects are using more than one 
framework and more than one logger, without any kind of problem for 
their users (thanks to the committers who do their best to make this 
work for users)




So, you would be better off trying to convince the teams of these
non-ASF projects to switch their logging framework ?



To SLF4J?  I'm not as optimistic about my chances to get a non-ASF
project to use an ASF logging framework, as I am that I can convince an
ASF project to make their logging optional.
  
I think that the vast majority of the projects is using log4j right now, 
then common-logging might be second, and at the end of the feed chain, 
you have slf4j and JCL. I personnaly have worked on a couple of projects 
those last 10 years, none of them were using JCL. And I find slf4j a 
convenient way to solve a lot of class-loader issues. We are using it in 
ADS, and we are quite pleased with it.


Bringing peace in the middle-east is probably easier than convincing 
someone to switch from his favorite logger to another one...



--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Revisiting logging in MINA 2.0

[Ceki Gulcu]

Hi Alex,

In reference to the MINA-based appender re-entrance problem as described in 
http://xrl.us/bctaa , I would suggest that logging from the  I/O processor 
thread be disabled.


As for JBoss, did you know that Hibernate 3.0, the next version of Hibernate, 
relies on SLF4J for its logging?


Moreover, Spring-OSGI which presumably lays the foundations of the next 
generation of Spring also relies on SLF4J?


I am not sure if this helps, but that's the best I can do in a few minutes. :-)

Alex Karasulu wrote:
Sorry forgot to CC Ceki after mentioning it.  Ceki could you take a 
minute to help us resolve these issues which are pushing towards the 
emergence of yet another logging framework now inside MINA.  I think 
much of this is a result of the JBoss push to do away with SLF4J 
dependencies.


Alex

On Dec 17, 2007 1:40 PM, Alex Karasulu <[EMAIL PROTECTED] 
> wrote:


On Dec 17, 2007 11:29 AM, Maarten Bosteels <[EMAIL PROTECTED]
> wrote:


On Dec 17, 2007 6:25 AM, Trustin Lee <[EMAIL PROTECTED]
> wrote:


...

 > We can ask Log4J team to fix this issue and it will be fixed,
but,
 > again, considering that people wants to use the older version
of Log4J
 > or doesn't want to upgrade the Log4J due to some reason (
e.g. custom
 > patch) won't see this problem resolved in Log4J.
 > And.. that's why I am suggesting a thin layer for logging.

Suppose that the log4j team fixes this issue in their next release,
then the only people who would need this thin layer
are people who
a) want to use a MINA based appender (which is not yet part of
standard log4j as far as I know)
b) AND don't want to upgrade to a newer log4j version

IMO, that is a rather weak argument for resorting to our own "thin
layer for logging".


Yes I agree completely.  It's unnecessary to add yet another logging
layer. 


I know several JBoss people are resentful with having to use SLF4J
while now using MINA but there is no reason why we should push
forward with that.

Why not just work with Ceki or see if you can get karma on that
project to fix these problems and/or facilitate the advance of a
release with the fix?  Ceki, I am sure would appreciate that.  Plus
the work you do there can benefit other projects using this
framework.  I have CC'd Ceki to get his attention so we can do
something sane about this.

...


Our application depends on JCL (because of spring,) and on SLF4J
(because of MINA) and we let both facades point to log4j.
Works pefectly. Really, I do not see the problem.


There are many people in this situation.  Adding yet another
framework whether mini or not is going to add to the confusion.
 



Of course, I would prefer it if we would only need SLF4J, but
that's a
problem that MINA can not solve.
I am afraid that a thin layer in MINA will just make things more
complex.


Absolutely!

Alex




--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

Re: Short question on statistics in Mina

[Frédéric Brégier]

Hi Trustin,

I double check and I don't see why I still have 0 value 
for ReadMessages and ReadMessagesThroughput in IoHandler,
while ReadBytes and ReadBytesThroughput are non zero
in the same time.
I have written an extension in my business logic to count
myself current Messages each 3 seconds interval (same as in Mina)
and I got numbers obviously different than 0.
I check both on AIX and on Windows, and the behavious
is the same.

Once say that, I totally agree with you if this is not on the
prioritary list since obviously it is not blocking at all
and it is just a "cosmetic" information... ;-)
I will continue to try to understand why...

And WDYT about my proposal of extension (again "cosmetic" only
so if you fill like it is not useful, no problem) ?

Frederic

- Original Message - 
Well, I come back with a proposal of addition in IoHandler.
Doing this will prevent me to use a specific Timer to do the same.
The objective are to get some statistics value on long term,
whatever the sessions are still running or not.
I think that only throughput are relevant, since others could be problematic
(risk of overflow) and could be not so relevant in general way.
Here is the proposal :

//NEW FIELDS
private double largestReadBytesThroughput = 0.0;
private double largestWrittenBytesThroughput = 0.0;
private double largestReadMessagesThroughput = 0.0;
private double largestWrittenMessagesThroughput = 0.0;
 
private void updateThroughput(long currentTime) {
synchronized (throughputCalculationLock) {
int interval = (int) (currentTime - lastThroughputCalculationTime);
long minInterval = getThroughputCalculationIntervalInMillis();
if (minInterval == 0 || interval < minInterval) {
return;
}

long readBytes = this.readBytes.get();
long writtenBytes = this.writtenBytes.get();
long readMessages = this.readMessages.get();
long writtenMessages = this.writtenMessages.get();

readBytesThroughput = (readBytes - lastReadBytes) * 1000.0 / 
interval;
writtenBytesThroughput = (writtenBytes - lastWrittenBytes) * 1000.0 
/ interval;
readMessagesThroughput = (readMessages - lastReadMessages) * 1000.0 
/ interval;
writtenMessagesThroughput = (writtenMessages - lastWrittenMessages) 
* 1000.0 / interval;

// NEW FIELDS FOR LARGEST VALUES WHATEVER THE LIFE OF SESSIONS
if (readBytesThroughput > largestReadBytesThroughput)
largestReadBytesThroughput = readBytesThroughput;
   if (writtenBytesThroughput > largestWrittenBytesThroughput)
largestWrittenBytesThroughput = writtenBytesThroughput;
   if (readMessagesThroughput > largestReadMessagesThroughput)
largestReadMessagesThroughput = readMessagesThroughput;
   if (writtenMessagesThroughput > largestWrittenMessagesThroughput)
largestWrittenMessagesThroughput = writtenMessagesThroughput;
// END OF ADDON

lastReadBytes = readBytes;
lastWrittenBytes = writtenBytes;
lastReadMessages = readMessages;
lastWrittenMessages = writtenMessages;

lastThroughputCalculationTime = currentTime;
}
}
// NEW METHODS
public final double getLargestReadBytesThroughput() {
return largestReadBytesThroughput;
}
public final double getLargestWrittenBytesThroughput() {
return largestWrittenBytesThroughput;
}
public final double getLargestReadMessagesThroughput() {
return largestReadMessagesThroughput;
}
public final double getLargestWrittenMessagesThroughput() {
return largestWrittenMessagesThroughput;
}
Could it be something added to Mina ?

Also I really don't know why Read Messages (max throughput or cumulative)
are still 0 in my code, but should not be since bytes are not null as below.
Is this relative to the use of DemuxingIoHandler ? WDYT ?
I look at the code and see nothing particular that should produce this 
behaviour.

Active since: Wed Dec 12 17:23:57 CET 2007
Cumulative Sessions: 106
Maximum Concurrent Sessions: 106
Current Active Sessions: 106
Bytes read by Second: 113200.9900990099
Messages read by Second: 0.0
Cumulative Read Messages: 0
Bytes written by Second: 5700083.168316832
Messages written by Second: 1079.8679867986798
Cumulative Written Messages: 51780

Frederic

Re: MINA 2 migration guide

[Frédéric Brégier]

I think you've got the list.
I would suggest you to look at some mails I wrote under subject
http://www.nabble.com/-jira--Created-3A--28DIRMINA-477-29-Update-page-about-differences-between-1.x-and-2.x-to13740995s16868.html
specially those using "Update page about differences between 1.x and 2.x" as 
title
(I probably made something wrong for other messages that are in the same thread 
but shouldn't).
I mainly quote change from "past" version of trunk to new one, but already see 
some
changes to do in the corresponding web page. As my "past" trunk version was not 
so far
from 1.x version, some hint can be taken again for 1.x to 2.x.

Also I write in these thread an example of init a server using 
DemuxingIoHandler, but that
can easily adapted to standard IoHandler (using the correction of Trustin since 
I was
missing acceptor.dispose() ) and the same the client part.

If needed, I can help on those guide. Just let me know what...

Frederic
- Original Message - 
From: "Mark"
Subject: MINA 2 migration guide


I have volunteered to lead an effort to put together a migration guide that
shows how to 'port' a MINA 1.x based program to a MINA 2.x based program.
Here are some thoughts I have:

1. Provide some programs written using MINA 1.x and the changes that are
required to use 2.x.
2. List the bugs/features that have been closed as a result of 2.xdevelopment.
3. List the changes to the API, and the locations of the submodules/classes.

Let me know if there are other ideas people have for this.

Thanks
Mark


-- 

The adjuration to be "normal" seems shockingly repellent to me; I see
neither hope nor comfort in sinking to that low level. I think it is
ignorance that makes people think of abnormality only with horror and allows
them to remain undismayed at the proximity of "normal" to average and
mediocre. For surely anyone who achieves anything is, essentially, abnormal.
Dr. Karl Menninger

Re: Revisiting logging in MINA 2.0

[David M. Lloyd]

On Mon, 17 Dec 2007 20:11:20 +0100
"Maarten Bosteels" <[EMAIL PROTECTED]> wrote:

> Hi David,
> 
> > Some people have feelings stronger than preference about it.  Also keep
> > in mind: you've got an application.  You are not developing a framework.
> >
> > How would you feel about things if MINA required slf4j AND jcl AND
> > log4j?  That would seem excessive, would it not?  It might even affect
> > one's willingness to use the framework.
> 
> Suppose I am developing framework X that depends on projectA, projectB
> and projectC
> and suppose also that
> * projectA requires SLF4J
> * projectB requires JCL
> * projectC requires log4j
> 
> Then I would take these steps to try to improve the situation:
> (1) try (hard) to convince the projectC team to switch to SLF4J
> (2) when (1) fails: search an alternative for projectC
> (3) try (probably less hard) to convince the projectB team to use
> SLF4J instead of JCL
> (4) if (3) fails, explain to the users of X why they need both jcl and
> SLF4J on their classpath
> (5) live with it.

My point is, as a framework, MINA should work to avoid imposing this
preference upon the consumer of the framework.  That's just "friendly"
programming practice: make as few assumptions as possible about the
user's environment, and impose as few constraints as possible.

> So, you would be better off trying to convince the teams of these
> non-ASF projects to switch their logging framework ?

To SLF4J?  I'm not as optimistic about my chances to get a non-ASF
project to use an ASF logging framework, as I am that I can convince an
ASF project to make their logging optional.

> > Therefore I am making an effort to convince the author(s) of these
> > frameworks upon which my project relies, to consider making logging
> > either configurable with no dependencies, or optional altogether.
> > Using JDK logging seems like a reasonable compromise.
> 
> IMO, SLF4J makes logging configurable AND optional (using slf4j-nop.jar).

So you need two jars in order to... do nothing.  Since logging is
already mostly centralized in MINA, why not just have a simple switch
of some sort?  Even a static method that says "turn off logging" would
be better than the current situation.  Though e.g. a setter on
IoAcceptor and IoConnector (for example) would be ideal (as this also
might address the reentrancy problem that Trustin brought up).

- DML

Re: HttpResponseEncoder and streaming data

[Bogdan Ciprian Pistol]

Hi Trustin,

> We could make our current class hierarchy more granular like the following:
>
> * HttpMessage
> ** HttpRequest - no getContent()
> *** MergedHttpRequest - getContent() here
> *** ChunkedHttpRequest - once written, encoder expects HttpChunks,
> other HttpRequest or disconnection.
> ** HttpResponse - no getContent()
> *** MergedHttpResponse - getContent() here
> *** ChunkedHttpResponse - once written, encoder expects HttpChunks,
> other HttpResponse or disconnection.
> * HttpChunk - getContent() here

Looks great.

Why is MergedHttpRequest needed? If someone wants to write a chunked
message he writes some ChunkedHttpRequests messages.

MergedHttpResponse could be returned as a normal HTTP message with
getContent( ).
If the application is interested about the merged HTTP chunks then it
is interested about the hole message so it could receive the message
as a standard HTTP message (from de decoder).
The application will not care if it's merged HTTP or standard HTTP in
this case, IMO.

I like the idea to first send ChunkedHttpResponse and subsequent
chunks as HttpChunks, (in my decoder I used only one class).

Bogdan

Re: Revisiting logging in MINA 2.0

[Maarten Bosteels]

Hi David,

On Dec 17, 2007 5:46 PM, David M. Lloyd <[EMAIL PROTECTED]> wrote:
> On Mon, 17 Dec 2007 17:29:24 +0100 "Maarten Bosteels"
> <[EMAIL PROTECTED]> wrote:
>
> > I agree, there are currently two logging facades that are widely used
> > by frameworks/libraries: jakarta-commons-logging (JCL) and SLF4J.
> > The consequence is that for any project with dependencies, there is a
> > reasonable chance that both logging facades need to be on the
> > classpath. But is that a problem ?
> >
> > Our application depends on JCL (because of spring,) and on SLF4J
>   ^^^
> > (because of MINA) and we let both facades point to log4j.
> > Works pefectly. Really, I do not see the problem.
> >
> > Of course, I would prefer it if we would only need SLF4J, but that's a
> > problem that MINA can not solve.
>
> Some people have feelings stronger than preference about it.  Also keep
> in mind: you've got an application.  You are not developing a framework.
>
> How would you feel about things if MINA required slf4j AND jcl AND
> log4j?  That would seem excessive, would it not?  It might even affect
> one's willingness to use the framework.

Suppose I am developing framework X that depends on projectA, projectB
and projectC
and suppose also that
* projectA requires SLF4J
* projectB requires JCL
* projectC requires log4j

Then I would take these steps to try to improve the situation:
(1) try (hard) to convince the projectC team to switch to SLF4J
(2) when (1) fails: search an alternative for projectC
(3) try (probably less hard) to convince the projectB team to use
SLF4J instead of JCL
(4) if (3) fails, explain to the users of X why they need both jcl and
SLF4J on their classpath
(5) live with it.

> This is the situation that I (and others with whom I work) face
> currently.  As a framework developer, I would not care if there was
> only one logging dependency - but the other libraries that my project
> depends on all use different logging frameworks.  This especially
> becomes an issue if you consider the wider world of software (beyond
> ASF projects).  Though most ASF projects use slf4j or jcl, this is not
> true in general terms.

So, you would be better off trying to convince the teams of these
non-ASF projects to switch their logging framework ?

>
> Therefore I am making an effort to convince the author(s) of these
> frameworks upon which my project relies, to consider making logging
> either configurable with no dependencies, or optional altogether.
> Using JDK logging seems like a reasonable compromise.

IMO, SLF4J makes logging configurable AND optional (using slf4j-nop.jar).

regards,
Maarten

Re: Revisiting logging in MINA 2.0

[Alex Karasulu]

Sorry forgot to CC Ceki after mentioning it.  Ceki could you take a minute
to help us resolve these issues which are pushing towards the emergence of
yet another logging framework now inside MINA.  I think much of this is a
result of the JBoss push to do away with SLF4J dependencies.

Alex

On Dec 17, 2007 1:40 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote:

> On Dec 17, 2007 11:29 AM, Maarten Bosteels <[EMAIL PROTECTED]>
> wrote:
>
> >
> > On Dec 17, 2007 6:25 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> >
>
> ...
>
> > We can ask Log4J team to fix this issue and it will be fixed, but,
> > > again, considering that people wants to use the older version of Log4J
> > > or doesn't want to upgrade the Log4J due to some reason ( e.g. custom
> > > patch) won't see this problem resolved in Log4J.
> > > And.. that's why I am suggesting a thin layer for logging.
> >
> > Suppose that the log4j team fixes this issue in their next release,
> > then the only people who would need this thin layer
> > are people who
> > a) want to use a MINA based appender (which is not yet part of
> > standard log4j as far as I know)
> > b) AND don't want to upgrade to a newer log4j version
> >
> > IMO, that is a rather weak argument for resorting to our own "thin
> > layer for logging".
> >
>
> Yes I agree completely.  It's unnecessary to add yet another logging
> layer.
>
> I know several JBoss people are resentful with having to use SLF4J while
> now using MINA but there is no reason why we should push forward with that.
>
> Why not just work with Ceki or see if you can get karma on that project to
> fix these problems and/or facilitate the advance of a release with the fix?
> Ceki, I am sure would appreciate that.  Plus the work you do there can
> benefit other projects using this framework.  I have CC'd Ceki to get his
> attention so we can do something sane about this.
>
> ...
>
>
> > Our application depends on JCL (because of spring,) and on SLF4J
> > (because of MINA) and we let both facades point to log4j.
> > Works pefectly. Really, I do not see the problem.
> >
>
> There are many people in this situation.  Adding yet another framework
> whether mini or not is going to add to the confusion.
>
>
> >
> > Of course, I would prefer it if we would only need SLF4J, but that's a
> > problem that MINA can not solve.
> > I am afraid that a thin layer in MINA will just make things more
> > complex.
> >
>
> Absolutely!
>
> Alex
>
>

Re: Revisiting logging in MINA 2.0

[Alex Karasulu]

On Dec 17, 2007 11:29 AM, Maarten Bosteels <[EMAIL PROTECTED]> wrote:

>
> On Dec 17, 2007 6:25 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
>

...

> We can ask Log4J team to fix this issue and it will be fixed, but,
> > again, considering that people wants to use the older version of Log4J
> > or doesn't want to upgrade the Log4J due to some reason (e.g. custom
> > patch) won't see this problem resolved in Log4J.
> > And.. that's why I am suggesting a thin layer for logging.
>
> Suppose that the log4j team fixes this issue in their next release,
> then the only people who would need this thin layer
> are people who
> a) want to use a MINA based appender (which is not yet part of
> standard log4j as far as I know)
> b) AND don't want to upgrade to a newer log4j version
>
> IMO, that is a rather weak argument for resorting to our own "thin
> layer for logging".
>

Yes I agree completely.  It's unnecessary to add yet another logging layer.


I know several JBoss people are resentful with having to use SLF4J while now
using MINA but there is no reason why we should push forward with that.

Why not just work with Ceki or see if you can get karma on that project to
fix these problems and/or facilitate the advance of a release with the fix?
Ceki, I am sure would appreciate that.  Plus the work you do there can
benefit other projects using this framework.  I have CC'd Ceki to get his
attention so we can do something sane about this.

...


> Our application depends on JCL (because of spring,) and on SLF4J
> (because of MINA) and we let both facades point to log4j.
> Works pefectly. Really, I do not see the problem.
>

There are many people in this situation.  Adding yet another framework
whether mini or not is going to add to the confusion.


>
> Of course, I would prefer it if we would only need SLF4J, but that's a
> problem that MINA can not solve.
> I am afraid that a thin layer in MINA will just make things more complex.
>

Absolutely!

Alex

Re: Revisiting logging in MINA 2.0

[Emmanuel Lecharny]

Trustin Lee wrote:





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.  
Please, don't ! This is MINA, a Network framework, not a Logger 
framework ! We already have so many meta-meta-meta-loger around there:)

Cheers,
Trustin
  



--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Revisiting logging in MINA 2.0

[Raman Gupta]

David M. Lloyd wrote:
> How would you feel about things if MINA required slf4j AND jcl AND
> log4j?  That would seem excessive, would it not?  It might even affect
> one's willingness to use the framework.
> 
> This is the situation that I (and others with whom I work) face
> currently.  As a framework developer, I would not care if there was
> only one logging dependency - but the other libraries that my project
> depends on all use different logging frameworks.  This especially
> becomes an issue if you consider the wider world of software (beyond
> ASF projects).  Though most ASF projects use slf4j or jcl, this is not
> true in general terms.
> 
> Therefore I am making an effort to convince the author(s) of these
> frameworks upon which my project relies, to consider making logging
> either configurable with no dependencies, or optional altogether.
> Using JDK logging seems like a reasonable compromise.

Many (most) of us don't want to introduce JDK logging into our
projects. We are very happy with logging to our framework of choice
via slf4j. I believe you've said before that JDK logging can easily be
redirected to slf4j (just like it is redirect jcl to slf4j). If that
really is the case, then I think it would make sense to switch Mina to
JDK logging, since everyone can then log from Mina to wherever they
want, without any complexity within Mina, or external dependencies.

However, I haven't seen any code anywhere to actually do this --
perhaps you'd like to reference something that does this, or explain
to the list how this could be done, or code it yourself if its not
currently available? That would go a long way to "convincing"
frameworks to switch to a logging system that few people actually use.

Keep in mind this "solution" should take into account esoteric
classloader situations (such as within application servers or OSGi
runtimes). If it can be done, I think it would actually be a very
useful and widely used component -- I know there are some other
libraries I use that use JDK logging that I would love to redirect to
log4j so I can manage all my logging from one place.

Cheers,
Raman Gupta

Problem with http chucked body decoder

[Matteo Merli]

Hi,

I've found a problem in the HTTP codec because some server incorrectly
send the chunk length.

These servers send the length follwed by some spaces, before the CRLF
terminator.

Example: http://del.icio.us/

The following patch fixed the problem for me:

Index: 
filter-codec-http/src/main/java/org/apache/mina/filter/codec/http/ChunkedBodyDecodingState.java
===
--- 
filter-codec-http/src/main/java/org/apache/mina/filter/codec/http/ChunkedBodyDecodingState.java
(revision 604818)
+++ 
filter-codec-http/src/main/java/org/apache/mina/filter/codec/http/ChunkedBodyDecodingState.java
(working copy)
@@ -107,8 +107,8 @@
 protected boolean isTerminator(byte b) {
 if (!(b >= '0' && b <= '9' || b >= 'a' && b <= 'f' || b >= 'A'
 && b <= 'F')) {
-if (b == '\r' || b == ';') {
-chunkHasExtension = b == ';';
+if (b == ' ' || b == '\r' || b == ';') {
+chunkHasExtension = (b == ';' || b == ' ');
 return true;
 }
 throw new IllegalArgumentException();


Best regards,
Matteo

-- 
Matteo Merli
<[EMAIL PROTECTED]>

Re: Revisiting logging in MINA 2.0

[David M. Lloyd]

On Mon, 17 Dec 2007 17:29:24 +0100 "Maarten Bosteels"
<[EMAIL PROTECTED]> wrote:

> I agree, there are currently two logging facades that are widely used
> by frameworks/libraries: jakarta-commons-logging (JCL) and SLF4J.
> The consequence is that for any project with dependencies, there is a
> reasonable chance that both logging facades need to be on the
> classpath. But is that a problem ?
> 
> Our application depends on JCL (because of spring,) and on SLF4J
  ^^^
> (because of MINA) and we let both facades point to log4j.
> Works pefectly. Really, I do not see the problem.
> 
> Of course, I would prefer it if we would only need SLF4J, but that's a
> problem that MINA can not solve.

Some people have feelings stronger than preference about it.  Also keep
in mind: you've got an application.  You are not developing a framework.

How would you feel about things if MINA required slf4j AND jcl AND
log4j?  That would seem excessive, would it not?  It might even affect
one's willingness to use the framework.

This is the situation that I (and others with whom I work) face
currently.  As a framework developer, I would not care if there was
only one logging dependency - but the other libraries that my project
depends on all use different logging frameworks.  This especially
becomes an issue if you consider the wider world of software (beyond
ASF projects).  Though most ASF projects use slf4j or jcl, this is not
true in general terms.

Therefore I am making an effort to convince the author(s) of these
frameworks upon which my project relies, to consider making logging
either configurable with no dependencies, or optional altogether.
Using JDK logging seems like a reasonable compromise.

- DML

Re: Revisiting logging in MINA 2.0

[Maarten Bosteels]

Hello all,

On Dec 17, 2007 6:25 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> Hi Maarten,
>
> On Dec 15, 2007 3:26 AM, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> > 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.
>
> I think it's not really a bug of Log4J but a missing feature (i.e.
> reentrant logging).  There are two workaround for the dead lock; one
> is to turn OFF logging for MINA, and the other is use a differnt
> appender (i.e. non-MINA-based one).  The second solution might be most
> viable solution that causes no change in our source code.  However,
> some built-in filters that logs messages might be used for the
> MINA-based appender, and the log messages logged by the filter might
> need to be transmitted via the MINA-based appender because it's not a
> critical but just informing message.  So... the two workarounds I've
> mentioned are not likely to solve this problem perfectly.
>
> We can ask Log4J team to fix this issue and it will be fixed, but,
> again, considering that people wants to use the older version of Log4J
> or doesn't want to upgrade the Log4J due to some reason (e.g. custom
> patch) won't see this problem resolved in Log4J.
> And.. that's why I am suggesting a thin layer for logging.

Suppose that the log4j team fixes this issue in their next release,
then the only people who would need this thin layer
are people who
a) want to use a MINA based appender (which is not yet part of
standard log4j as far as I know)
b) AND don't want to upgrade to a newer log4j version

IMO, that is a rather weak argument for resorting to our own "thin
layer for logging".

> By doing so, a user can bypass the existing logging framework to log messages
> from MINA itself.  Of course, this doesn't necessarily mean that we
> will not experience dead lock or infinite recursion.  However, at
> least we have control over such a tricky situation, and cut down
> unnecessary recursion.
>
> Another merit of the thin logging layer could be that it makes a JUL
> user doesn't need to add SLF4J JARs unnecessary.  I sometime don't
> understand why the number of JARs are important.  However, as David
> pointed out, it's pretty critical to the frameworks that depends on
> the other frameworks.  For example, in the early stage of JMX
> integration implementation, I have used Commons BeanUtils which
> depends on commons logging.  This meant a MiNA user who wants to use
> JMX integration module needs to add another JAR to his or her
> classpath.

I agree, there are currently two logging facades that are widely used
by frameworks/libraries: jakarta-commons-logging (JCL) and SLF4J.
The consequence is that for any project with dependencies, there is a
reasonable chance that both logging facades need to be on the
classpath. But is that a problem ?

Our application depends on JCL (because of spring,) and on SLF4J
(because of MINA) and we let both facades point to log4j.
Works pefectly. Really, I do not see the problem.

Of course, I would prefer it if we would only need SLF4J, but that's a
problem that MINA can not solve.
I am afraid that a thin layer in MINA will just make things more complex.
Could you explain a bit how that thin layer would work ?

Maarten
logger.info("I am NOT obsessed with logging");

> If he or she is using a Maven, then it also means that he
> or she has to add many  tags to  section, which
> is pain in the butt.
>
> These thoughts lead me to think all frameworks have to:
>
> 1) provide a thin logging layer or
> 2) not log at all.
>
> I'd prefer the solution #1.
>
> David answered other questions pretty nicely, so that's all for me.
>
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>

Re: Revisiting logging in MINA 2.0

[David M. Lloyd]

On Mon, 17 Dec 2007 14:29:10 +0900
"Trustin Lee" <[EMAIL PROTECTED]> wrote:

> BTW I think we need something different from JarJar
> (http://code.google.com/p/jarjar/).  We need a simple skeleton code
> from which a thin logging layer code is generated into the specified
> package (org.apache.mina.common in MINA's case).  It could be reused
> among many frameworks including MINA.

Yes, I agree - I've often wished that slf4j would have taken this route
instead.  If such a thing existed, I'd definitely use it for my
projects.

- DML

[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it

[David M. Lloyd (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552402
 ] 

David M. Lloyd commented on DIRMINA-495:


The name is unimportant to me - Mike?

> 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 AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value = 
> value; }
>public static  AttributePair pair(K key, V value) { return 
> new AttributePair(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] Closed: (DIRMINA-497) Thread safety issue: incorrect usage of Collections.synchronizedMap in DefaultIoSessionDataStructureFactory.DefaultIoSessionAttributeMap

[David M. Lloyd (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David M. Lloyd closed DIRMINA-497.
--

Resolution: Invalid

Ah yes, you are correct - I looked a while back and noticed that there is a 
separate "mutex" object in the SynchronizedMap implementation, but I never 
noticed that it was initialized to the map itself...

Never mind then ;-)

> 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.

Re: [New Committer] Everyone let's give a warm welcome to Jeff Genender

[Maarten Bosteels]

Welcome Jeff !

Maarten

On Dec 17, 2007 9:32 AM, Julien Vermillard <[EMAIL PROTECTED]> wrote:

> Welcome Jeff !
>
> On Fri, 14 Dec 2007 16:29:50 -0500
> "Alex Karasulu" <[EMAIL PROTECTED]> 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

[Julien Vermillard]

Welcome Jeff !

On Fri, 14 Dec 2007 16:29:50 -0500
"Alex Karasulu" <[EMAIL PROTECTED]> 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: Send Message Failure

[Steve Johns]

On Dec 17, 2007 12:31 PM, Trustin Lee <[EMAIL PROTECTED]> wrote:

>  On Dec 14, 2007 7:56 AM, Steve Johns <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 14, 2007 6:40 AM, mat <[EMAIL PROTECTED]> wrote:
> >
> > > On Dec 14, 2007 1:35 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> > >
> > > > Hi Steve,
> > > >
> > > > On Dec 13, 2007 11:49 PM, Steve Johns <[EMAIL PROTECTED]>
> > > wrote:
> > > > > Thanks for Mina. It is a great project.
> > > >
> > > > Whenever we hear this, we become happy and try to work harder for
> > > > MINA.  Thank you too!
> > >
> > > :D
> > >
> > > >
> > > >
> > > > > 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?).
> > > >
> > > > There's writeTimeout property in IoSessionConfig, so you can adjust
> > > > the timeout value.  Once the write it timed out,
> WriteTimeoutException
> > > > is raised and forwarded to your IoHandler's exceptionCaught method.
> > > > And then the connection will be closed automatically.
> > > >
> > > > > Why
> > > > > NOT accumulated writeQueue size > user defined size and exception?
> > > >
> > > > Could you explain this question more in detail?
> > >
> > > Which meant: I need close the session whenever the write queue
> size(buffer
> > > size) for this session reaches a certain number.
> >
> > Yup. That was what I meant.
>
> You can always check the size of the write request queue via
> IoSession.getScheduledWriteRequests/Bytes().  You can call
> IoSession.close() explicitly when it returns the greater value than
> you expected.
>
> > > > 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.
> > >
> > > Right.  We got the same request before and I suggested him to use some
> > > cache.  Would it work for you, either?
> >
> > A cache sounded workable. However where should I do the MESSAGE ->
> byte[] ->
> > > cache(If I do in IoHandler, is that kinda mixing business logic and
> > > protocol
> > > handler)?
> >
> > Can you give more hints about what the CACHE is?
>
> In you encoder, you could maintain a Map whose key is some message key
> and whose value is encoded ByteBuffer (or byte[]).  It could probably
> be a LRUMap implementation that is provided by 3rd party collections
> API such as Apache Commons Collections.  You could query the map if
> there's already an encoded form of the message, and reuse the encoded
> data if there's one in your encoder implementation.

Thanks. Trustin. I totally understood. However, where I do the message - >
byte[]  part? Is that supposed to be in the Encoder? But what suggested
seems doing the encoding message -> byte[] part in IoHandlerAdapter or
Busniess logic.

>
>
> HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>