[JBoss JIRA] Created: (JBREM-1286) Fix sources encoding to UTF-8
by Ondrej Zizka (JIRA)
Fix sources encoding to UTF-8
-----------------------------
Key: JBREM-1286
URL: https://issues.jboss.org/browse/JBREM-1286
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Ondrej Zizka
Compiling 395 source files to build/classes
src/main/org/jboss/remoting/callback/CallbackStore.java:79: unmappable character for encoding UTF-8
* Key for setting the file suffix to use for the callback objects written to disk. The default value is �ser�.
src/main/org/jboss/remoting/callback/CallbackStore.java:79: unmappable character for encoding UTF-8
* Key for setting the file suffix to use for the callback objects written to disk. The default value is �ser�.
2 errors
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (JBREM-1169) Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold
by mingjun jiang (JIRA)
Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBREM-1169
URL: https://jira.jboss.org/jira/browse/JBREM-1169
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: detection
Affects Versions: 2.2.3.SP1
Environment: OS: Windows Server 2003. JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA, JBoss Remoting 2.2.3 SP1
Reporter: mingjun jiang
We are using JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA and JBoss Remoting 2.2.3 SP1. In our application, there are a lot of Message listeners running on the client side, these message listeners will receive messages from queue/topic deployed in JBoss Messaging
Configuration:
We created our own JMS Connection factory which uses the default remoting connector. As you know, the default remoting connector is configured to use the bisocket transport. We didn't change the default value of the remoting connector
During we run our application, we open the JBoss web console to monitor the value of currentClientPoolSize under "Jboss.remoting" JMX MBean.
How to reproduce this issue:
1. Run 5 message listeners in the client side to receive messages from JBoss Messaging, then we observe the value of currentClientPoolSize is 10
2. After processing several messages, we manually pull out the ethernet cable. The value of currentClientPoolSize is still 10.
3. We run another 5 message listeners in client side, then the value of currentClientPoolSize will become 20
4. After we do the same operations above several times, the value of currentClientPoolSize will increase continuously. Once the value of currentClientPoolSize is equal to the MaxPoolSize, then the subsequent incoming client requests will hang, and we will encounter the following exception in server side
2009-10-20 18:08:09,655 ERROR [org.jboss.remoting.transport.socket.ServerThread] Worker thread initialization failure
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
at java.io.FilterInputStream.read(FilterInputStream.java:66)
at org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:859)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:545)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:406)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173)
Conclusion: JBoss Messaging won't close the failure connections if they are caused by manually pulling out ethernet cable. As a result, the value of currentClientPoolSize will increase continuously and finally the new client requests will hang
Note: If we killed the process of message listener in client side, then the value of currentClientPoolSize will decrease to 0 immediately, it seems that the server could detect the failure connection and perform the corresponding resource releasing.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (JBREM-1054) Annotation to automatically return new transporters types
by David Lloyd (JIRA)
Annotation to automatically return new transporters types
---------------------------------------------------------
Key: JBREM-1054
URL: https://jira.jboss.org/jira/browse/JBREM-1054
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: r3 api
Reporter: David Lloyd
Priority: Optional
Fix For: 3.1.0.Beta1
It would be cool if a transporter interface (or an implementing class of that interface) could have methods which sport an annotation that indicates that the return value of that method, if it is an interface, should be automatically wrapped into a transporter (if invoked via a transporter). This way, complex remote object structures can be easily created and used.
Also handy would be a simple way of notating such methods when the interface and implementation are already existent.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (JBREM-1287) getting java.lang.RuntimeException: Unreachable?: Service unavailable. after reaching around 100 odd remote connections
by Dinuka Arseculeratne (JIRA)
getting java.lang.RuntimeException: Unreachable?: Service unavailable. after reaching around 100 odd remote connections
-----------------------------------------------------------------------------------------------------------------------
Key: JBREM-1287
URL: https://issues.jboss.org/browse/JBREM-1287
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Redhat Linux
Reporter: Dinuka Arseculeratne
Priority: Critical
i am getting java.lang.RuntimeException: Unreachable?: Service unavailable. error within my jbos 4.2.3 app server when doing a load test. During the test when we reach around 100+ remote ejb lookup calls we get this error. It works fine for any connections around 70. After this error comes we have to restart the servers. Our architecture is such that we have the web and app servers separated and remote calls happen between the two servers.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] Created: (JBREM-1295) CloseHandlers are not called when the remote connection closes
by Kabir Khan (JIRA)
CloseHandlers are not called when the remote connection closes
--------------------------------------------------------------
Key: JBREM-1295
URL: https://issues.jboss.org/browse/JBREM-1295
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Kabir Khan
Assignee: David Lloyd
THis is for 3.2.0 which does not appear in the version list
Adding the following to org.jboss.remoting3.test.ChannelTestBase.java, the close handler does not get called. We discussed on IRC a few days ago but no matter what I do to close the channel this does not get called. Please provide a working example
@Test
public void testRemoteChannelClose() throws Exception {
final CountDownLatch closedLatch = new CountDownLatch(1);
sendChannel.addCloseHandler(new CloseHandler<Channel>() {
@Override
public void handleClose(Channel closed) {
closedLatch.countDown();
}
});
recvChannel.writeShutdown();
IoUtils.safeClose(recvChannel);
System.out.println("Waiting for closed");
closedLatch.await();
System.out.println("Closed");
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months