[JBoss JIRA] (WFCORE-2687) Expose the current step operation's name and parameters via the OperationContext
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2687:
----------------------------------------
Summary: Expose the current step operation's name and parameters via the OperationContext
Key: WFCORE-2687
URL: https://issues.jboss.org/browse/WFCORE-2687
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Remove the need to pass the 'operation' ModelNode to a method for it to be able to learn about the currently effective operation.
OperationContext already exposes getCurrentAddress(). Add getCurrentOperationName() and getCurrentOperationParameter(String name).
The latter returns null if !operation.has(name) otherwise it returns whatever the node was. Or perhaps return undefined with an overloaded variant with a boolean param that lets the caller turn on getting null.
The getCurrentOperationParameter should reject 'name', 'address', 'operation-headers' etc as legal param names; only expose true parameters.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2068) HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2068?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2068:
-------------------------------------
Component/s: Domain Management
> HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing Due To Native Protocol Issue
> --------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2068
> URL: https://issues.jboss.org/browse/WFCORE-2068
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting, Test Suite
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta16
>
>
> The listed test case is failing during clean up with the following error: -
> {noformat}
> java.io.IOException: java.io.IOException: WFLYPRT0054: Channel closed
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:166)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:135)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:59)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:80)
> {noformat}
> The stage of the test using HTTP Upgrade over a HTTPS connection appears to be working fine, the issue is with the native management interface used for test clean up.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBMESSAGING-1961) message didn't put into the queue
by Tony Fan (JIRA)
Tony Fan created JBMESSAGING-1961:
-------------------------------------
Summary: message didn't put into the queue
Key: JBMESSAGING-1961
URL: https://issues.jboss.org/browse/JBMESSAGING-1961
Project: JBoss Messaging
Issue Type: Feature Request
Components: Messaging Core
Affects Versions: 1.4.8.SP9
Environment: Jboss 5.1
JBOSS remoting 2.5.4.SP5
Jboss JMS 1.4.8.SP9
Reporter: Tony Fan
We have a one central server is using Jboss 5.1 with JBossQueue[dmStatusQueue],
two instruments send status message to central server every 20-30 seconds, after system running for a while we had discovered that one of our instrument message got to put into the queue, the other didn't, I turned debug on and find out message never put into the queue.
here is log from jboss successfully :
2017-04-12 12:12:01,730 TRACE [org.jboss.jms.server.remoting.ServerSocketWrapper] (WorkerThread#1441[192.168.207.136:45506]) acknowledge read byte WorkerThread#1441[192.168.207.136:45506]
2017-04-12 12:12:01,730 TRACE [org.jboss.remoting.transport.socket.TimedOutputStream] (WorkerThread#1441[192.168.207.136:45506]) org.jboss.remoting.transport.socket.TimedOutputStream@1aea853 scheduled org.jboss.remoting.transport.socket.TimedOutputStream$OutputTimerTask@55b8ad: 30000
2017-04-12 12:12:01,731 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#1441[192.168.207.136:45506]) preparing to process next invocation
2017-04-12 12:12:01,731 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#1441[192.168.207.136:45506]) WorkerThread#1441[192.168.207.136:45506] blocking to read version from input stream
2017-04-12 12:12:01,731 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#1441[192.168.207.136:45506]) WorkerThread#1441[192.168.207.136:45506] read version 22 from input stream
2017-04-12 12:12:01,731 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#1441[192.168.207.136:45506]) blocking to read invocation from unmarshaller
2017-04-12 12:12:01,731 TRACE [org.jboss.jms.wireformat.JMSWireFormat] (WorkerThread#1441[192.168.207.136:45506]) Reading
2017-04-12 12:12:01,731 TRACE [org.jboss.jms.wireformat.JMSWireFormat] (WorkerThread#1441[192.168.207.136:45506]) Stream is already DataInputStream :)
2017-04-12 12:12:01,731 TRACE [org.jboss.jms.wireformat.JMSWireFormat] (WorkerThread#1441[192.168.207.136:45506]) Created packet org.jboss.jms.wireformat.SessionSendRequest@1cf6c2e
2017-04-12 12:12:01,731 TRACE [org.jboss.jms.wireformat.JMSWireFormat] (WorkerThread#1441[192.168.207.136:45506]) Reading packet
2017-04-12 12:12:01,731 TRACE [org.jboss.jms.wireformat.JMSWireFormat] (WorkerThread#1441[192.168.207.136:45506]) Read packet
2017-04-12 12:12:01,731 TRACE [org.jboss.jms.wireformat.JMSWireFormat] (WorkerThread#1441[192.168.207.136:45506]) Returning payload: InvocationRequest[c768f1, JMS, OnewayInvocation[org.jboss.jms.wireformat.SessionSendRequest@1cf6c2e]]
2017-04-12 12:12:01,731 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#1441[192.168.207.136:45506]) read InvocationRequest[c768f1, JMS, OnewayInvocation[org.jboss.jms.wireformat.SessionSendRequest@1cf6c2e]] from unmarshaller
2017-04-12 12:12:01,731 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#1441[192.168.207.136:45506]) about to call SocketServerInvoker[192.168.207.199:4459].invoke()
2017-04-12 12:12:01,731 TRACE [org.jboss.remoting.ServerInvoker] (WorkerThread#1441[192.168.207.136:45506]) SocketServerInvoker[192.168.207.199:4459] received OnewayInvocation[org.jboss.jms.wireformat.SessionSendRequest@1cf6c2e]
2017-04-12 12:12:01,731 TRACE [org.jboss.remoting.ServerInvoker] (WorkerThread#1441[192.168.207.136:45506]) reusing oneway thread pool
2017-04-12 12:12:01,731 TRACE [org.jboss.remoting.ServerInvoker] (WorkerThread#1441[192.168.207.136:45506]) SocketServerInvoker[192.168.207.199:4459] placing InvocationRequest[c768f1, JMS, org.jboss.jms.wireformat.SessionSendRequest@1cf6c2e] in onewayThreadPool
2017-04-12 12:12:01,731 TRACE [org.jboss.remoting.ServerInvoker] (WorkerThread#1441[192.168.207.136:45506]) SocketServerInvoker[192.168.207.199:4459] received org.jboss.jms.wireformat.SessionSendRequest@1cf6c2e
2017-04-12 12:12:01,731 TRACE [org.jboss.remoting.ServerInvoker] (WorkerThread#1441[192.168.207.136:45506]) SocketServerInvoker[192.168.207.199:4459] dispatching InvocationRequest[c768f1, JMS, org.jboss.jms.wireformat.SessionSendRequest@1cf6c2e] from client null to subsystem 'JMS'
2017-04-12 12:12:01,731 TRACE [org.jboss.jms.server.remoting.JMSServerInvocationHandler] (WorkerThread#1441[192.168.207.136:45506]) invoking InvocationRequest[c768f1, JMS, org.jboss.jms.wireformat.SessionSendRequest@1cf6c2e]
2017-04-12 12:12:01,731 TRACE [org.jboss.jms.server.container.SecurityAspect] (WorkerThread#1441[192.168.207.136:45506]) checking access permissions to JBossQueue[dmStatusQueue]
2017-04-12 12:12:01,731 TRACE [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (WorkerThread#1441[192.168.207.136:45506]) authenticating user null
2017-04-12 12:12:01,731 TRACE [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (WorkerThread#1441[192.168.207.136:45506]) authorizing user null for role(s) [guest, publisher]
2017-04-12 12:12:01,732 TRACE [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (WorkerThread#1441[192.168.207.136:45506]) user null is authorized
2017-04-12 12:12:01,732 TRACE [org.jboss.jms.server.endpoint.ServerConnectionEndpoint] (WorkerThread#1441[192.168.207.136:45506]) ConnectionEndpoint[0t24-tvhtld1j-1-8yfjj21j-m4r0qw-j5r5o4c5] sending message JBossMessage[6111287385027365]:NON-PERSISTENT non-transactionally
.........
Here is one unsuccessfully:
2017-04-18 15:56:53,593 TRACE [org.jboss.jms.server.remoting.ServerSocketWrapper] (WorkerThread#21[192.168.207.136:41466]) acknowledge read byte WorkerThread#21[192.168.207.136:41466]
2017-04-18 15:56:53,593 TRACE [org.jboss.remoting.transport.socket.TimedOutputStream] (WorkerThread#21[192.168.207.136:41466]) org.jboss.remoting.transport.socket.TimedOutputStream@12ba248 scheduled org.jboss.remoting.transport.socket.TimedOutputStream$OutputTimerTask@cabb1d: 30000
2017-04-18 15:56:53,593 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#21[192.168.207.136:41466]) preparing to process next invocation
2017-04-18 15:56:53,593 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#21[192.168.207.136:41466]) WorkerThread#21[192.168.207.136:41466] blocking to read version from input stream
2017-04-18 15:56:53,595 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#21[192.168.207.136:41466]) WorkerThread#21[192.168.207.136:41466] read version 22 from input stream
2017-04-18 15:56:53,595 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#21[192.168.207.136:41466]) blocking to read invocation from unmarshaller
2017-04-18 15:56:53,596 TRACE [org.jboss.jms.wireformat.JMSWireFormat] (WorkerThread#21[192.168.207.136:41466]) Reading
2017-04-18 15:56:53,596 TRACE [org.jboss.jms.wireformat.JMSWireFormat] (WorkerThread#21[192.168.207.136:41466]) Stream is already DataInputStream :)
2017-04-18 15:56:53,596 TRACE [org.jboss.jms.wireformat.JMSWireFormat] (WorkerThread#21[192.168.207.136:41466]) Created packet org.jboss.jms.wireformat.SessionSendRequest@1c28b12
2017-04-18 15:56:53,596 TRACE [org.jboss.jms.wireformat.JMSWireFormat] (WorkerThread#21[192.168.207.136:41466]) Reading packet
2017-04-18 15:56:53,596 TRACE [org.jboss.jms.wireformat.JMSWireFormat] (WorkerThread#21[192.168.207.136:41466]) Read packet
2017-04-18 15:56:53,596 TRACE [org.jboss.jms.wireformat.JMSWireFormat] (WorkerThread#21[192.168.207.136:41466]) Returning payload: InvocationRequest[13875b4, JMS, OnewayInvocation[org.jboss.jms.wireformat.SessionSendRequest@1c28b12]]
2017-04-18 15:56:53,596 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#21[192.168.207.136:41466]) read InvocationRequest[13875b4, JMS, OnewayInvocation[org.jboss.jms.wireformat.SessionSendRequest@1c28b12]] from unmarshaller
2017-04-18 15:56:53,596 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#21[192.168.207.136:41466]) about to call SocketServerInvoker[192.168.207.199:4459].invoke()
2017-04-18 15:56:53,596 TRACE [org.jboss.remoting.ServerInvoker] (WorkerThread#21[192.168.207.136:41466]) SocketServerInvoker[192.168.207.199:4459] received OnewayInvocation[org.jboss.jms.wireformat.SessionSendRequest@1c28b12]
2017-04-18 15:56:53,596 TRACE [org.jboss.remoting.ServerInvoker] (WorkerThread#21[192.168.207.136:41466]) reusing oneway thread pool
2017-04-18 15:56:53,596 TRACE [org.jboss.remoting.ServerInvoker] (WorkerThread#21[192.168.207.136:41466]) SocketServerInvoker[192.168.207.199:4459] placing InvocationRequest[13875b4, JMS, org.jboss.jms.wireformat.SessionSendRequest@1c28b12] in onewayThreadPool
2017-04-18 15:56:53,596 TRACE [org.jboss.remoting.ServerInvoker] (WorkerThread#21[192.168.207.136:41466]) SocketServerInvoker[192.168.207.199:4459] received org.jboss.jms.wireformat.SessionSendRequest@1c28b12
2017-04-18 15:56:53,596 TRACE [org.jboss.remoting.ServerInvoker] (WorkerThread#21[192.168.207.136:41466]) SocketServerInvoker[192.168.207.199:4459] dispatching InvocationRequest[13875b4, JMS, org.jboss.jms.wireformat.SessionSendRequest@1c28b12] from client null to subsystem 'JMS'
2017-04-18 15:56:53,596 TRACE [org.jboss.jms.server.remoting.JMSServerInvocationHandler] (WorkerThread#21[192.168.207.136:41466]) invoking InvocationRequest[13875b4, JMS, org.jboss.jms.wireformat.SessionSendRequest@1c28b12]
2017-04-18 15:56:53,596 TRACE [org.jboss.remoting.ServerInvoker] (WorkerThread#21[192.168.207.136:41466]) SocketServerInvoker[192.168.207.199:4459] successfully dispatched invocation, returning null from subsystem 'JMS' to client null
2017-04-18 15:56:53,596 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#21[192.168.207.136:41466]) SocketServerInvoker[192.168.207.199:4459].invoke() returned null
2017-04-18 15:56:53,596 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#21[192.168.207.136:41466]) oneway request, writing no reply on the wire
2017-04-18 15:56:53,596 TRACE [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#21[192.168.207.136:41466]) checking connection
-------------------------------------------------------------------------------------------------------
it skipped the part "TRACE [org.jboss.jms.server.container.SecurityAspect] (WorkerThread#1441[192.168.207.136:45506]) checking access permissions to JBossQueue[dmStatusQueue]"
can someone help me to do more debug on this issue? Thanks
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2686) Map to resource set aliasing and transformer facility
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2686:
----------------------------------------
Summary: Map to resource set aliasing and transformer facility
Key: WFCORE-2686
URL: https://issues.jboss.org/browse/WFCORE-2686
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Food for thought:
Scenario:
1) A resource that historically has child resources of child type 'property', where children of that type have a single attribute 'value' each child is really just an entry in a map.
2) A better API would be to have a 'properties' attribute in the parent, defined using MapAttributeDefinition.
It would be good to be able to switch to the map attribute and deprecate the child resources. But for compatibility reasons the child resources can't just be dropped. And that makes this kind of change painful. If the extension API could provide some helpers that would be good. For example:
a) read-attribute handler for the map attribute that reads the child resources.
b) write-attribute handler for the map attribute that diffs the map and adds add/remove/write-attribute steps for the child resources.
c) Transformer logic for legacy domain mode slaves that diffs the map and transforms the op to a composite made up of add/remove/write-attribute ops.
An alternative to a) and b) above is to make the new map attribute the authoritative store of data and then update the child resources to work with it (the transformer discussed in c) would still be needed):
x) the handlers for child resource add or write-attribute ops just add a map-put step against the parent resource
y) the handler for the child resource remove op just adds a map-remove step against the parent resource
z) A specialized resource type would be needed for the parent resource, one that understands how to read the map attribute from its own model and represent its entries as child resources.
Perhaps both sets of functionality would be useful.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1089) CS tool, missing parameters compared to management API
by Peter Skopek (JIRA)
[ https://issues.jboss.org/browse/ELY-1089?page=com.atlassian.jira.plugin.s... ]
Peter Skopek moved WFCORE-2492 to ELY-1089:
-------------------------------------------
Project: WildFly Elytron (was: WildFly Core)
Key: ELY-1089 (was: WFCORE-2492)
Component/s: Command-Line Tool
(was: Security)
> CS tool, missing parameters compared to management API
> ------------------------------------------------------
>
> Key: ELY-1089
> URL: https://issues.jboss.org/browse/ELY-1089
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Command-Line Tool
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Labels: credential-store, wildfly-elytron-tool
>
> compared to management API I am missing these parameters:
> * {{entry-type}}
> * -{{providers}} + {{provider-name}}-
> ** -user can gain alternative behaviour by editing java.security file-
> * {{other-providers}}
> ** user can gain alternative behaviour by editing java.security file. But it has to be ensured these providers are injected to implementation throught SPI
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1089) CS tool, missing parameters compared to management API
by Peter Skopek (JIRA)
[ https://issues.jboss.org/browse/ELY-1089?page=com.atlassian.jira.plugin.s... ]
Peter Skopek reassigned ELY-1089:
---------------------------------
Assignee: Peter Skopek (was: Darran Lofthouse)
> CS tool, missing parameters compared to management API
> ------------------------------------------------------
>
> Key: ELY-1089
> URL: https://issues.jboss.org/browse/ELY-1089
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Command-Line Tool
> Reporter: Martin Choma
> Assignee: Peter Skopek
> Priority: Critical
> Labels: credential-store, wildfly-elytron-tool
>
> compared to management API I am missing these parameters:
> * {{entry-type}}
> * -{{providers}} + {{provider-name}}-
> ** -user can gain alternative behaviour by editing java.security file-
> * {{other-providers}}
> ** user can gain alternative behaviour by editing java.security file. But it has to be ensured these providers are injected to implementation throught SPI
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2684) IO extension doesn't initialise outbound bind addresses
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2684?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2684:
------------------------------------------
[~jfdenise] Please let me know if this fixes JBEAP-10283. If it does I'll do the various JIRA state twiddling on that one.
> IO extension doesn't initialise outbound bind addresses
> -------------------------------------------------------
>
> Key: WFCORE-2684
> URL: https://issues.jboss.org/browse/WFCORE-2684
> Project: WildFly Core
> Issue Type: Bug
> Components: IO
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Fix For: 3.0.0.Beta16
>
>
> WorkerService.start and OutboundBindAddressAddHandler execute in //. The add handler is executed first, so the table is still null.
> The Builder table must be returned by the Service.
> Furthermore the OutboundBindAddressRemoveHandler uses the operation ModelNode instead of the model, so there is no way to remove an OutboundBind address.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2685) http-interface.http-upgrade should not be marked as "restart-required" => "no-services"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2685?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-10403 to WFCORE-2685:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2685 (was: JBEAP-10403)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Affects Version/s: (was: 7.1.0.DR16)
> http-interface.http-upgrade should not be marked as "restart-required" => "no-services"
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-2685
> URL: https://issues.jboss.org/browse/WFCORE-2685
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Martin Choma
> Assignee: Ken Wills
>
> Although {{http-upgrade}} attribute is marked as {{"restart-required" => "no-services"}} in model, when I try change it, server gets into reload required state, anyway.
> {code}
> [standalone@localhost:9990 /] /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=application-sasl-authentication)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
> This issue foolows-up JBEAP-9137, where all other {{http-interface}} where marked as {{"restart-required" => "all-services"}}. So seems to me {{http-upgrade}} was ommited just by mistake.
> {code}
> "http-upgrade" => {
> "type" => OBJECT,
> "description" => "HTTP Upgrade specific configuration",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "value-type" => {
> "enabled" => {
> "type" => BOOLEAN,
> "description" => "Flag that indicates HTTP Upgrade is enabled, which allows HTTP requests to be upgraded to native remoting connections",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => false
> },
> "sasl-authentication-factory" => {
> "type" => STRING,
> "description" => "The server side SASL authentication policy to use to secure the interface where the connection is after a HTTP upgrade.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.sasl-authentication-factory",
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JGRP-2167) Highest seqno is not resent nor recorded on receivers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2167?page=com.atlassian.jira.plugin.... ]
Bela Ban reopened JGRP-2167:
----------------------------
OK, I'll take another look.
> Highest seqno is not resent nor recorded on receivers
> -----------------------------------------------------
>
> Key: JGRP-2167
> URL: https://issues.jboss.org/browse/JGRP-2167
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 4.0.3
>
>
> I am investigating an issue in a stress test which leads me to a situation where in a TCP-based configuration a {{GMS[VIEW]}} is broadcast to all nodes, but it is not received by some of them. Soon after that there's a {{NAKACK2.HIGHEST_SEQNO}} that causes the node that is missing the last seqno to resend it, but the retransmit is not received either. There are no further retries, and generally no NAKACK2 activity until about 30 seconds later (when another node leaves after some timeout in the test).
> The receiver does not keep asking for retransmissions until it gets them, but it seems that {{NAKACK2.handleHighestSeqno}} doesn't update {{Table.hr}} (not sure if having highest received set to non-received msg would be legal, though).
> The sender uses default value {{NAKACK2.resend_last_seqno_max_times=1}}, and as there are no further mcast messages, the highest sent seqno does not change on sender.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years