[jira] Created: (DIRMINA-734) Regression with flushing in MINA 2.0.0-M7 trunk
Regression with flushing in MINA 2.0.0-M7 trunk --- Key: DIRMINA-734 URL: https://issues.apache.org/jira/browse/DIRMINA-734 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-M7 Reporter: Serge Baranov It looks like the present trunk of MINA in the repository has a bug. Updating from M7 built on 06.06.2009 to the current trunk broke some of our tests. I've tried to build it today and ran our application tests, some of them failed. Reverting back to 06.06.2009 build has fixed the problem. At the first look it appears that session.close(false) behaves like session.close(true), as a result some messages are truncated (not being flushed on session.close(false)). If I comment out a call to session.close(false) (i.e. not closing the session at all when needed), the problem goes away. This behavior is inconsistent, test fails/succeeds randomly. On the first run it may pass, on the second run it may fail. Test fails about 10% of runs. The part which is not flushed is also random. Could be a race condition somewhere in MINA introduced in the last 2 months. I can't provide a test case yet, but our application is a kind of proxy, so it behaves like this: 1. client connects to the app and send a request 2. app connects to another server and sends a request 3. app gets a reply from the server and sends it back to the client 4. when another server closes the connection, app is closing the connection with the client using session.close(false) The app may be still flushing data to client when closing the connection. As I said it worked fine with previous MINA versions, but has broken only recently. We are using OrderedThreadPoolExecutor and CumulativeProtocolDecoder if that matters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (VYSPER-102) Discovering Component Support for MUC
[ https://issues.apache.org/jira/browse/VYSPER-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-102. Resolution: Fixed Assignee: Niklas Gustavsson Implemented in rev 800979 > Discovering Component Support for MUC > - > > Key: VYSPER-102 > URL: https://issues.apache.org/jira/browse/VYSPER-102 > Project: VYSPER > Issue Type: Sub-task > Components: XEP-0045 MUC >Reporter: Niklas Gustavsson >Assignee: Niklas Gustavsson > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (VYSPER-103) Discovering Rooms
[ https://issues.apache.org/jira/browse/VYSPER-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed VYSPER-103. Resolution: Fixed Implemented in rev 800979 > Discovering Rooms > - > > Key: VYSPER-103 > URL: https://issues.apache.org/jira/browse/VYSPER-103 > Project: VYSPER > Issue Type: Sub-task > Components: XEP-0045 MUC >Reporter: Niklas Gustavsson > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: FTPS with passive mode is slow
I believe this problem has been reported multiple times. Please open a JIRA and apply the patch, it makes perfect sense. /niklas On Tue, Aug 4, 2009 at 10:02 PM, Sai Pullabhotla wrote: > I've been noticing that the passive data connections are taking quite > some time when using SSL. I finally got some time to look into this > and noticed the following while debugging through the code. This issue > might have been introduced with the fix we put in for FTPSERVER-241. > > The code that wraps the plain socket into an SSL socket uses the > following line: > > SSLSocket sslSocket = (SSLSocket) ssocketFactory > .createSocket(serverSocket, > serverSocket.getInetAddress().getHostName(), > serverSocket.getPort(), true); > > Based on the JavaDocs, the InetAddress.getHostName() performs a > reverse name look up, which was taking about 1.5 seconds on every > system on our network. I'm not sure if this is an issue with the way > our network is setup. Some one please let me know if this in fact an > issue with our network. > > We are not seeing this lag when client and server are running on the > same system. Things work too fast in this case, probably because the > system knows very well about itself. > > Just to try it out, I changed the code to simply use the IP address > rather than the host name, and I was able to get rid of the lag and > things seem to be working much faster. Below is the change to the > above line: > > SSLSocket sslSocket = (SSLSocket) ssocketFactory > .createSocket(serverSocket, > serverSocket.getInetAddress().getHostAddress(), > serverSocket.getPort(), true); > > Could some one test the current code base with client and server > running on different systems and tell me if they notice the lag when > creating the passive data connection. If this can be reproduced on one > of your environments, we should probably put the above fix. I don't > think this suggested fix should cause any other issues, do you? > > Regards, > > Sai Pullabhotla > www.jMethods.com >
FTPS with passive mode is slow
I've been noticing that the passive data connections are taking quite some time when using SSL. I finally got some time to look into this and noticed the following while debugging through the code. This issue might have been introduced with the fix we put in for FTPSERVER-241. The code that wraps the plain socket into an SSL socket uses the following line: SSLSocket sslSocket = (SSLSocket) ssocketFactory .createSocket(serverSocket, serverSocket.getInetAddress().getHostName(), serverSocket.getPort(), true); Based on the JavaDocs, the InetAddress.getHostName() performs a reverse name look up, which was taking about 1.5 seconds on every system on our network. I'm not sure if this is an issue with the way our network is setup. Some one please let me know if this in fact an issue with our network. We are not seeing this lag when client and server are running on the same system. Things work too fast in this case, probably because the system knows very well about itself. Just to try it out, I changed the code to simply use the IP address rather than the host name, and I was able to get rid of the lag and things seem to be working much faster. Below is the change to the above line: SSLSocket sslSocket = (SSLSocket) ssocketFactory .createSocket(serverSocket, serverSocket.getInetAddress().getHostAddress(), serverSocket.getPort(), true); Could some one test the current code base with client and server running on different systems and tell me if they notice the lag when creating the passive data connection. If this can be reproduced on one of your environments, we should probably put the above fix. I don't think this suggested fix should cause any other issues, do you? Regards, Sai Pullabhotla www.jMethods.com
[jira] Created: (DIRMINA-733) The profile method in the ProfilerTimerFilter can caused more methods to be profiled than intended.
The profile method in the ProfilerTimerFilter can caused more methods to be profiled than intended. --- Key: DIRMINA-733 URL: https://issues.apache.org/jira/browse/DIRMINA-733 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 2.0.0-M6 Environment: Mina M6 and verified in the trunk. Reporter: Christopher Popp Priority: Minor Issue affects the ProfilerTimerFilter. Some of the case statements in the profile method are missing a return/break. This causes the possibility of profiling to be enabled for methods other than the one specified. See method below public void profile(IoEventType type) { switch (type) { case MESSAGE_RECEIVED : profileMessageReceived = true; if (messageReceivedTimerWorker == null) { messageReceivedTimerWorker = new TimerWorker(); } return; case MESSAGE_SENT : profileMessageSent = true; if (messageSentTimerWorker == null) { messageSentTimerWorker = new TimerWorker(); } return; case SESSION_CREATED : profileSessionCreated = true; if (sessionCreatedTimerWorker == null) { sessionCreatedTimerWorker = new TimerWorker(); } case SESSION_OPENED : profileSessionOpened = true; if (sessionOpenedTimerWorker == null) { sessionOpenedTimerWorker = new TimerWorker(); } case SESSION_IDLE : profileSessionIdle = true; if (sessionIdleTimerWorker == null) { sessionIdleTimerWorker = new TimerWorker(); } case SESSION_CLOSED : profileSessionClosed = true; if (sessionClosedTimerWorker == null) { sessionClosedTimerWorker = new TimerWorker(); } } } -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VYSPER-10) Implement Service Discovery XEP-0030
[ https://issues.apache.org/jira/browse/VYSPER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Fondermann resolved VYSPER-10. Resolution: Fixed implemented and in use. > Implement Service Discovery XEP-0030 > > > Key: VYSPER-10 > URL: https://issues.apache.org/jira/browse/VYSPER-10 > Project: VYSPER > Issue Type: Bug > Components: core protocol, extension >Reporter: Bernd Fondermann >Assignee: Bernd Fondermann > > Service Discovery is a central XMPP feature specified at > http://www.xmpp.org/extensions/xep-0030.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (VYSPER-170) Implement Service Administration XEP-0133
Implement Service Administration XEP-0133 - Key: VYSPER-170 URL: https://issues.apache.org/jira/browse/VYSPER-170 Project: VYSPER Issue Type: New Feature Components: extension Reporter: Bernd Fondermann Service Administration specifies Ad-hoc commands to admin the server (manage users, sessions, roster, etc). see http://xmpp.org/extensions/xep-0133.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (VYSPER-169) Implement Ad-Hoc Commands XEP-0050
Implement Ad-Hoc Commands XEP-0050 -- Key: VYSPER-169 URL: https://issues.apache.org/jira/browse/VYSPER-169 Project: VYSPER Issue Type: New Feature Components: extension Reporter: Bernd Fondermann Ad-Hoc commands specifies a framework for invoking server-side functions. see http://xmpp.org/extensions/xep-0050.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (VYSPER-91) Implement Jabber Component Protocol (XEP-0114)
[ https://issues.apache.org/jira/browse/VYSPER-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Fondermann reassigned VYSPER-91: -- Assignee: (was: Bernd Fondermann) > Implement Jabber Component Protocol (XEP-0114) > -- > > Key: VYSPER-91 > URL: https://issues.apache.org/jira/browse/VYSPER-91 > Project: VYSPER > Issue Type: New Feature > Components: extension >Reporter: Bernd Fondermann >Priority: Minor > > See > http://xmpp.org/extensions/xep-0114.html > A related XEP is > http://xmpp.org/extensions/xep-0225.html > Components are trusted functional extensions to a server, residing on their > own subdomain. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Vysper] Server Cache requirements
>>> "Caching" is an optimization strategy to improve throughput and scalability. >>> Currently, we have no idea where we need to optimize, haven't we? >> >> Yup it is. However, we have to start thinking about this. Well we know >> how XMPP Server works and >> we can atleast start putting our thoughts in place. >> >>> What do you think would be the benefit of introducing such a "global >>> implementation"? What would be its features and benefits? >> >> Let me simplify it a bit. We have a cache implementation. How about >> using the same implementation >> by all. The user like presence, roster etc can just customize the way >> they see cache. >> >> Here is what I feel should be the requirements >> 1. CacheProvider - SPI like implementation to plugin custom caching >> implementation. Our Server Users can choose what works best for them >> 2. Modules don't rewrite specific cache implementations, unless a >> situation demands so. They rely on the global implementation. Please >> note that global implementation doesn't means single cache. There can >> be multiple cache's with or without replication. Even as of today we >> use two cache instances for Presence, one based on Entity and other is >> based on JID >> >> The benefit is code reuse and ease of maintenance :-) > > You mean you want to share code and build something like a "cache > abstraction layer"? I found the current implementations to be quite > lightweight and don't yet see the benefit. Not yet, but shall the details as soon as I have more concrete design. -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [Vysper] Server Cache requirements
Ashish wrote: > On Tue, Aug 4, 2009 at 1:13 PM, Bernd > Fondermann wrote: >> On Tue, Aug 4, 2009 at 06:24, Ashish wrote: >>> While implementing Presence Cache for Vysper, was wondering, is this >>> the only cache needed by Server? >>> >>> So, if other modules need caching, they may have to re-implement the >>> cache like Presence Cache. >>> >>> How about having Cache implemntation as part of Server and required >>> modules can either extend it or >>> use the global implementation. >>> >>> wdyt? >> There are a few things the server needs to have quick access to: >> rosters, active sessions, resource ids etc. >> Some XMPP extension mights needs this, too. They will have very >> specific requirements, though. >> >> "Caching" is an optimization strategy to improve throughput and scalability. >> Currently, we have no idea where we need to optimize, haven't we? > > Yup it is. However, we have to start thinking about this. Well we know > how XMPP Server works and > we can atleast start putting our thoughts in place. > >> What do you think would be the benefit of introducing such a "global >> implementation"? What would be its features and benefits? > > Let me simplify it a bit. We have a cache implementation. How about > using the same implementation > by all. The user like presence, roster etc can just customize the way > they see cache. > > Here is what I feel should be the requirements > 1. CacheProvider - SPI like implementation to plugin custom caching > implementation. Our Server Users can choose what works best for them > 2. Modules don't rewrite specific cache implementations, unless a > situation demands so. They rely on the global implementation. Please > note that global implementation doesn't means single cache. There can > be multiple cache's with or without replication. Even as of today we > use two cache instances for Presence, one based on Entity and other is > based on JID > > The benefit is code reuse and ease of maintenance :-) You mean you want to share code and build something like a "cache abstraction layer"? I found the current implementations to be quite lightweight and don't yet see the benefit. Do you have some code or can outline what would be shared between cache implementations? Bernd
Re: [Vysper] Server Cache requirements
On Tue, Aug 4, 2009 at 1:13 PM, Bernd Fondermann wrote: > On Tue, Aug 4, 2009 at 06:24, Ashish wrote: >> While implementing Presence Cache for Vysper, was wondering, is this >> the only cache needed by Server? >> >> So, if other modules need caching, they may have to re-implement the >> cache like Presence Cache. >> >> How about having Cache implemntation as part of Server and required >> modules can either extend it or >> use the global implementation. >> >> wdyt? > > There are a few things the server needs to have quick access to: > rosters, active sessions, resource ids etc. > Some XMPP extension mights needs this, too. They will have very > specific requirements, though. > > "Caching" is an optimization strategy to improve throughput and scalability. > Currently, we have no idea where we need to optimize, haven't we? Yup it is. However, we have to start thinking about this. Well we know how XMPP Server works and we can atleast start putting our thoughts in place. > > What do you think would be the benefit of introducing such a "global > implementation"? What would be its features and benefits? Let me simplify it a bit. We have a cache implementation. How about using the same implementation by all. The user like presence, roster etc can just customize the way they see cache. Here is what I feel should be the requirements 1. CacheProvider - SPI like implementation to plugin custom caching implementation. Our Server Users can choose what works best for them 2. Modules don't rewrite specific cache implementations, unless a situation demands so. They rely on the global implementation. Please note that global implementation doesn't means single cache. There can be multiple cache's with or without replication. Even as of today we use two cache instances for Presence, one based on Entity and other is based on JID The benefit is code reuse and ease of maintenance :-) -- thanks ashish
Re: [Vysper] Server Cache requirements
On Tue, Aug 4, 2009 at 06:24, Ashish wrote: > While implementing Presence Cache for Vysper, was wondering, is this > the only cache needed by Server? > > So, if other modules need caching, they may have to re-implement the > cache like Presence Cache. > > How about having Cache implemntation as part of Server and required > modules can either extend it or > use the global implementation. > > wdyt? There are a few things the server needs to have quick access to: rosters, active sessions, resource ids etc. Some XMPP extension mights needs this, too. They will have very specific requirements, though. "Caching" is an optimization strategy to improve throughput and scalability. Currently, we have no idea where we need to optimize, haven't we? What do you think would be the benefit of introducing such a "global implementation"? What would be its features and benefits? Bernd > > -- > thanks > ashish > > Blog: http://www.ashishpaliwal.com/blog > My Photo Galleries: http://www.pbase.com/ashishpaliwal >