[JBoss JIRA] (WFLY-3784) JMX remoting-connector dependency error
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3784?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-3784.
------------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Rejected
Jira is for the management and scheduling of bugs and features, for assistance with your configuration please use the community forums.
If you are unfamiliar with the best place for different tasks I recommend starting at http://wildfly.org/
> JMX remoting-connector dependency error
> ---------------------------------------
>
> Key: WFLY-3784
> URL: https://issues.jboss.org/browse/WFLY-3784
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.1.0.Final
> Reporter: Rakesh Panati
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.Beta1
>
>
> My WildFly 8.1 configuration contains the below subsystem profile.
> <server xmlns="urn:jboss:domain:2.1">
> <extensions>
> ....
> <extension module="org.jboss.as.remoting"/>
> ....
> </extensions>
> ...........
> <profile>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
> <expose-resolved-model/>
> <expose-expression-model/>
> <remoting-connector/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:remoting:2.0">
> <endpoint worker="default"/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> </profile>
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> <socket-binding name="https" port="${jboss.https.port:8443}"/>
> <socket-binding name="txn-recovery-environment" port="4712"/>
> <socket-binding name="txn-status-manager" port="4713"/>
> <outbound-socket-binding name="mail-smtp">
> <remote-destination host="localhost" port="25"/>
> </outbound-socket-binding>
> </socket-binding-group>
> </server>
> During startup, the JMX addition fails with the below error
> 2014-08-27 14:34:06,301 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
> ("subsystem" => "jmx"),
> ("remoting-connector" => "jmx")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.jmx.remoting-connector-ref is missing [jboss.remoting.endpoint.management]"]}
> 2014-08-27 14:34:06,329 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.remoting.endpoint.management (missing) dependents: [service jboss.jmx.remoting-connector-ref]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3784) JMX remoting-connector dependency error
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3784?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-3784:
--------------------------------------
Assignee: Darran Lofthouse (was: Jason Greene)
> JMX remoting-connector dependency error
> ---------------------------------------
>
> Key: WFLY-3784
> URL: https://issues.jboss.org/browse/WFLY-3784
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.1.0.Final
> Reporter: Rakesh Panati
> Assignee: Darran Lofthouse
>
> My WildFly 8.1 configuration contains the below subsystem profile.
> <server xmlns="urn:jboss:domain:2.1">
> <extensions>
> ....
> <extension module="org.jboss.as.remoting"/>
> ....
> </extensions>
> ...........
> <profile>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
> <expose-resolved-model/>
> <expose-expression-model/>
> <remoting-connector/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:remoting:2.0">
> <endpoint worker="default"/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> </profile>
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> <socket-binding name="https" port="${jboss.https.port:8443}"/>
> <socket-binding name="txn-recovery-environment" port="4712"/>
> <socket-binding name="txn-status-manager" port="4713"/>
> <outbound-socket-binding name="mail-smtp">
> <remote-destination host="localhost" port="25"/>
> </outbound-socket-binding>
> </socket-binding-group>
> </server>
> During startup, the JMX addition fails with the below error
> 2014-08-27 14:34:06,301 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
> ("subsystem" => "jmx"),
> ("remoting-connector" => "jmx")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.jmx.remoting-connector-ref is missing [jboss.remoting.endpoint.management]"]}
> 2014-08-27 14:34:06,329 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.remoting.endpoint.management (missing) dependents: [service jboss.jmx.remoting-connector-ref]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3724) Batch jobs don't receive partition-specific parameters
by Enrique González Martínez (JIRA)
[ https://issues.jboss.org/browse/WFLY-3724?page=com.atlassian.jira.plugin.... ]
Enrique González Martínez closed WFLY-3724.
-------------------------------------------
Resolution: Rejected
> Batch jobs don't receive partition-specific parameters
> ------------------------------------------------------
>
> Key: WFLY-3724
> URL: https://issues.jboss.org/browse/WFLY-3724
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Batch
> Affects Versions: 8.1.0.Final
> Environment: Windows 7 Home Premium Service Pack 1 64-bit + JDK8u11 + WildFly 8.1.0 Final
> Reporter: Ari Silvan
> Assignee: Enrique González Martínez
>
> When defining a batch job chunk step to run as partitions, ItemReader doesn't receive the partition-specific parameters specified by an implementation of the PartitionPlan interface. Parameters are null. See steps to reproduce for further details.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3724) Batch jobs don't receive partition-specific parameters
by Enrique González Martínez (JIRA)
[ https://issues.jboss.org/browse/WFLY-3724?page=com.atlassian.jira.plugin.... ]
Enrique González Martínez commented on WFLY-3724:
-------------------------------------------------
I don't think this behavior can be considered a bug. Partition properties are available through xml substitution and they are in step scope.
Extracted from the JavaDoc
jsr 352 -> 10.9.7
JobOperator::getParameters(execID)
"Returns job parameters for a specified job instance. These are the key/value pairs specified when the instance was originally created by the start method."
That means the properties passed during creation: JobOperator::start(jobXMLName, jobParameters).
It does not mention anything about partition plan properties available to the job parameters or job properties (through the JobContext).
The specification states that:
jsr352 -> 10.9.4 PartitionPlan
PartitionPlan::getPartitionProperties()
"Gets array of Partition Properties objects for Partitions. These can be used in Job XML substitution using substitution expressions with the syntax: #{partitionPlan['propertyName']}
Each element of the Properties array returned can be used to resolving substitutions for a single partition. In the typical use case, each Properties element will have a similar set of property names, with a substitution potentially resolving to the corresponding value for each partition."
jsr 352 -> 8.8.1.4 partitionPlan Substitution Operator
"The partitionPlan substitution operator resolves to the value of the partition plan property with the specified target name from the PartitionPlan returned by the PartitionMapper
Partition plan properties are in scope only for the step to which the partition plan is defined. The partitionPlan operator is resolved separately for each partition before the partition execution begins. "
> Batch jobs don't receive partition-specific parameters
> ------------------------------------------------------
>
> Key: WFLY-3724
> URL: https://issues.jboss.org/browse/WFLY-3724
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Batch
> Affects Versions: 8.1.0.Final
> Environment: Windows 7 Home Premium Service Pack 1 64-bit + JDK8u11 + WildFly 8.1.0 Final
> Reporter: Ari Silvan
> Assignee: Enrique González Martínez
>
> When defining a batch job chunk step to run as partitions, ItemReader doesn't receive the partition-specific parameters specified by an implementation of the PartitionPlan interface. Parameters are null. See steps to reproduce for further details.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-1024) Better JGroups defaults
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/WFLY-1024?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on WFLY-1024:
------------------------------------
Infinispan needs OOB thread pool to be queueless.
> Better JGroups defaults
> -----------------------
>
> Key: WFLY-1024
> URL: https://issues.jboss.org/browse/WFLY-1024
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Reporter: NadirX
> Assignee: Paul Ferraro
>
> The JGroups subsystem needs optimal defaults out of the box, that are also good for derived products (e.g. JDG), both for protocols and thread pools.
> Use a bounded thread pool for the default executor
> core-size==number of members (32 for JDG)
> max-threads = 1.5*core-size
> oob should be queueless
> AS7 protocol list (UDP): PING, MERGE2, FD_SOCK, FD, VERIFY_SUSPECT, BARRIER, pbcast.NAKACK, UNICAST2, pbcast.STABLE, pbcast.GMS, UFC, MFC, FRAG2, RSVP
> JDG protocol list (UDP): PING, MERGE2, FD_SOCK, FD_ALL, pbcast.NAKACK, UNICAST2, pbcast.STABLE, pbcast.GMS, UFC, MFC, FRAG2, RSVP
> AS7 protocol list (TCP): MPING, MERGE2, FD_SOCK, FD, VERIFY_SUSPECT, BARRIER, pbcast.NAKACK, UNICAST2, pbcast.STABLE, pbcast.GMS, UFC, MFC, FRAG2, RSVP
> JDG protocol list (TCP): MPING, MERGE2, FD_SOCK, FD, VERIFY_SUSPECT, pbcast.NAKACK, UNICAST2, pbcast.STABLE, pbcast.GMS, UFC, MFC, FRAG2, RSVP
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (WFLY-3788) Upgrade org.apache.httpcomponents:httpclient to 4.3.2
by Jim Ma (JIRA)
Jim Ma created WFLY-3788:
----------------------------
Summary: Upgrade org.apache.httpcomponents:httpclient to 4.3.2
Key: WFLY-3788
URL: https://issues.jboss.org/browse/WFLY-3788
Project: WildFly
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 8.1.0.Final
Reporter: Jim Ma
Assignee: Alessio Soldano
Fix For: 9.0.0.Final
Webservice needs this upgrade to enable asynchronous client http transport in cxf 3.x.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1875:
---------------------------
Description:
If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
* B needs to get the lowest and highest seqno sent from A
* B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
* B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}}
* B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
* B creates an entry for A with the lowest and highest seqnos
* B sends a {{SYNC-ACK}} to A
* A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again
* A and B now use the usual protocols to retransmit missing messages
was:
If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
* B needs to get the lowest and highest seqno sent from A
* B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
* B sets a flag that discards all {{STABLE}} messages on reception of {{SYNC}}
* B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
* B creates an entry for A with the lowest and highest seqnos
* B sends a {{SYNC-DONE}} to A
* A resets the flag and starts accepting {{STABLE}} messages from B again
* A and B now use the usual protocols to retransmit missing messages
> UNICAST3/UNICAST2: sync receiver table with sender table
> --------------------------------------------------------
>
> Key: JGRP-1875
> URL: https://issues.jboss.org/browse/JGRP-1875
> Project: JGroups
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}).
> To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g.
> * B needs to get the lowest and highest seqno sent from A
> * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message)
> * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}}
> * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos
> * B creates an entry for A with the lowest and highest seqnos
> * B sends a {{SYNC-ACK}} to A
> * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again
> * A and B now use the usual protocols to retransmit missing messages
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months