[JBoss JIRA] (JGRP-2218) New payload interface
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2218?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2218:
---------------------------
Description:
h3. Goal
Change payload in {{Message}} from byte[] arrays to a {{Payload}} interface which can have multiple implementations.
h3. Reason
Currently, having to pass a byte[] array to a message leads to unnecessary copying:
* When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
* When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
* When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. With the suggested {{ObjectBuffer}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating the byte[] array allocation made by the application.
h3. Design
Instead of copying, the application creates an instance of {{Payload}} and sets the payload in {{Message}}. The {{Payload}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of payload implementations, e.g.
* {{ArrayPayload}}: wraps a byte[] array with an offset and length
* {{NioDirectPayload}}: wraps an NIO direct {{ByteBuffer}}
* {{NioHeapPayload}}: wraps an NIO heap-based {{ByteBuffer}}
* {{CompositePayload}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
* {{IntPayload}}: a single integer
* {{ObjectPayload}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in payloads and they're only marshalled at the end (transport).
* {{PartialPayload}}: a ref to a {{Payload}}, with an offset and length
The {{Payload}} interface has methods:
* {{size()}}
* {{writeTo(DataOutput)}}
* {{readFrom(DataInput)}}
* {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying payload
and possibly also
* {{acquire()}} and
* {{release()}} (for ref-counting)
* {{copy()}}
Each payload impl has an ID and it should be possible to register new impls. A {{PayloadFactory}} maintains a mapping between IDs and impl classes.
When marshalling a {{Payload}}, the ID is written first, followed by the payload's {{writeTo()}} method. When reading payloads, the {{PayloadFactory}} is used to create instances from IDs.
h4. Fragmentation
When fragmenting a buffer, the fragments are instances of {{PartialPayload}} which maintains an offset and length over an underlying payload. When marshalling a {{PartialPayload}}, only the part between offset and offset+length is written to the output stream.
h4. Reference counting
If we implement ref-counting, then payloads can be reused as soon as the ref-count is 0. For example, when sending a message, the payload's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the payload cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the payload cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
h4. Payload management
When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{PayloadManagement}} (or {{PayloadPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of payloads.
The {{PayloadManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of payloads: thus the creation of buffers by the application and of payloads received over the network can be controlled by the same payload management impl.
h4. Misc
* Since this issue includes API changes, the version will be 5.0
was:
h3. Goal
Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations.
h3. Reason
Currently, having to pass a byte[] array to a message leads to unnecessary copying:
* When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
* When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
* When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. With the suggested {{ObjectBuffer}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating the byte[] array allocation made by the application.
h3. Design
Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g.
* {{ArrayBuffer}}: wraps a byte[] array with an offset and length
* {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}}
* {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}}
* {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
* {{IntBuffer}}: a single integer
* {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport).
* {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length
The {{Buffer}} interface has methods:
* {{size()}}
* {{writeTo(DataOutput)}}
* {{readFrom(DataInput)}}
* {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer
and possibly also
* {{acquire()}} and
* {{release()}} (for ref-counting)
* {{copy()}}
Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes.
When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs.
h4. Fragmentation
When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream.
h4. Reference counting
If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
h4. Buffer management
When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers.
The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl.
h4. Misc
* Since this issue includes API changes, the version will be 5.0
> New payload interface
> ---------------------
>
> Key: JGRP-2218
> URL: https://issues.jboss.org/browse/JGRP-2218
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> h3. Goal
> Change payload in {{Message}} from byte[] arrays to a {{Payload}} interface which can have multiple implementations.
> h3. Reason
> Currently, having to pass a byte[] array to a message leads to unnecessary copying:
> * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
> * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
> * When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. With the suggested {{ObjectBuffer}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating the byte[] array allocation made by the application.
> h3. Design
> Instead of copying, the application creates an instance of {{Payload}} and sets the payload in {{Message}}. The {{Payload}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of payload implementations, e.g.
> * {{ArrayPayload}}: wraps a byte[] array with an offset and length
> * {{NioDirectPayload}}: wraps an NIO direct {{ByteBuffer}}
> * {{NioHeapPayload}}: wraps an NIO heap-based {{ByteBuffer}}
> * {{CompositePayload}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
> * {{IntPayload}}: a single integer
> * {{ObjectPayload}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in payloads and they're only marshalled at the end (transport).
> * {{PartialPayload}}: a ref to a {{Payload}}, with an offset and length
> The {{Payload}} interface has methods:
> * {{size()}}
> * {{writeTo(DataOutput)}}
> * {{readFrom(DataInput)}}
> * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying payload
> and possibly also
> * {{acquire()}} and
> * {{release()}} (for ref-counting)
> * {{copy()}}
> Each payload impl has an ID and it should be possible to register new impls. A {{PayloadFactory}} maintains a mapping between IDs and impl classes.
> When marshalling a {{Payload}}, the ID is written first, followed by the payload's {{writeTo()}} method. When reading payloads, the {{PayloadFactory}} is used to create instances from IDs.
> h4. Fragmentation
> When fragmenting a buffer, the fragments are instances of {{PartialPayload}} which maintains an offset and length over an underlying payload. When marshalling a {{PartialPayload}}, only the part between offset and offset+length is written to the output stream.
> h4. Reference counting
> If we implement ref-counting, then payloads can be reused as soon as the ref-count is 0. For example, when sending a message, the payload's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the payload cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the payload cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
> h4. Payload management
> When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{PayloadManagement}} (or {{PayloadPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of payloads.
> The {{PayloadManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of payloads: thus the creation of buffers by the application and of payloads received over the network can be controlled by the same payload management impl.
> h4. Misc
> * Since this issue includes API changes, the version will be 5.0
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-2218) New payload interface
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2218?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2218:
---------------------------
Summary: New payload interface (was: New buffers)
> New payload interface
> ---------------------
>
> Key: JGRP-2218
> URL: https://issues.jboss.org/browse/JGRP-2218
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> h3. Goal
> Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations.
> h3. Reason
> Currently, having to pass a byte[] array to a message leads to unnecessary copying:
> * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
> * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
> * When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. With the suggested {{ObjectBuffer}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating the byte[] array allocation made by the application.
> h3. Design
> Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g.
> * {{ArrayBuffer}}: wraps a byte[] array with an offset and length
> * {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}}
> * {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}}
> * {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
> * {{IntBuffer}}: a single integer
> * {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport).
> * {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length
> The {{Buffer}} interface has methods:
> * {{size()}}
> * {{writeTo(DataOutput)}}
> * {{readFrom(DataInput)}}
> * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer
> and possibly also
> * {{acquire()}} and
> * {{release()}} (for ref-counting)
> * {{copy()}}
> Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes.
> When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs.
> h4. Fragmentation
> When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream.
> h4. Reference counting
> If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
> h4. Buffer management
> When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers.
> The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl.
> h4. Misc
> * Since this issue includes API changes, the version will be 5.0
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-2218) New buffers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2218?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2218:
---------------------------
Description:
h3. Goal
Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations.
h3. Reason
Currently, having to pass a byte[] array to a message leads to unnecessary copying:
* When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
* When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
* When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. With the suggested {{ObjectBuffer}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating the byte[] array allocation made by the application.
h3. Design
Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g.
* {{ArrayBuffer}}: wraps a byte[] array with an offset and length
* {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}}
* {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}}
* {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
* {{IntBuffer}}: a single integer
* {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport).
* {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length
The {{Buffer}} interface has methods:
* {{size()}}
* {{writeTo(DataOutput)}}
* {{readFrom(DataInput)}}
* {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer
and possibly also
* {{acquire()}} and
* {{release()}} (for ref-counting)
* {{copy()}}
Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes.
When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs.
h4. Fragmentation
When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream.
h4. Reference counting
If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
h4. Buffer management
When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers.
The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl.
h4. Misc
* Since this issue includes API changes, the version will be 5.0
was:
h3. Goal
Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations.
h3. Reason
Currently, having to pass a byte[] array to a message leads to unnecessary copying:
* When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
* When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
* When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. When sending, a new byte[] array is created (second allocation and the application's payload plus JGroups metadata (headers etc) is copied into the new array. With the suggested {{ObjectBuffer}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating 2 byte[] array allocations.
h3. Design
Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g.
* {{ArrayBuffer}}: wraps a byte[] array with an offset and length
* {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}}
* {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}}
* {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
* {{IntBuffer}}: a single integer
* {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport).
* {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length
The {{Buffer}} interface has methods:
* {{size()}}
* {{writeTo(DataOutput)}}
* {{readFrom(DataInput)}}
* {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer
and possibly also
* {{acquire()}} and
* {{release()}} (for ref-counting)
* {{copy()}}
Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes.
When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs.
h4. Fragmentation
When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream.
h4. Reference counting
If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
h4. Buffer management
When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers.
The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl.
h4. Misc
* Since this issue includes API changes, the version will be 5.0
> New buffers
> -----------
>
> Key: JGRP-2218
> URL: https://issues.jboss.org/browse/JGRP-2218
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> h3. Goal
> Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations.
> h3. Reason
> Currently, having to pass a byte[] array to a message leads to unnecessary copying:
> * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
> * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
> * When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. With the suggested {{ObjectBuffer}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating the byte[] array allocation made by the application.
> h3. Design
> Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g.
> * {{ArrayBuffer}}: wraps a byte[] array with an offset and length
> * {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}}
> * {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}}
> * {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
> * {{IntBuffer}}: a single integer
> * {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport).
> * {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length
> The {{Buffer}} interface has methods:
> * {{size()}}
> * {{writeTo(DataOutput)}}
> * {{readFrom(DataInput)}}
> * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer
> and possibly also
> * {{acquire()}} and
> * {{release()}} (for ref-counting)
> * {{copy()}}
> Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes.
> When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs.
> h4. Fragmentation
> When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream.
> h4. Reference counting
> If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
> h4. Buffer management
> When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers.
> The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl.
> h4. Misc
> * Since this issue includes API changes, the version will be 5.0
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-2218) New buffers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2218?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2218:
---------------------------
Description:
h3. Goal
Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations.
h3. Reason
Currently, having to pass a byte[] array to a message leads to unnecessary copying:
* When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
* When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
* When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. When sending, a new byte[] array is created (second allocation and the application's payload plus JGroups metadata (headers etc) is copied into the new array. With the suggested {{ObjectBuffer}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating 2 byte[] array allocations.
h3. Design
Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g.
* {{ArrayBuffer}}: wraps a byte[] array with an offset and length
* {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}}
* {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}}
* {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
* {{IntBuffer}}: a single integer
* {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport).
* {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length
The {{Buffer}} interface has methods:
* {{size()}}
* {{writeTo(DataOutput)}}
* {{readFrom(DataInput)}}
* {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer
and possibly also
* {{acquire()}} and
* {{release()}} (for ref-counting)
* {{copy()}}
Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes.
When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs.
h4. Fragmentation
When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream.
h4. Reference counting
If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
h4. Buffer management
When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers.
The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl.
h4. Misc
* Since this issue includes API changes, the version will be 5.0
was:
h3. Goal
Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations.
h3. Motivation
Currently, having to pass a byte[] array to a message leads to unnecessary copying:
* When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
* When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
h3. Design
Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g.
* {{ArrayBuffer}}: wraps a byte[] array with an offset and length
* {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}}
* {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}}
* {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
* {{IntBuffer}}: a single integer
* {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport).
* {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length
The {{Buffer}} interface has methods:
* {{size()}}
* {{writeTo(DataOutput)}}
* {{readFrom(DataInput)}}
* {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer
and possibly also
* {{acquire()}} and
* {{release()}} (for ref-counting)
* {{copy()}}
Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes.
When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs.
h4. Fragmentation
When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream.
h4. Reference counting
If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
h4. Buffer management
When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers.
The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl.
h4. Misc
* Since this issue includes API changes, the version will be 5.0
> New buffers
> -----------
>
> Key: JGRP-2218
> URL: https://issues.jboss.org/browse/JGRP-2218
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> h3. Goal
> Change payload in {{Message}} from byte[] arrays to a {{Buffer}} interface which can have multiple implementations.
> h3. Reason
> Currently, having to pass a byte[] array to a message leads to unnecessary copying:
> * When an application has a ref to an NIO (direct) {{ByteBuffer}}, the bytes in the byte buffer have to be copied into a byte[] array and then set in the message
> * When the application sends around byte[] arrays, but also wants to add some additional metadata, e.g. type (1000-byte requests/responses), it needs to create a new byte[] array of (say) 1001 bytes and copy the data (1000 bytes) plus the request type (1 byte) into the new copy. Example: {{MPerf}} and {{UPerf}}
> * When an object has to be sent (e.g. in Infinispan), the object has to be marshalled into a byte[] array (first allocation) and then added to the message. When sending, a new byte[] array is created (second allocation and the application's payload plus JGroups metadata (headers etc) is copied into the new array. With the suggested {{ObjectBuffer}} (below), marshalling of the object would occur late, and it would be marshalled directly into the output stream of the bundler, eliminating 2 byte[] array allocations.
> h3. Design
> Instead of copying, the application creates an instance of {{Buffer}} and sets the buffer in {{Message}}. The {{Buffer}} is then passed all the way down into the transport where it is marshalled and sent. There can be a number of buffer implementations, e.g.
> * {{ArrayBuffer}}: wraps a byte[] array with an offset and length
> * {{NioDirectBuffer}}: wraps an NIO direct {{ByteBuffer}}
> * {{NioHeapBuffer}}: wraps an NIO heap-based {{ByteBuffer}}
> * {{CompositeBuffer}}: wraps multiple Buffers. E.g. type (1 byte) and data (1000 bytes) as described above
> * {{IntBuffer}}: a single integer
> * {{ObjectBuffer}}: has an Object and a ClassLoader (for reading), plus a Marshaller which know how to marshal the object, this allows for objects to be passed in buffers and they're only marshalled at the end (transport).
> * {{PartialBuffer}}: a ref to a {{Buffer}}, with an offset and length
> The {{Buffer}} interface has methods:
> * {{size()}}
> * {{writeTo(DataOutput)}}
> * {{readFrom(DataInput)}}
> * {{getInput()}}: this provides a {{DataInput}} stream for reading from the underlying buffer
> and possibly also
> * {{acquire()}} and
> * {{release()}} (for ref-counting)
> * {{copy()}}
> Each buffer impl has an ID and it should be possible to register new impls. A {{BufferFactory}} maintains a mapping between IDs and impl classes.
> When marshalling a {{Buffer}}, the ID is written first, followed by the buffer's {{writeTo()}} method. When reading buffers, the {{BufferFactory}} is used to create instances from IDs.
> h4. Fragmentation
> When fragmenting a buffer, the fragments are instances of {{PartialBuffer}} which maintains an offset and length over an underlying buffer. When marshalling a {{PartialBuffer}}, only the part between offset and offset+length is written to the output stream.
> h4. Reference counting
> If we implement ref-counting, then buffers can be reused as soon as the ref-count is 0. For example, when sending a message, the buffer's ref-count could be incremented by the app calling {{acquire()}}. (Assuming the message is a unicast message), {{UNICAST3}} would increment the count to 2. This is needed because {{UNICAST3}} might have to retransmit the message if it was lost on the network, and meanwhile the buffer cannot be reused (changed). The app calls {{release()}} when the {{JChannel.send()}} call returns, but the buffer cannot be reused until {{UNICAST3}} calls {{release()}} as well. This will happen when an {{ACK}} for the given message has been received.
> h4. Buffer management
> When a request is received, the buffer is created from the bytes received on the network, based on the ID. This should be done by asking a {{BufferManagement}} (or {{BufferPool}} component for a new buffer. A naive implementation might create a new buffer every time, and more sophisticated one might use a pool of buffers.
> The {{BufferManagement}} instance could be replaced by one's own implementation; this allows for an application to control the lifecycle of buffers: thus the creation of buffers by the application and of buffers received over the network can be controlled by the same buffer management impl.
> h4. Misc
> * Since this issue includes API changes, the version will be 5.0
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9227) XA-Datasources not shown in admin console when using expressions (${some.thing}) in xml config
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9227?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9227:
----------------------------------------
What does the CLI show when you do this?
/subsystem=datasources:read-resource(recursive=true)
> XA-Datasources not shown in admin console when using expressions (${some.thing}) in xml config
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-9227
> URL: https://issues.jboss.org/browse/WFLY-9227
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Web Console
> Affects Versions: 10.1.0.Final
> Reporter: Marius Schmidt
> Assignee: Brian Stansberry
> Priority: Minor
>
> I expected the this to work, but I does not seem to:
> {noformat}
> GIVEN a Wildfly 10.1.0.Final subsystem datasources configuration as
> <subsystem xmlns="urn:jboss:domain:datasources:4.0">
> <datasources>
> <xa-datasource jndi-name="java:/datasources/SOURCE" pool-name="SOURCE" enabled="${source.db.enabled:false}">
> <xa-datasource-property name="URL">
> ${source.db.url:undefined}
> </xa-datasource-property>
> <driver>OracleJDBCDriver</driver>
> <xa-pool>
> <min-pool-size>0</min-pool-size>
> <max-pool-size>10</max-pool-size>
> <is-same-rm-override>false</is-same-rm-override>
> <no-tx-separate-pools>true</no-tx-separate-pools>
> </xa-pool>
> <security>
> <user-name>${source.db.user:user}</user-name>
> <password>${source.db.password:password}</password>
> </security>
> <recovery no-recovery="true"/>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/>
> <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/>
> </validation>
> </xa-datasource>
> </datasources>
> <drivers>
> <driver name="h2" module="com.h2database.h2">
> <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
> </driver>
> <driver name="OracleJDBCDriver" module="com.oracle.ojdbc7">
> <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
> </driver>
> </drivers>
> </subsystem>
> AND a /full/path/to/file.properties file fitting a database connection, containing
> source.db.enabled=true
> source.db.url=jdbc:oracle:thin:@sample.de:1521:MY_SID
> source.db.user=USER
> source.db.password=PASSWORD
> WHEN the server is started with --properties=/full/path/to/file.properties
> THEN the webadmin console shows the xa-datasource SOURCE within the datasources subsytem
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-54) ConcurrentModificationException in ConfigAdminService
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-54?page=com.atlassian.jira.plugin.sy... ]
Brian Stansberry reopened WFLY-54:
----------------------------------
> ConcurrentModificationException in ConfigAdminService
> -----------------------------------------------------
>
> Key: WFLY-54
> URL: https://issues.jboss.org/browse/WFLY-54
> Project: WildFly
> Issue Type: Bug
> Components: ConfigAdmin, OSGi
> Reporter: Thomas Diesler
> Assignee: Brian Stansberry
> Fix For: 8.0.0.Alpha1
>
>
> {code}
> 12:07:46,616 ERROR [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011026: Framework Error: org.osgi.framework.BundleException: JBOSGI011254: Cannot start bundle: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT
> at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:110) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.as.osgi.service.BundleLifecycleIntegration.start(BundleLifecycleIntegration.java:167)
> at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:292) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:228) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:522) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.DefaultStartLevelPlugin.increaseStartLevel(DefaultStartLevelPlugin.java:265) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.FrameworkActive.start(FrameworkActive.java:131) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> Caused by: java.util.ConcurrentModificationException
> at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:373) [rt.jar:1.6.0_37]
> at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:384) [rt.jar:1.6.0_37]
> at org.jboss.as.configadmin.service.ConfigAdminServiceImpl.addListener(ConfigAdminServiceImpl.java:249)
> at org.jboss.as.osgi.configadmin.DomainModelPersistenceManager.start(DomainModelPersistenceManager.java:68)
> at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:84) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-54) ConcurrentModificationException in ConfigAdminService
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-54?page=com.atlassian.jira.plugin.sy... ]
Brian Stansberry updated WFLY-54:
---------------------------------
Component/s: (was: ConfigAdmin)
> ConcurrentModificationException in ConfigAdminService
> -----------------------------------------------------
>
> Key: WFLY-54
> URL: https://issues.jboss.org/browse/WFLY-54
> Project: WildFly
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Brian Stansberry
> Fix For: 8.0.0.Alpha1
>
>
> {code}
> 12:07:46,616 ERROR [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011026: Framework Error: org.osgi.framework.BundleException: JBOSGI011254: Cannot start bundle: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT
> at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:110) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.as.osgi.service.BundleLifecycleIntegration.start(BundleLifecycleIntegration.java:167)
> at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:292) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:228) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:522) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.DefaultStartLevelPlugin.increaseStartLevel(DefaultStartLevelPlugin.java:265) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.FrameworkActive.start(FrameworkActive.java:131) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> Caused by: java.util.ConcurrentModificationException
> at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:373) [rt.jar:1.6.0_37]
> at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:384) [rt.jar:1.6.0_37]
> at org.jboss.as.configadmin.service.ConfigAdminServiceImpl.addListener(ConfigAdminServiceImpl.java:249)
> at org.jboss.as.osgi.configadmin.DomainModelPersistenceManager.start(DomainModelPersistenceManager.java:68)
> at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:84) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-54) ConcurrentModificationException in ConfigAdminService
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-54?page=com.atlassian.jira.plugin.sy... ]
Brian Stansberry resolved WFLY-54.
----------------------------------
Resolution: Done
> ConcurrentModificationException in ConfigAdminService
> -----------------------------------------------------
>
> Key: WFLY-54
> URL: https://issues.jboss.org/browse/WFLY-54
> Project: WildFly
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Brian Stansberry
> Fix For: 8.0.0.Alpha1
>
>
> {code}
> 12:07:46,616 ERROR [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011026: Framework Error: org.osgi.framework.BundleException: JBOSGI011254: Cannot start bundle: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT
> at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:110) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.as.osgi.service.BundleLifecycleIntegration.start(BundleLifecycleIntegration.java:167)
> at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:292) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:228) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:522) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.DefaultStartLevelPlugin.increaseStartLevel(DefaultStartLevelPlugin.java:265) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.osgi.framework.internal.FrameworkActive.start(FrameworkActive.java:131) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> Caused by: java.util.ConcurrentModificationException
> at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:373) [rt.jar:1.6.0_37]
> at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:384) [rt.jar:1.6.0_37]
> at org.jboss.as.configadmin.service.ConfigAdminServiceImpl.addListener(ConfigAdminServiceImpl.java:249)
> at org.jboss.as.osgi.configadmin.DomainModelPersistenceManager.start(DomainModelPersistenceManager.java:68)
> at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:84) [jbosgi-framework-core-2.0.1.Final.jar:2.0.1.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-272) Internal/Redundant information stored in Domain Model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-272?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated WFLY-272:
----------------------------------
Component/s: OSGi
(was: ConfigAdmin)
> Internal/Redundant information stored in Domain Model
> -----------------------------------------------------
>
> Key: WFLY-272
> URL: https://issues.jboss.org/browse/WFLY-272
> Project: WildFly
> Issue Type: Feature Request
> Components: OSGi
> Reporter: Thomas Diesler
>
> Only property 'foo' should show up in the model. Property service.pid is redundant, service.bundleLocation,.org.jboss.source is for internal use only and should not survive shutdown
> {code}
> <configuration pid="org.jboss.as.test.integration.osgi.api.ConfiguredService">
> <property name="service.pid" value="org.jboss.as.test.integration.osgi.api.ConfiguredService"/>
> <property name="service.bundleLocation" value="config-admin-bundle-a"/>
> <property name="foo" value="bar"/>
> <property name=".org.jboss.source" value="notfromdmr"/>
> </configuration>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months