March 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-552) cannot init cause of ClassCastException

by John Mazzitelli (JIRA)

cannot init cause of ClassCastException --------------------------------------- Key: JBREM-552 URL: http://jira.jboss.com/jira/browse/JBREM-552 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.Beta2 (Boon) Reporter: John Mazzitelli Assigned To: Tom Elrod Priority: Minor Fix For: 2.0.0.CR1 (Boon) I'm in a catch clause within InvokerRegistry and I'm getting a weird exception thrown: java.lang.IllegalStateException: Can't overwrite cause at java.lang.Throwable.initCause(Throwable.java:320) at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:447) at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:324) at org.jboss.remoting.Client.connect(Client.java:385) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.getRemotingClient(JBossRemotingRemoteCommunicator.java:470) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.send(JBossRemotingRemoteCommunicator.java:430) at org.jboss.on.communications.command.client.AbstractCommandClient.invoke(AbstractCommandClient.java:167) at org.jboss.on.communications.command.client.ClientCommandSender.send(ClientCommandSender.java:820) at org.jboss.on.communications.command.client.ServerPollingThread.run(ServerPollingThread.java:102) Look at line 447 and you'll see it is trying to init the cause of a ClassNotFoundException. Running in a debugger, the newly constructed exception created on 446 has a null cause. Looking then at Throwable.initCause and you'll see a null cause causes this IllegalStateException to be thrown. The cause needs to be "this", not null (I don't know why, seems like it should also look for null, but whatever - that's the way the JDK is written). The fix is simple - use the constructor that takes a throwable as its second parameter. Not sure why initCause it being used, as opposed to this constructor. e.g.: new ClassNotFoundException("Can not invoke loadClientInvokerClass method on " + transportFactoryClass, e); (notice the ", e" parameter). There are three other instances where initCause is called on ClassNotFoundException that also need to be fixed. See the other catch clauses in here. -- 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

14 years, 5 months

5
5
0 / 0

[JBoss JIRA] Created: (SECURITY-176) Implement JBossRequestContext.asElement(Document)

by Anil Saldhana (JIRA)

Implement JBossRequestContext.asElement(Document) ------------------------------------------------- Key: SECURITY-176 URL: http://jira.jboss.com/jira/browse/SECURITY-176 Project: JBoss Security and Identity Management Issue Type: 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 If provided a Document, then create an element with the request details. Pretty cumbersome process. -- 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

14 years, 5 months

4
4
0 / 0

[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

14 years, 5 months

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

14 years, 5 months

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

14 years, 5 months

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

14 years, 5 months

2
10
0 / 0

[JBoss JIRA] Created: (JGRP-886) TCP: single implementation based on NIO

by Bela Ban (JIRA)

TCP: single implementation based on NIO --------------------------------------- Key: JGRP-886 URL: https://jira.jboss.org/jira/browse/JGRP-886 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Merge TCP and TCP_NIO into one protocol. Adapt it to use NIO2 (when available). -- 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

14 years, 5 months

3
8
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

14 years, 5 months

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

14 years, 5 months

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

14 years, 5 months

3
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2009