[JBoss JIRA] (WFCORE-3293) Transformers logging duplicate messages when managing mixed domain
by Ken Wills (JIRA)
Ken Wills created WFCORE-3293:
---------------------------------
Summary: Transformers logging duplicate messages when managing mixed domain
Key: WFCORE-3293
URL: https://issues.jboss.org/browse/WFCORE-3293
Project: WildFly Core
Issue Type: Task
Reporter: Ken Wills
When a WF11 HC is managing an earlier WF slave the logs have a lot of repeated messages, during for example a profile clone:
{code}
Nothing logged at all on slave.
DC has:
[domain@localhost:9999 /] /profile=full:clone(to-profile=test1)
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "WFLYDC0021: Unexplained failure"},
"rolled-back" => true
}
[Host Controller] 13:26:19,084 WARN [org.wildfly.iiop.openjdk] (management-handler-thread - 2) WFLYIIOP0111: SSL has not been configured but ssl-port property has been specified - the connection will use clear-text protocol
[Host Controller] 13:26:19,102 WARN [org.jboss.as.controller.transformer.slave] (management-handler-thread - 2) WFLYCTL0032: There were problems during the transformation process for target host: 'slave'
[Host Controller] Problems found:
[Host Controller] [ WFLYCTL0303: Resource [
[Host Controller] ("profile" => "default"),
[Host Controller] ("subsystem" => "remoting"),
[Host Controller] ("configuration" => "endpoint")
[Host Controller] ] is rejected on the target host, and will need to be ignored on the host
[Host Controller] , java.lang.Thread.getStackTrace(Thread.java:1559)
[Host Controller] org.jboss.as.controller.transform.description.TransformingDescription.transformResource(TransformingDescription.java:145)
[Host Controller] org.jboss.as.controller.transform.ResourceTransformationContextImpl.processChild(ResourceTransformationContextImpl.java:297)
[Host Controller] org.jboss.as.controller.transform.ResourceTransformationContextImpl.processChildren(ResourceTransformationContextImpl.java:262)
[Host Controller] org.jboss.as.controller.transform.ResourceTransformer$1.transformResource(ResourceTransformer.java:54)
[Host Controller] org.jboss.as.controller.transform.description.TransformingDescription$3.invokeNext(TransformingDescription.java:167)
[Host Controller] org.jboss.as.controller.transform.description.AttributeTransformationRule.transformResource(AttributeTransformationRule.java:103)
[Host Controller] org.jboss.as.controller.transform.description.TransformingDescription.transformResource(TransformingDescription.java:173)
[Host Controller] org.jboss.as.controller.transform.description.ChainedTransformingDescription.transformResource(ChainedTransformingDescription.java:122)
[Host Controller] org.jboss.as.controller.transform.ResourceTransformationContextImpl.processChild(ResourceTransformationContextImpl.java:297)
[Host Controller] org.jboss.as.controller.transform.ResourceTransformationContextImpl.processChildren(ResourceTransformationContextImpl.java:262)
[Host Controller] org.jboss.as.controller.transform.ResourceTransformer$1.transformResource(ResourceTransformer.java:54)
[Host Controller] org.jboss.as.controller.transform.description.TransformingDescription$3.invokeNext(TransformingDescription.java:167)
[Host Controller] org.jboss.as.controller.transform.description.AttributeTransformationRule.transformResource(AttributeTransformationRule.java:103)
[Host Controller] org.jboss.as.controller.transform.description.TransformingDescription.transformResource(TransformingDescription.java:173)
[Host Controller] org.jboss.as.controller.transform.ResourceTransformationContextImpl.processChild(ResourceTransformationContextImpl.java:297)
[Host Controller] org.jboss.as.controller.transform.ResourceTransformationContextImpl.processChildren(ResourceTransformationContextImpl.java:262)
[Host Controller] org.jboss.as.controller.transform.ResourceTransformer$1.transformResource(ResourceTransformer.java:54)
[Host Controller] org.jboss.as.controller.transform.TransformersImpl.transformRootResource(TransformersImpl.java:134)
[Host Controller] org.jboss.as.domain.controller.operations.ReadMasterDomainModelUtil.readMasterDomainResourcesForInitialConnect(ReadMasterDomainModelUtil.java:89)
[Host Controller] org.jboss.as.domain.controller.operations.ReadDomainModelHandler.execute(ReadDomainModelHandler.java:56)
[Host Controller] org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:980)
[Host Controller] org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
[Host Controller] org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
[Host Controller] org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
[Host Controller] org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
[Host Controller] org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:490)
[Host Controller] org.jboss.as.host.controller.DomainModelControllerService.access$1100(DomainModelControllerService.java:200)
[Host Controller] org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor$1.lambda$apply$0(DomainModelControllerService.java:1372)
[Host Controller] org.jboss.as.controller.access.InVmAccess.runInVm(InVmAccess.java:63)
[Host Controller] org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor$1.apply(DomainModelControllerService.java:1372)
[Host Controller] org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor$1.apply(DomainModelControllerService.java:1369)
[Host Controller] org.jboss.as.host.controller.SecurityActions$Execution$1.execute(SecurityActions.java:77)
[Host Controller] org.jboss.as.host.controller.SecurityActions.privilegedExecution(SecurityActions.java:47)
[Host Controller] org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1375)
[Host Controller] org.jboss.as.host.controller.mgmt.HostControllerRegistrationHandler$RegistrationContext.processRegistration(HostControllerRegistrationHandler.java:487)
[Host Controller] org.jboss.as.host.controller.mgmt.HostControllerRegistrationHandler$RegistrationContext.access$400(HostControllerRegistrationHandler.java:394)
[Host Controller] org.jboss.as.host.controller.mgmt.HostControllerRegistrationHandler$InitiateRegistrationHandler$1.execute(HostControllerRegistrationHandler.java:254)
[Host Controller] org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
[Host Controller] org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
[Host Controller] java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[Host Controller] java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[Host Controller] java.lang.Thread.run(Thread.java:748)
[Host Controller] org.jboss.threads.JBossThread.run(JBossThread.java:320)
[Host Controller]
[Host Controller] , WFLYCTL0303: Resource [
[Host Controller] ("profile" => "ha"),
[Host Controller] ("subsystem" => "remoting"),
[Host Controller] ("configuration" => "endpoint")
[Host Controller] ] is rejected on the target host, and will need to be ignored on the host
[Host Controller] , WFLYCTL0303: Resource [
[Host Controller] ("profile" => "full"),
[Host Controller] ("subsystem" => "remoting"),
[Host Controller] ("configuration" => "endpoint")
[Host Controller] ] is rejected on the target host, and will need to be ignored on the host
[Host Controller] , WFLYCTL0303: Resource [
[Host Controller] ("profile" => "full-ha"),
[Host Controller] ("subsystem" => "remoting"),
[Host Controller] ("configuration" => "endpoint")
[Host Controller] ] is rejected on the target host, and will need to be ignored on the host
[Host Controller] ]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1516) GAV names are not coming properly when running the tomcat as Service
by CasterJose CasterJose (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1516?page=com.atlassian.jira.plugi... ]
CasterJose CasterJose commented on DROOLS-1516:
-----------------------------------------------
The "{color:#d04437}repository.getM2RepositoryDir(ArtifactRepositoryService.GLOBAL_M2_REPO_NAME);{color}" in method {color:#14892c}getJarPath(final String path, final String separator){color} in class M2RepoServiceImpl adds a "{color:#205081}/{color}" to de repositorie path.
Found a workaround to solve this for now. That is{color:#14892c} String jarPath = path.substring(pathToDir.length() + 0);{color} instead of {color:#d04437}String jarPath = path.substring(pathToDir.length() + 1);{color}
> GAV names are not coming properly when running the tomcat as Service
> --------------------------------------------------------------------
>
> Key: DROOLS-1516
> URL: https://issues.jboss.org/browse/DROOLS-1516
> Project: Drools
> Issue Type: Bug
> Components: build, kie server, tools
> Affects Versions: 6.5.0.Final
> Environment: Windows
> Reporter: Arunraj SRM
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: Drools, GAV,, Maven
> Attachments: gav_issue.png
>
>
> Deploy Drools Work Bench and KIE Server in Tomcat Server configured with SSL and started via service. All the artifacts populated under the GAV are displaying as
> <undetermined>:<undetermined>:<undetermined>
> instead of actual path including the guvnor
> Start-up values:
> -Dcatalina.home=C:\apache-tomcat-9.0.0.M19
> -Dcatalina.base=C:\apache-tomcat-9.0.0.M19
> -Djava.io.tmpdir=C:\apache-tomcat-9.0.0.M19\temp
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djava.util.logging.config.file=C:\apache-tomcat-9.0.0.M19\conf\logging.properties
> -Xmx256M
> -XX:MaxPermSize=2048m
> -Dbtm.root=C:\apache-tomcat-9.0.0.M19\
> -Dbitronix.tm.configuration=C:\apache-tomcat-9.0.0.M19\conf\btm-config.properties
> -Dbitronix.tm.resource.configuration=C:\apache-tomcat-9.0.0.M19\conf\resources.properties
> -Djbpm.tsr.jndi.lookup=java:comp/env/TransactionSynchronizationRegistry
> -Djava.security.auth.login.config=C:\apache-tomcat-9.0.0.M19\webapps\kie-wb\WEB-INF\classes\login.config
> -Dorg.jboss.logging.provider=jdk
> -Dorg.jbpm.cdi.bm=java:comp/env/BeanManager
> -Dorg.kie.server.persistence.ds=java:comp/env/jdbc/jbpm
> -Dorg.kie.server.persistence.tm=org.hibernate.service.jta.platform.internal.BitronixJtaPlatform
> -Dorg.uberfire.nio.git.dir=C:\drools\repositories\git\
> -Dorg.guvnor.m2repo.dir=C:\drools\repositories\kie\
> -Dorg.uberfire.metadata.index.dir=C:\drools\runtime\
> -Dorg.uberfire.nio.git.ssh.cert.dir=C:\drools\runtime\
> -Dorg.kie.demo=false
> -Dorg.kie.example=false
> -Dorg.kie.server.id=default-kieserver
> -Dorg.kie.server.location=https://localhost/kie-server/services/rest/server
> -Dorg.kie.server.controller=https://localhost/kie-wb/rest/controller
> -Dorg.jbpm.server.ext.disabled=true
> -Dorg.drools.server.filter.classes=true
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3292) The wildfly-config.xml defined in controller tests and protocol tests use invalid remoting attributes
by James Perkins (JIRA)
James Perkins created WFCORE-3292:
-------------------------------------
Summary: The wildfly-config.xml defined in controller tests and protocol tests use invalid remoting attributes
Key: WFCORE-3292
URL: https://issues.jboss.org/browse/WFCORE-3292
Project: WildFly Core
Issue Type: Bug
Components: Test Suite
Reporter: James Perkins
Assignee: James Perkins
The {{wildfly-config.xml}} configurations for tests in the controller and protocol modules use invalid attributes for remoting 5.
{code:xml}
<configuration>
<endpoint name="test-endpoint" xmlns="urn:jboss-remoting:5.0">
<connections>
<connection uri="remote://localhost:32123" immediate="true"/>
</connections>
</endpoint>
</configuration>
{code}
The {{uri}} and {{immediate}} attributes are not valid for a {{connection}} element type.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1729) Unable to load rule with global variables via kiescanner.
by Pedro Almeida (JIRA)
Pedro Almeida created DROOLS-1729:
-------------------------------------
Summary: Unable to load rule with global variables via kiescanner.
Key: DROOLS-1729
URL: https://issues.jboss.org/browse/DROOLS-1729
Project: Drools
Issue Type: Bug
Affects Versions: 6.5.0.Final
Reporter: Pedro Almeida
Assignee: Edson Tirelli
Priority: Blocker
I have a master drl that has global variables declaration as well as class role declaration and other drl files that depend on those declarations. Build is successful and I'm able to use the engine as intended. The thing is when I unload a rule and load it back, I get compilation errors that make it look like it's not relation to the master drl.
Examples:
1) "A Sliding Window can only be assigned to types declared with @role( event )
[Actually it is declared on the master drl]
2) "helper cannot be resolved"
[helper being my global variable, an instance of a class]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JGRP-2218) New payload interface
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-2218?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on JGRP-2218 at 9/14/17 10:41 AM:
--------------------------------------------------------------
{quote}Re Bits.size(): yes, not very eficient as JGroups never uses UTF internally. But you can provide your own better impl{quote}
We can only do {{estimateSize()}} in O\(1\), {{size()}} must be O\(n\).
{quote}When sending a CompositePayload of a 500 byte ByteArrayPayload and a 1000 byte NioDirectPayload, would we want to also get the same CompositePayload consisting of 2 payloads on the receiver side, or would we want to combine the 2 payloads into one and make the 2 payloads refer to the same combined byte[] array (or NIO buffer)? Should this be made configurable?{quote}
I'd like the option to get a single non-composite payload with all the bytes regardless of the input. Actually, if I send a message with a single {{ByteArrayPayload}} of 4*frag_size bytes, it would be even better to get a {{CompositePayload}} with a sub-payload for each fragment on the receiver.
was (Author: dan.berindei):
> Re Bits.size(): yes, not very eficient as JGroups never uses UTF internally. But you can provide your own better impl
We can only do {{estimateSize()}} in O\(1\), {{size()}} must be O\(n\).
{quote}When sending a CompositePayload of a 500 byte ByteArrayPayload and a 1000 byte NioDirectPayload, would we want to also get the same CompositePayload consisting of 2 payloads on the receiver side, or would we want to combine the 2 payloads into one and make the 2 payloads refer to the same combined byte[] array (or NIO buffer)? Should this be made configurable?{quote}
I'd like the option to get a single non-composite payload with all the bytes regardless of the input. Actually, if I send a message with a single {{ByteArrayPayload}} of 4*frag_size bytes, it would be even better to get a {{CompositePayload}} with a sub-payload for each fragment on the receiver.
> 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 {{ObjectPayload}} (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.
> * {{ByteArrayPayload}}: 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. Symmetry
> When sending a {{CompositePayload}} of a 500 byte {{ByteArrayPayload}} and a 1000 byte {{NioDirectPayload}}, would we want to also get the same {{CompositePayload}} consisting of 2 payloads on the receiver side, or would we want to combine the 2 payloads into one and make the 2 payloads refer to the same combined byte[] array (or NIO buffer)? Should this be made configurable?
> 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, 8 months
[JBoss JIRA] (JGRP-2218) New payload interface
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-2218?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-2218:
------------------------------------
> Re Bits.size(): yes, not very eficient as JGroups never uses UTF internally. But you can provide your own better impl
We can only do {{estimateSize()}} in O\(1\), {{size()}} must be O\(n\).
{quote}When sending a CompositePayload of a 500 byte ByteArrayPayload and a 1000 byte NioDirectPayload, would we want to also get the same CompositePayload consisting of 2 payloads on the receiver side, or would we want to combine the 2 payloads into one and make the 2 payloads refer to the same combined byte[] array (or NIO buffer)? Should this be made configurable?{quote}
I'd like the option to get a single non-composite payload with all the bytes regardless of the input. Actually, if I send a message with a single {{ByteArrayPayload}} of 4*frag_size bytes, it would be even better to get a {{CompositePayload}} with a sub-payload for each fragment on the receiver.
> 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 {{ObjectPayload}} (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.
> * {{ByteArrayPayload}}: 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. Symmetry
> When sending a {{CompositePayload}} of a 500 byte {{ByteArrayPayload}} and a 1000 byte {{NioDirectPayload}}, would we want to also get the same {{CompositePayload}} consisting of 2 payloads on the receiver side, or would we want to combine the 2 payloads into one and make the 2 payloads refer to the same combined byte[] array (or NIO buffer)? Should this be made configurable?
> 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, 8 months