[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 {{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
was:
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. 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 {{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] (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:
-----------------------------------------------
Hi Toni/Arunja,
Do one of you two have a solution for me? I just tried it with a new tomcat version(8.5.2.0) but still get the undetermined error.
> 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] (WFLY-9344) Let Infinispan manage eviction for distributed web sessions and @Stateful EJBs
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-9344:
----------------------------------
Summary: Let Infinispan manage eviction for distributed web sessions and @Stateful EJBs
Key: WFLY-9344
URL: https://issues.jboss.org/browse/WFLY-9344
Project: WildFly
Issue Type: Enhancement
Components: Clustering
Affects Versions: 11.0.0.CR1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 12.0.0.Alpha1
With Infinispan's transition to Caffeine to implement its data container, WF should finally be able to offload eviction to Infinispan, by configuring caffeine to use a specific Weigher that returns 0 for non-primary session entries, where max-active-sessions is configured as the maximumWeight. From an Infinispan configuration perspective, this corresponds to a custom EntrySizeCalculator that returns 0 for non-primary session entries, and a maxSize equal to the max-active-sessions. The remaining entries would rely on cascading eviction (i.e. manually evicting from a via passivation callback).
As of Infinispan 9.1, the requisite DataContainer configuration attributes are deprecated - thus we need to lobby to expose the mechanisms for overriding the entry size calculator to be able to ensure this solution will be supported in the future.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 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:
---------------------------
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 {{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. 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 {{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.
* {{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
> 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. 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] (DROOLS-1728) There is always HTTP 404 Error Where I request the maven2 in workbench
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1728?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-1728:
----------------------------------------
Hi [~zhouhuiyu] we have no plans.
However if there's enough demand there's nothing stopping a RFE being raised and triaged etc for future consideration.
Glad your immediate {{KieScanner}} issue is resolved!
> There is always HTTP 404 Error Where I request the maven2 in workbench
> ----------------------------------------------------------------------
>
> Key: DROOLS-1728
> URL: https://issues.jboss.org/browse/DROOLS-1728
> Project: Drools
> Issue Type: Bug
> Components: tools
> Affects Versions: 7.3.0.Final
> Environment: CentOS 6.8
> Virtual Box 5.x
> Tomcat 8.5.20
> kie-drools-wb-7.3.0.Final-tomcat8.war
> MySQL 5.6.x
> Reporter: HuiYu Zhou
> Assignee: Michael Anstis
> Priority: Blocker
> Labels: reported-by-qe
>
> I want to try KieScanner for the remote maven repo. So I setup the workbench and create "Project1" as a sample, I also build and deploy it successfully. I can see the jar named "Project1-1.0.0.jar" with GAV "com.myteam:Project1:1.0.0" exist in “Admin” -> "Artifacts".
> So I add the repository into my development pom.xml and the jar as dependency, but the jar can't been downloaded by Maven Project.
> I also try to open the url: http://192.168.56.101:8080/kie-drools-wb/maven2, but there is always HTTP Status 404 – Not Found happened with description " The origin server did not find a current representation for the target resource or is not willing to disclose that one exists."
> The most funny thing is I can open the url: http://192.168.56.101:8080/kie-drools-wb/maven2/com/myteam/Project1/maven..., the content is shown in my webpage as following:
> This XML file does not appear to have any style information associated with it. The document tree is shown below.
> <metadata>
> <groupId>com.myteam</groupId>
> <artifactId>Project1</artifactId>
> <versioning>
> <release>1.0.0</release>
> <versions>
> <version>1.0.0</version>
> </versions>
> <lastUpdated>20170913142741</lastUpdated>
> </versioning>
> </metadata>
> As remote maven repo of workbench, why not like my private nexus maven that I can open the link even if it 's a folder?
>
> my pom.xml as following:
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <groupId>drools</groupId>
> <artifactId>drools</artifactId>
> <version>1.0-SNAPSHOT</version>
> <properties>
> <drools.version>7.3.0.Final</drools.version>
> </properties>
> <repositories>
> <repository>
> <id>guvnor-m2-repo</id>
> <name>Guvnor M2 Repo</name>
> <url>http://192.168.56.101:8080/kie-drools-wb/maven2/</url>
> </repository>
> </repositories>
> <dependencies>
> <dependency>
> <groupId>com.myteam</groupId>
> <artifactId>Project1</artifactId>
> <version>1.0.0</version>
> </dependency>
> <!--drools dependencies -->
> </dependencies>
> </project>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1728) There is always HTTP 404 Error Where I request the maven2 in workbench
by HuiYu Zhou (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1728?page=com.atlassian.jira.plugi... ]
HuiYu Zhou commented on DROOLS-1728:
------------------------------------
I added the server info to setting.xml, it works fine now.
Do you have plan to develop the browsing maven repo in WB?
> There is always HTTP 404 Error Where I request the maven2 in workbench
> ----------------------------------------------------------------------
>
> Key: DROOLS-1728
> URL: https://issues.jboss.org/browse/DROOLS-1728
> Project: Drools
> Issue Type: Bug
> Components: tools
> Affects Versions: 7.3.0.Final
> Environment: CentOS 6.8
> Virtual Box 5.x
> Tomcat 8.5.20
> kie-drools-wb-7.3.0.Final-tomcat8.war
> MySQL 5.6.x
> Reporter: HuiYu Zhou
> Assignee: Michael Anstis
> Priority: Blocker
> Labels: reported-by-qe
>
> I want to try KieScanner for the remote maven repo. So I setup the workbench and create "Project1" as a sample, I also build and deploy it successfully. I can see the jar named "Project1-1.0.0.jar" with GAV "com.myteam:Project1:1.0.0" exist in “Admin” -> "Artifacts".
> So I add the repository into my development pom.xml and the jar as dependency, but the jar can't been downloaded by Maven Project.
> I also try to open the url: http://192.168.56.101:8080/kie-drools-wb/maven2, but there is always HTTP Status 404 – Not Found happened with description " The origin server did not find a current representation for the target resource or is not willing to disclose that one exists."
> The most funny thing is I can open the url: http://192.168.56.101:8080/kie-drools-wb/maven2/com/myteam/Project1/maven..., the content is shown in my webpage as following:
> This XML file does not appear to have any style information associated with it. The document tree is shown below.
> <metadata>
> <groupId>com.myteam</groupId>
> <artifactId>Project1</artifactId>
> <versioning>
> <release>1.0.0</release>
> <versions>
> <version>1.0.0</version>
> </versions>
> <lastUpdated>20170913142741</lastUpdated>
> </versioning>
> </metadata>
> As remote maven repo of workbench, why not like my private nexus maven that I can open the link even if it 's a folder?
>
> my pom.xml as following:
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <groupId>drools</groupId>
> <artifactId>drools</artifactId>
> <version>1.0-SNAPSHOT</version>
> <properties>
> <drools.version>7.3.0.Final</drools.version>
> </properties>
> <repositories>
> <repository>
> <id>guvnor-m2-repo</id>
> <name>Guvnor M2 Repo</name>
> <url>http://192.168.56.101:8080/kie-drools-wb/maven2/</url>
> </repository>
> </repositories>
> <dependencies>
> <dependency>
> <groupId>com.myteam</groupId>
> <artifactId>Project1</artifactId>
> <version>1.0.0</version>
> </dependency>
> <!--drools dependencies -->
> </dependencies>
> </project>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9343) mod_cluster fails to start with negative port offset
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9343?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9343:
---------------------------------
Priority: Major (was: Critical)
> mod_cluster fails to start with negative port offset
> ----------------------------------------------------
>
> Key: WFLY-9343
> URL: https://issues.jboss.org/browse/WFLY-9343
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 11.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> When using a negative port-offset in HA profiles, mod-cluster fails to start.
> This problem doesn't occur in non-HA profiles (e.g. default), because the modcluster subsystem is not present in them.
> Server log contains:
> {noformat}
> 19:59:41,337 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.mod_cluster.config: org.jboss.msc.service.StartException in service org.wildfly.mod_cluster.config: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: port out of range:-100
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:188)
> at org.jboss.as.network.SocketBinding.getSocketAddress(SocketBinding.java:129)
> at org.wildfly.extension.mod_cluster.ModClusterConfigurationServiceBuilder.getValue(ModClusterConfigurationServiceBuilder.java:272)
> at org.wildfly.extension.mod_cluster.ModClusterConfigurationServiceBuilder.getValue(ModClusterConfigurationServiceBuilder.java:104)
> at org.jboss.msc.service.ValueService.start(ValueService.java:49)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> ... 3 more
> 19:59:41,492 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 16 (per class), which is derived from the number of CPUs on this host.
> 19:59:41,493 INFO [org.jboss.as.ejb3] (MSC service thread 1-5) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 64 (per class), which is derived from thread worker pool sizing.
> 19:59:41,657 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 65) WFLYUT0014: Creating file handler for path '/home/kwart/test/710CR1/jboss-eap-7.1/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 19:59:41,663 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0012: Started server default-server.
> 19:59:41,666 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting
> 19:59:41,729 INFO [org.jboss.as.ejb3] (MSC service thread 1-7) WFLYEJB0493: EJB subsystem suspension complete
> 19:59:41,747 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:7909
> 19:59:41,749 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:7980
> 19:59:41,881 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 19:59:41,989 INFO [org.jboss.as.patching] (MSC service thread 1-3) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none
> 19:59:42,006 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-3) WFLYDM0111: Keystore /home/kwart/test/710CR1/jboss-eap-7.1/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> 19:59:42,043 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) WFLYDS0013: Started FileSystemDeploymentService for directory /home/kwart/test/710CR1/jboss-eap-7.1/standalone/deployments
> 19:59:42,151 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0006: Undertow HTTPS listener https listening on 127.0.0.1:8343
> 19:59:42,252 INFO [org.jboss.ws.common.management] (MSC service thread 1-7) JBWS022052: Starting JBossWS 5.1.9.Final-redhat-1 (Apache CXF 3.1.12.redhat-1)
> 19:59:42,259 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "modcluster")]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.mod_cluster.config" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: port out of range:-100"}}
> 19:59:42,282 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service org.wildfly.mod_cluster.config: Failed to start service
> 19:59:42,367 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 19:59:42,369 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9890/management
> 19:59:42,370 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9890
> 19:59:42,370 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.GA (WildFly Core 3.0.1.Final-redhat-1) started (with errors) in 4175ms - Started 309 of 642 services (3 services failed or missing dependencies, 421 services are lazy, passive or on-demand)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9343) mod_cluster fails to start with negative port offset
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9343?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9343:
---------------------------------
Summary: mod_cluster fails to start with negative port offset (was: Modcluster fails to start with negative port offset used)
> mod_cluster fails to start with negative port offset
> ----------------------------------------------------
>
> Key: WFLY-9343
> URL: https://issues.jboss.org/browse/WFLY-9343
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 11.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
>
> When using a negative port-offset in HA profiles, mod-cluster fails to start.
> This problem doesn't occur in non-HA profiles (e.g. default), because the modcluster subsystem is not present in them.
> Server log contains:
> {noformat}
> 19:59:41,337 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.mod_cluster.config: org.jboss.msc.service.StartException in service org.wildfly.mod_cluster.config: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: port out of range:-100
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.<init>(InetSocketAddress.java:188)
> at org.jboss.as.network.SocketBinding.getSocketAddress(SocketBinding.java:129)
> at org.wildfly.extension.mod_cluster.ModClusterConfigurationServiceBuilder.getValue(ModClusterConfigurationServiceBuilder.java:272)
> at org.wildfly.extension.mod_cluster.ModClusterConfigurationServiceBuilder.getValue(ModClusterConfigurationServiceBuilder.java:104)
> at org.jboss.msc.service.ValueService.start(ValueService.java:49)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> ... 3 more
> 19:59:41,492 INFO [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0482: Strict pool mdb-strict-max-pool is using a max instance size of 16 (per class), which is derived from the number of CPUs on this host.
> 19:59:41,493 INFO [org.jboss.as.ejb3] (MSC service thread 1-5) WFLYEJB0481: Strict pool slsb-strict-max-pool is using a max instance size of 64 (per class), which is derived from thread worker pool sizing.
> 19:59:41,657 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 65) WFLYUT0014: Creating file handler for path '/home/kwart/test/710CR1/jboss-eap-7.1/welcome-content' with options [directory-listing: 'false', follow-symlink: 'false', case-sensitive: 'true', safe-symlink-paths: '[]']
> 19:59:41,663 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0012: Started server default-server.
> 19:59:41,666 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0018: Host default-host starting
> 19:59:41,729 INFO [org.jboss.as.ejb3] (MSC service thread 1-7) WFLYEJB0493: EJB subsystem suspension complete
> 19:59:41,747 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow AJP listener ajp listening on 127.0.0.1:7909
> 19:59:41,749 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:7980
> 19:59:41,881 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
> 19:59:41,989 INFO [org.jboss.as.patching] (MSC service thread 1-3) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none
> 19:59:42,006 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-3) WFLYDM0111: Keystore /home/kwart/test/710CR1/jboss-eap-7.1/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> 19:59:42,043 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) WFLYDS0013: Started FileSystemDeploymentService for directory /home/kwart/test/710CR1/jboss-eap-7.1/standalone/deployments
> 19:59:42,151 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0006: Undertow HTTPS listener https listening on 127.0.0.1:8343
> 19:59:42,252 INFO [org.jboss.ws.common.management] (MSC service thread 1-7) JBWS022052: Starting JBossWS 5.1.9.Final-redhat-1 (Apache CXF 3.1.12.redhat-1)
> 19:59:42,259 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "modcluster")]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.mod_cluster.config" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: port out of range:-100"}}
> 19:59:42,282 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service org.wildfly.mod_cluster.config: Failed to start service
> 19:59:42,367 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 19:59:42,369 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9890/management
> 19:59:42,370 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9890
> 19:59:42,370 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.GA (WildFly Core 3.0.1.Final-redhat-1) started (with errors) in 4175ms - Started 309 of 642 services (3 services failed or missing dependencies, 421 services are lazy, passive or on-demand)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1728) There is always HTTP 404 Error Where I request the maven2 in workbench
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1728?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-1728:
----------------------------------------
Please see https://bugzilla.redhat.com/show_bug.cgi?id=1059584
If you add the workbench Maven repository to {{settings.xml}} and provide an entry for authentication against the repository it should work fine.
The Workbench's Maven Repository does not support browsing content so you cannot simply enter the root URL and browse the artifacts.
> There is always HTTP 404 Error Where I request the maven2 in workbench
> ----------------------------------------------------------------------
>
> Key: DROOLS-1728
> URL: https://issues.jboss.org/browse/DROOLS-1728
> Project: Drools
> Issue Type: Bug
> Components: tools
> Affects Versions: 7.3.0.Final
> Environment: CentOS 6.8
> Virtual Box 5.x
> Tomcat 8.5.20
> kie-drools-wb-7.3.0.Final-tomcat8.war
> MySQL 5.6.x
> Reporter: HuiYu Zhou
> Assignee: Michael Anstis
> Priority: Blocker
> Labels: reported-by-qe
>
> I want to try KieScanner for the remote maven repo. So I setup the workbench and create "Project1" as a sample, I also build and deploy it successfully. I can see the jar named "Project1-1.0.0.jar" with GAV "com.myteam:Project1:1.0.0" exist in “Admin” -> "Artifacts".
> So I add the repository into my development pom.xml and the jar as dependency, but the jar can't been downloaded by Maven Project.
> I also try to open the url: http://192.168.56.101:8080/kie-drools-wb/maven2, but there is always HTTP Status 404 – Not Found happened with description " The origin server did not find a current representation for the target resource or is not willing to disclose that one exists."
> The most funny thing is I can open the url: http://192.168.56.101:8080/kie-drools-wb/maven2/com/myteam/Project1/maven..., the content is shown in my webpage as following:
> This XML file does not appear to have any style information associated with it. The document tree is shown below.
> <metadata>
> <groupId>com.myteam</groupId>
> <artifactId>Project1</artifactId>
> <versioning>
> <release>1.0.0</release>
> <versions>
> <version>1.0.0</version>
> </versions>
> <lastUpdated>20170913142741</lastUpdated>
> </versioning>
> </metadata>
> As remote maven repo of workbench, why not like my private nexus maven that I can open the link even if it 's a folder?
>
> my pom.xml as following:
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <groupId>drools</groupId>
> <artifactId>drools</artifactId>
> <version>1.0-SNAPSHOT</version>
> <properties>
> <drools.version>7.3.0.Final</drools.version>
> </properties>
> <repositories>
> <repository>
> <id>guvnor-m2-repo</id>
> <name>Guvnor M2 Repo</name>
> <url>http://192.168.56.101:8080/kie-drools-wb/maven2/</url>
> </repository>
> </repositories>
> <dependencies>
> <dependency>
> <groupId>com.myteam</groupId>
> <artifactId>Project1</artifactId>
> <version>1.0.0</version>
> </dependency>
> <!--drools dependencies -->
> </dependencies>
> </project>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months