I have noticed a problem and I am wondering about the fix, as it concerns net.sf.jml.net.Session it seems important to me.
The problem is easy to reproduce. As in sip-communicator we are not currently using switchboards we let the jml create them. If you send a message to a contact and that contact doesn't closes the conversation for some time (I tested with one hour) and if we send a second message after that time we got the following exception :
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.ByteArrayOutputStream.writeTo(ByteArrayOutputStream.java:109)
at net.sf.jml.net.Session.sendMessage(Session.java:511)
at net.sf.jml.net.Session.access$1300(Session.java:30)
at net.sf.jml.net.Session$MsgSender.run(Session.java:476)
at java.lang.Thread.run(Thread.java:619)
Currently in Session.sendMessage we just print the exception and ignore it. I'm wondering if we just firExceptionCaught(ex); and in BasicSwitchboard.SBSessionListener we catch this and fire that the switchboard is closed so the next time we send a message a new switchboard will be open. But this way we miss a message which is not good. Or we can reopen the switchboard the same way it was created by jml. Or the third option is to recreate the Socket in net.Session but this I'm not sure that the server is keeping the state and will it handle the reopening ok.
WDYT ?
Thanks
damencho
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wonder if there's some solution to prevent even such exception, maybe we could implement some kind of timer to auto-close switchboard after some idle time.. (as other clients implement such thing perhaps according MSNP). Anyway I remember seeing some issue with this idle-related things with aMSN..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, sounds reasonable, I will try to find more info what is the time interval and such, maybe others have tested it. As we mentioned timers, long ago I had a change I haven't merged in the trunk maybe now is the time to discuss it cause it seems almost the same :)
In sip-communicator when we load the contact list and we are missing a picture for a contact we request it, this happens to all contacts when you have just created the account. And here comes the problem as there is rate allowed for new switchboards its 8 of them for one minute. And if you try to make 9 you got an error from the server, so I added a rater thread to SimpleMessenger. I will add a patch so anybody can take a look and if its ok with all of you we can merge it.
damencho
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hum, its set 5 minutes time out to the session used by the switchboard but there seems to be any problem. I tried sending a message than wait 6 minutes and send new one to see of new switchboard will be created, but I have never seen that message coming after the 5 minutes and no switchboard was closed and none was opened. It seems problem on our side.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think as this is just an improvement you can merge it without problems, thank you! Anyway before merge what SVN version are you using? I think there are no changes in the last commits on SimpleMessenger, but it would be great to diff / commit it with the last SVN to avoid unnecessary reverts!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No its already there, the timer. I think I found it, I'm just testing it and will commit it later :) Actually as there is set a timout to the session used by the switchboard, no timer is started cause the set is before starting the session but that timouts must be set on running session (this is also used by PNG, pings to keep alive).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I left timeout to be 5 minutes. I saw other libraries are more aggressive as they close it on 60 seconds, but if we spot the problem again will lower it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I have noticed a problem and I am wondering about the fix, as it concerns net.sf.jml.net.Session it seems important to me.
The problem is easy to reproduce. As in sip-communicator we are not currently using switchboards we let the jml create them. If you send a message to a contact and that contact doesn't closes the conversation for some time (I tested with one hour) and if we send a second message after that time we got the following exception :
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.ByteArrayOutputStream.writeTo(ByteArrayOutputStream.java:109)
at net.sf.jml.net.Session.sendMessage(Session.java:511)
at net.sf.jml.net.Session.access$1300(Session.java:30)
at net.sf.jml.net.Session$MsgSender.run(Session.java:476)
at java.lang.Thread.run(Thread.java:619)
Currently in Session.sendMessage we just print the exception and ignore it. I'm wondering if we just firExceptionCaught(ex); and in BasicSwitchboard.SBSessionListener we catch this and fire that the switchboard is closed so the next time we send a message a new switchboard will be open. But this way we miss a message which is not good. Or we can reopen the switchboard the same way it was created by jml. Or the third option is to recreate the Socket in net.Session but this I'm not sure that the server is keeping the state and will it handle the reopening ok.
WDYT ?
Thanks
damencho
Hi!
I wonder if there's some solution to prevent even such exception, maybe we could implement some kind of timer to auto-close switchboard after some idle time.. (as other clients implement such thing perhaps according MSNP). Anyway I remember seeing some issue with this idle-related things with aMSN..
Thanks, sounds reasonable, I will try to find more info what is the time interval and such, maybe others have tested it. As we mentioned timers, long ago I had a change I haven't merged in the trunk maybe now is the time to discuss it cause it seems almost the same :)
In sip-communicator when we load the contact list and we are missing a picture for a contact we request it, this happens to all contacts when you have just created the account. And here comes the problem as there is rate allowed for new switchboards its 8 of them for one minute. And if you try to make 9 you got an error from the server, so I added a rater thread to SimpleMessenger. I will add a patch so anybody can take a look and if its ok with all of you we can merge it.
damencho
Hum, its set 5 minutes time out to the session used by the switchboard but there seems to be any problem. I tried sending a message than wait 6 minutes and send new one to see of new switchboard will be created, but I have never seen that message coming after the 5 minutes and no switchboard was closed and none was opened. It seems problem on our side.
I think as this is just an improvement you can merge it without problems, thank you! Anyway before merge what SVN version are you using? I think there are no changes in the last commits on SimpleMessenger, but it would be great to diff / commit it with the last SVN to avoid unnecessary reverts!
I didn't read the last message hmmm you mean after implementing a timer?
No its already there, the timer. I think I found it, I'm just testing it and will commit it later :) Actually as there is set a timout to the session used by the switchboard, no timer is started cause the set is before starting the session but that timouts must be set on running session (this is also used by PNG, pings to keep alive).
oh ok, great you found it! thanks!
Ok done, I've committed both modifications.
I left timeout to be 5 minutes. I saw other libraries are more aggressive as they close it on 60 seconds, but if we spot the problem again will lower it.
ok thank you damencho! :)