[JBoss JIRA] Created: (JGRP-815) Scatter/Gather to avoid copying
by Bela Ban (JIRA)
Scatter/Gather to avoid copying
-------------------------------
Key: JGRP-815
URL: https://jira.jboss.org/jira/browse/JGRP-815
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
When we invoke Channel.send(), we pass a bufffer to JGroups. At the transport level, JGroups marshals the sender and destination address, plus all headers and the buffer into a new byte[] buffer, which is then passed to the socket (DatagramSocket, MulticastSocket, Socket).
We cannot do gathering writes on a DatagramSocket because DatagramSocket doesn't expose this functionality, contrary to a DatagramChannel.
We could avoid having to copy the user's buffer by using gathering writes: effectively passing to the socket NIO ByteBuffers containing:
1: Src and dest address plus flags, plus possibly size
2: The marshalled headers
3: The buffer passed to JGroups by the user
We can obtain a gathering-write channel as follows:
ByteBuffer[] buffers; // contains the 3 byte buffers above
DatagramSocket sock;
DatagramChannel ch=sock.getChannel();
ch.write(buffers, 0, length); // length is the number of bytes of the total marshalled message
This is supported by a GatheringByteChannel.
I don't think there's currently a need to do scattered reads, but this needs to get investigated more. Also investigate whether MulticastSockets support gathering writes (whether they expose the correct DatagramChannel).
--
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
12 years, 7 months
[JBoss JIRA] Created: (JGRP-816) TP: avoid copying when receiving data
by Bela Ban (JIRA)
TP: avoid copying when receiving data
-------------------------------------
Key: JGRP-816
URL: https://jira.jboss.org/jira/browse/JGRP-816
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
Currently, we receive data into a byte[] buffer, e.g. from DatagramSocket.receive(), but then have to COPY buffer when passing it to a worker from the thread pool. The copy is needed because the next DatargamSocket.receive() will overwrite the contents of buffer, and if the worker thread is still unmarshalling the data from the buffer, it might read corrupt contents.
To overcome this, investigate the following:
- Every worker thread has it own buffer
- When the thread has been idle for N seconds and is removed from the pool, that buffer will be discarded
- We create DatagramChannels from the socket(s) (DatagramSocket, MulticastSocket or Socket)
- A selector is called when new data is available on the socket
- The key returned by the selector points to the right channel
- We pass the channel to a thread pool worker thread and continue with the select() loop
- The worker then reads the data into its own buffer, unmarshalls it and passed it up the stack
==> No copy of the buffer is required as the thread's buffer is available until the message has been processed (usually until message unmarshalling)
--
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
12 years, 7 months
[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
12 years, 7 months
[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
12 years, 7 months
[JBoss JIRA] Created: (JBREM-857) transporterclient not thread-safe for failover
by craig bordelon (JIRA)
transporterclient not thread-safe for failover
----------------------------------------------
Key: JBREM-857
URL: http://jira.jboss.com/jira/browse/JBREM-857
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transporter
Affects Versions: 1.4.6.GA
Environment: solaris 10 and java 5
Reporter: craig bordelon
Fix For: 2.2.2.GA_CP02
the jboss 1.4.1 transporterclient used by multithreaded program was giving strange results on a clustered server when failing over so i found lack of synchronization in the code.
I made these changes and seems to be helping.
changes to TransporterClient.java.
I would like this fixed in the 2.x and 3.x versions (hello developers). I think i know how to fix the 2.x version of this code too as it has some new stuff but is likewise broken. (developers send me an email to bord(a)iscp.telcordia.com if you need it. thx
Craig)
@@ -93,11 +93,12 @@
/**
* Disconnects the remoting client
*/
- private void disconnect()
+ private synchronized void disconnect()
{
if(remotingClient != null)
{
remotingClient.disconnect();
+ remotingClient = null;
}
}
@@ -232,14 +233,18 @@
do
{
+ Client rcl = null;
+ synchronized(this) { rcl = remotingClient; }
+ if (rcl == null) throw new CannotConnectException("Client has been dis
connected.");
try
{
failOver = false;
- response = remotingClient.invoke(request);
+ response = rcl.invoke(request);
}
catch(CannotConnectException cnc)
{
- failOver = findAlternativeTarget();
+ failOver = findAlternativeTarget(rcl);
+ if (log.isDebugEnabled()) log.error("on CannotConnectException failO
ver is "+failOver+" for "+rcl.getInvoker().getLocator());
if(!failOver)
{
throw cnc;
@@ -264,7 +269,7 @@
*
* @return
*/
- private boolean findAlternativeTarget()
+ private boolean findAlternativeTarget(Client rcl)
{
boolean failover = false;
@@ -287,12 +292,19 @@
{
// finally found server with target handler
InvokerLocator newLocator = data.getInvokerLocator();
- if(!remotingClient.getInvoker().getLocator().equals(new
Locator))
+ if(!rcl.getInvoker().getLocator().equals(newLocator))
{
try
{
- remotingClient = new Client(newLocator);
- remotingClient.connect();
+ synchronized(this) {
+ if (rcl == remotingClient) {
+ disconnect();
+ remotingClient = new Client(newLocator);
+ }
+ //otherwise have to assume some other thread
+ //has meanwhile changed it
+ //including even disconnecting
+ }
return true;
}
catch(Exception e)
@@ -300,6 +312,8 @@
log.warn("Problem connecting to newly found alter
nate target.", e);
}
}
+ else if (log.isDebugEnabled())
+ log.error(rcl.getInvoker().getLocator()+" == "+newLoc
ator);
}
}
}
@@ -333,4 +347,4 @@
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] Created: (JBREM-906) NoSuchObjectException on Server Restart Using RMI Transport & Unified Invoker
by John Reynolds (JIRA)
NoSuchObjectException on Server Restart Using RMI Transport & Unified Invoker
-----------------------------------------------------------------------------
Key: JBREM-906
URL: http://jira.jboss.com/jira/browse/JBREM-906
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: unifiedinvoker
Affects Versions: 2.2.2.GA
Environment: Server Running Windows XP or Redhat - Swing Client on Windows XP
Reporter: John Reynolds
Using a Swing client to connect to the JBoss server, configured with RMI Transport Connector and Unified Invoker, I receive the following StackTrace when, after successfully connecting to the server and executing a few EJB transactions, I shut the server down and then bring it back up. Upon attempting to do any further invocations, it appears cached information is causing the client to fail.
-------------
(rmi.RMIClientInvoker 272 ) java.rmi.NoSuchObjectException: no such object in table
galaxy.framework.model.domain.services.util.SLCommunicationException: Error making invocation in RMI client invoker.
at galaxy.framework.model.domain.services.util.ServiceLocator.authenticateUser(ServiceLocator.java:738)
at galaxy.framework.model.domain.services.util.ServiceLocator.initializeWithLDAP(ServiceLocator.java:435)
at galaxy.application.view.swing.presentation.util.ClientConnectionManager$1.run(ClientConnectionManager.java:51)
Caused by: org.jboss.remoting.CannotConnectException: Error making invocation in RMI client invoker.
at org.jboss.remoting.transport.rmi.RMIClientInvoker.transport(RMIClientInvoker.java:273)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
at org.jboss.remoting.Client.invoke(Client.java:1550)
at org.jboss.remoting.Client.invoke(Client.java:530)
at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:183)
at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
at $Proxy1.authenticateSwingUserWithLDAP(Unknown Source)
at galaxy.framework.model.domain.services.util.ServiceLocator.authenticateUser(ServiceLocator.java:725)
... 2 more
Caused by: java.rmi.NoSuchObjectException: no such object in table
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
at org.jboss.remoting.transport.rmi.RMIServerInvoker_Stub.transport(Unknown Source)
at org.jboss.remoting.transport.rmi.RMIClientInvoker.transport(RMIClientInvoker.java:238)
... 14 more
------------
Seems potentially similar to this issue fixed in 4.0.5 in non-remoting-RMI code:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116027
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months