WebSocket: to flip or not the ByteBuffer during sendBinary in RemoteEndpoint(s)
Hi folks, while playing around with tyrus and tomcat implementation of websocket I spotted a difference in the way sendBinary is actually implemented. In short: tyrus uses bytebuffer.array(), hence there is no change in buffer's position while we end with channel write operation that does this. Neither the spec nor the javadoc detail that but the result is that one application can run perfectly on one of the implementations and could cause problem on the other. Shall we contact the EG for clarification on this matter? Opinions? cheers niki
Re: WebSocket: to flip or not the ByteBuffer during sendBinary in RemoteEndpoint(s)
On 28/06/2013 12:47, Niki Dokovski wrote: Hi folks, while playing around with tyrus and tomcat implementation of websocket I spotted a difference in the way sendBinary is actually implemented. In short: tyrus uses bytebuffer.array(), hence there is no change in buffer's position while we end with channel write operation that does this. Neither the spec nor the javadoc detail that but the result is that one application can run perfectly on one of the implementations and could cause problem on the other. Shall we contact the EG for clarification on this matter? No need. The EG has already stated its view (well, the EG lead did and no-one disagreed) quote Since the spec does not say anything about re-using ByteBuffers and they are mutable objects, I would expect the conventional developer practice to be to use a new one each time. /quote Opinions? I agree with the EG lead. Client's should not be making any assumptions about what the implementation will or won't do with a ByteBuffer. If you want to argue for a specific behaviour, open an issue against the spec. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket: to flip or not the ByteBuffer during sendBinary in RemoteEndpoint(s)
On Fri, Jun 28, 2013 at 3:44 PM, Mark Thomas ma...@apache.org wrote: On 28/06/2013 12:47, Niki Dokovski wrote: Hi folks, while playing around with tyrus and tomcat implementation of websocket I spotted a difference in the way sendBinary is actually implemented. In short: tyrus uses bytebuffer.array(), hence there is no change in buffer's position while we end with channel write operation that does this. Neither the spec nor the javadoc detail that but the result is that one application can run perfectly on one of the implementations and could cause problem on the other. Shall we contact the EG for clarification on this matter? No need. The EG has already stated its view (well, the EG lead did and no-one disagreed) quote Since the spec does not say anything about re-using ByteBuffers and they are mutable objects, I would expect the conventional developer practice to be to use a new one each time. /quote Thanks for sharing. This is an assumption about what is conventional developer practice :) Opinions? I agree with the EG lead. Client's should not be making any assumptions about what the implementation will or won't do with a ByteBuffer. If you want to argue for a specific behaviour, open an issue against the spec. I'll ask for a clarification and let's see. The effect is that because of this we can lose portability. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket: to flip or not the ByteBuffer during sendBinary in RemoteEndpoint(s)
On Fri, Jun 28, 2013 at 3:57 PM, Niki Dokovski nick...@gmail.com wrote: On Fri, Jun 28, 2013 at 3:44 PM, Mark Thomas ma...@apache.org wrote: On 28/06/2013 12:47, Niki Dokovski wrote: Hi folks, while playing around with tyrus and tomcat implementation of websocket I spotted a difference in the way sendBinary is actually implemented. In short: tyrus uses bytebuffer.array(), hence there is no change in buffer's position while we end with channel write operation that does this. Neither the spec nor the javadoc detail that but the result is that one application can run perfectly on one of the implementations and could cause problem on the other. Shall we contact the EG for clarification on this matter? No need. The EG has already stated its view (well, the EG lead did and no-one disagreed) quote Since the spec does not say anything about re-using ByteBuffers and they are mutable objects, I would expect the conventional developer practice to be to use a new one each time. /quote Thanks for sharing. This is an assumption about what is conventional developer practice :) Opinions? I agree with the EG lead. Client's should not be making any assumptions about what the implementation will or won't do with a ByteBuffer. If you want to argue for a specific behaviour, open an issue against the spec. I'll ask for a clarification and let's see. The effect is that because of this we can lose portability. https://java.net/jira/browse/WEBSOCKET_SPEC-209 Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
