November 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-1250) Properties for each message

by Bela Ban (JIRA)

Properties for each message --------------------------- Key: JGRP-1250 URL: https://jira.jboss.org/browse/JGRP-1250 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12 JGroups already has the ability to bypass certain protocols, e.g. NO_FC set in a message bypasses any flow control layer. It would be nice to do this for other protocols, too, e.g. SEQUENCER, but this needs to be done in a generic fashion. What should be done is to use *properties*, e.g. +reliable-mcast, -frag, +flowcontrol, -bundling etc. Based on these flags, each protocol decides whether to handle (or not) a message. The properties should not take up *any* space in a message if not set. This can probably be generalized, ie. by annotating a protocol with the props it provides, e.g. @Reliable @ReliableUnicast UNICAST, and by having code which matches the flags in a message and decides whether or not to process the message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

5
11
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

13 years, 1 month

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

13 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (JBWEB-186) Using the native connector causes the JVM to crash when shutting down on Windows

by Mike Millson (JIRA)

Using the native connector causes the JVM to crash when shutting down on Windows -------------------------------------------------------------------------------- Key: JBWEB-186 URL: https://jira.jboss.org/browse/JBWEB-186 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Affects Versions: JBossWeb-3.0.0.Beta7 Reporter: Mike Millson Assignee: Remy Maucherat Boss server is crashing with an "EXCEPTION_ACCESS_VIOLATION" once shutdown has started. Setting a breakpoint in AccessLogValve.invoke() then doing shutdown, then releasing the break point crashes the JVM. The fatal error log shows the following: # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0d74c90e, pid=3204, tid=5944 # # JRE version: 6.0_20-b02 # Java VM: Java HotSpot(TM) Server VM (16.3-b01 mixed mode windows-x86 ) # Problematic frame: # C [libapr-1.dll+0xc90e] # ... Current thread (0x05973400): JavaThread "http-127.0.0.1-8080-2" daemon [_thread_in_native, id=5944, stack(0x0efe0000,0x0f030000)] ... Stack: [0x0efe0000,0x0f030000], sp=0x0f02f628, free space=13d0f02f15ck Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libapr-1.dll+0xc90e] C [libtcnative-1.dll+0x1150] j org.apache.tomcat.jni.Address.get(IJ)J+0 j org.apache.coyote.http11.Http11AprProcessor.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V+196 j org.apache.coyote.Request.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V+56 j org.apache.catalina.connector.Request.getRemoteAddr()Ljava/lang/String;+18 j org.apache.catalina.connector.Request.getRemoteHost()Ljava/lang/String;+19 j org.apache.catalina.valves.AccessLogValve$HostElement.addElement(Ljava/lang/StringBuffer;Ljava/util/Date;Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;J)V+2 j org.apache.catalina.valves.AccessLogValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+115 ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
10
0 / 0

[JBoss JIRA] Created: (JGRP-1194) Revisit implementation of TUNNEL and shared transport

by Vladimir Blagojevic (JIRA)

Revisit implementation of TUNNEL and shared transport ----------------------------------------------------- Key: JGRP-1194 URL: https://jira.jboss.org/jira/browse/JGRP-1194 Project: JGroups Issue Type: Task Affects Versions: 2.9, 2.8 Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 3.0 TUNNEL and shared transport are not supported at the moment (2.10.Alpha5). The main complexity behind TUNNEL and shared transport is that we have to change StubReceiver model. StubReceiver reads messages of the socket on the TUNNEL side. With shared transport turned on StubReceiver would have to be changed because we are receiving byte arrays for all channels sharing transport. We need some special StubReceiver multiplexer so to speak which will read messages and then pass off the byte arrays to other Receivers which will in turn pass them as messages to appropriate channel above transport. Each byte array passed around have to be pre appended with some identifier....and so on. -- 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

4
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: (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

13 years, 1 month

3
8
0 / 0

[JBoss JIRA] Created: (JGRP-1225) Removed BasicConnectionTable

by Bela Ban (JIRA)

Removed BasicConnectionTable ---------------------------- Key: JGRP-1225 URL: https://jira.jboss.org/browse/JGRP-1225 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.0 Currently still used by TCP_NIO (ConnectionTableNIO). When we move to NIO2, we can drop this class, as it will be obsolete -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2010