November 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (SECURITY-177) Implement JBossResponseContext.asElement(Document)

by Anil Saldhana (JIRA)

Implement JBossResponseContext.asElement(Document) -------------------------------------------------- Key: SECURITY-177 URL: http://jira.jboss.com/jira/browse/SECURITY-177 Project: JBoss Security and Identity Management Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JBossXACML Affects Versions: 2.0.2-BETA6 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2.GA -- 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

13 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (JGRP-809) Copyless stack

by Bela Ban (JIRA)

Copyless stack -------------- Key: JGRP-809 URL: https://jira.jboss.org/jira/browse/JGRP-809 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Currently (as of 2.7), the transport reads the contents of a received packet into a buffer, then passes a *copy* of the buffer to a thread from the OOB or incoming thread pools. To prevent this copy, we can - have the receiver read only the version and OOB flag (to see which thread pool to dispatch the packet to) - pass a ref to the socket to a thread from the incoming of OOB pool, have that thread read the packet and return - each thread in the pool has its own buffer into which the buffer is read from the socket Possibly use NIO: we can install a selector and get woken up whenever data to be read is present. At that point, we can pass the ref to the socket to the handler thread and return immediately. NIO with channels for multicast sockets is available only in JDK 7 (or 8?), so this is a bit off... However, we can already implement this with reading the version and flags bytes and then passing the socket to the handler -- 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, 1 month

2
6
0 / 0

[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

13 years, 1 month

2
8
0 / 0

[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

13 years, 1 month

2
10
0 / 0

[JBoss JIRA] Created: (JBREM-902) InvocationRequest need SSLSession for certificates and principal in sslsocket transport

by ya xiang (JIRA)

InvocationRequest need SSLSession for certificates and principal in sslsocket transport --------------------------------------------------------------------------------------- Key: JBREM-902 URL: http://jira.jboss.com/jira/browse/JBREM-902 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: security Reporter: ya xiang In a SSL context, there is a real need for check principal and certificates. There are ways to do this, but current jboss remoting not provide it, just provider socket remote address as sessionId. seems not enough. -- 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

13 years, 1 month

2
5
0 / 0

[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, 1 month

3
14
0 / 0

[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

13 years, 1 month

3
3
0 / 0

[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

13 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-802) TransporterHandler should not use Class.forName

by Julien Viet (JIRA)

TransporterHandler should not use Class.forName ----------------------------------------------- Key: JBREM-802 URL: http://jira.jboss.com/jira/browse/JBREM-802 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.2.1.GA, 2.2.0.SP4 Reporter: Julien Viet line: classSig[x] = Class.forName(sig[x]); should probably be replaced by classSig[x] = targetPOJO.getClass().getClassLoader().loadClass(sig[x]); to provide a correct class lookup -- 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

13 years, 1 month

4
4
0 / 0

[JBoss JIRA] Created: (JBREM-808) Remove dependencies on ObjectNameFactory from JBoss JMX

by Julien Viet (JIRA)

Remove dependencies on ObjectNameFactory from JBoss JMX ------------------------------------------------------- Key: JBREM-808 URL: http://jira.jboss.com/jira/browse/JBREM-808 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Julien Viet It happens when my POJO has not been bound on the transporter server, it looks like the transporter client is trying to do some fail over. This make JBoss Remoting depends on the JBoss JMX implementation. That makes JBoss Remoting more difficult to embed and reuse. I think that the ObjectNameFactory class could be easily ported to JBoss Remoting without any harm done. However perhaps JBoss Remoting has more dependencies on JBoss JMX that I don't know that would prevent to remove such dependency. [junit_] Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/mx/util/ObjectNameFactory [junit_] at org.jboss.remoting.transporter.InternalTransporterServices.<clinit>(InternalTransporterServices.java:41) [junit_] at org.jboss.remoting.transporter.TransporterClient.findAlternativeTarget(TransporterClient.java:330) [junit_] at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterClient.java:301) [junit_] at $Proxy0.getInfo(Unknown Source) [junit_] at org.jboss.portal.test.framework.driver.remote.RemoteTestDriverClient.getInfo(RemoteTestDriverClient.java:107) -- 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

13 years, 1 month

3
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2008