[JBoss JIRA] (JGRP-2024) Receiving messages out of order.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2024?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2024:
--------------------------------
The second bug in your code is in this line:
{code}
channel.send(new Message(null, fileByte, 0, fileByte.length));
{code}
This will read the last line that is less than 128 bytes incorrectly. The correct line should be
{code}
channel.send(new Message(null, fileByte, 0, bytesRead));
{code}
I attached the correct version, you need to change the file paths.
> Receiving messages out of order.
> --------------------------------
>
> Key: JGRP-2024
> URL: https://issues.jboss.org/browse/JGRP-2024
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7, 3.6.8
> Environment: RedHat 6.7
> Java 1.8.0 Update 45
> Reporter: Dylan Turnbull
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: jGroups Unit Test.zip
>
>
> After splitting a file into smaller messages and send them down the channel the messages are received on the other side out of order.
> Below is a sample output:
> *+On the sender:+*
> Sending...
> Data Sent:
> Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy te
> -----------------------------------------------------
> Data Sent:
> xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur
> -----------------------------------------------------
> Data Sent:
> vived not only five centuries, but also the leap into electronic typesetting, re
> -----------------------------------------------------
> Data Sent:
> d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passag
> *+On the receiver:+*
> Listening...
> Data Received:
> xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur
> -----------------------------------------------------
> Data Received:
> vived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularise
> -----------------------------------------------------
> Data Received:
> d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
> Data Received:
> ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
> Data Received:
> ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2024) Receiving messages out of order.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2024?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2024:
--------------------------------
You're reusing the buffer into which you read the text. Since a message can be queued at the transport level, re-reading data into the same buffer might change it while the message is still being sent.
I changed this to create a new buffer every time you read data, but I'm adding code to verify the correct order automatically, comparing the text line-by-line kills my eyes... :-)
> Receiving messages out of order.
> --------------------------------
>
> Key: JGRP-2024
> URL: https://issues.jboss.org/browse/JGRP-2024
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7, 3.6.8
> Environment: RedHat 6.7
> Java 1.8.0 Update 45
> Reporter: Dylan Turnbull
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: jGroups Unit Test.zip
>
>
> After splitting a file into smaller messages and send them down the channel the messages are received on the other side out of order.
> Below is a sample output:
> *+On the sender:+*
> Sending...
> Data Sent:
> Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy te
> -----------------------------------------------------
> Data Sent:
> xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur
> -----------------------------------------------------
> Data Sent:
> vived not only five centuries, but also the leap into electronic typesetting, re
> -----------------------------------------------------
> Data Sent:
> d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passag
> *+On the receiver:+*
> Listening...
> Data Received:
> xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur
> -----------------------------------------------------
> Data Received:
> vived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularise
> -----------------------------------------------------
> Data Received:
> d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
> Data Received:
> ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
> Data Received:
> ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2024) Receiving messages out of order.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2024?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2024:
---------------------------
Fix Version/s: 4.0
> Receiving messages out of order.
> --------------------------------
>
> Key: JGRP-2024
> URL: https://issues.jboss.org/browse/JGRP-2024
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7, 3.6.8
> Environment: RedHat 6.7
> Java 1.8.0 Update 45
> Reporter: Dylan Turnbull
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: jGroups Unit Test.zip
>
>
> After splitting a file into smaller messages and send them down the channel the messages are received on the other side out of order.
> Below is a sample output:
> *+On the sender:+*
> Sending...
> Data Sent:
> Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy te
> -----------------------------------------------------
> Data Sent:
> xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur
> -----------------------------------------------------
> Data Sent:
> vived not only five centuries, but also the leap into electronic typesetting, re
> -----------------------------------------------------
> Data Sent:
> d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passag
> *+On the receiver:+*
> Listening...
> Data Received:
> xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur
> -----------------------------------------------------
> Data Received:
> vived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularise
> -----------------------------------------------------
> Data Received:
> d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
> Data Received:
> ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
> Data Received:
> ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2024) Receiving messages out of order.
by Dylan Turnbull (JIRA)
[ https://issues.jboss.org/browse/JGRP-2024?page=com.atlassian.jira.plugin.... ]
Dylan Turnbull commented on JGRP-2024:
--------------------------------------
In another test project I setup to troubleshoot this issue I noticed that while payload was coming in in the wrong order, the headers were coming in correctly. this means that the payload was getting separated from the header (I assume because if bundling), then being paired up with the header again, but not with the same header it had been paired with originally.
When I put my data in the header itself and sent the message with a null payload I found the data would be received in order.
> Receiving messages out of order.
> --------------------------------
>
> Key: JGRP-2024
> URL: https://issues.jboss.org/browse/JGRP-2024
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7, 3.6.8
> Environment: RedHat 6.7
> Java 1.8.0 Update 45
> Reporter: Dylan Turnbull
> Assignee: Bela Ban
> Attachments: jGroups Unit Test.zip
>
>
> After splitting a file into smaller messages and send them down the channel the messages are received on the other side out of order.
> Below is a sample output:
> *+On the sender:+*
> Sending...
> Data Sent:
> Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy te
> -----------------------------------------------------
> Data Sent:
> xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur
> -----------------------------------------------------
> Data Sent:
> vived not only five centuries, but also the leap into electronic typesetting, re
> -----------------------------------------------------
> Data Sent:
> d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passag
> *+On the receiver:+*
> Listening...
> Data Received:
> xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur
> -----------------------------------------------------
> Data Received:
> vived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularise
> -----------------------------------------------------
> Data Received:
> d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
> Data Received:
> ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
> Data Received:
> ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so
> -----------------------------------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6057) JAXB bindings of XmlJavaTypeAdapter are ignored
by Jeremy Karlson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6057?page=com.atlassian.jira.plugin.... ]
Jeremy Karlson commented on WFLY-6057:
--------------------------------------
I'm also running into this issue trying to migrate a project from AS 7 to WildFly 10.
> JAXB bindings of XmlJavaTypeAdapter are ignored
> -----------------------------------------------
>
> Key: WFLY-6057
> URL: https://issues.jboss.org/browse/WFLY-6057
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 10.0.0.CR5
> Reporter: George Turner
> Assignee: Alessio Soldano
>
> I filed this problem in WF8, and I still cannot get it to work in WF10
> Every xsd:date field prints as a xs:dateTime, and ignores by custom bindings.
> Here is my setup:
> binding.xjb
> <?xml version="1.0" encoding="UTF-8"?>
> <bindings xmlns="http://java.sun.com/xml/ns/jaxb"
> xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> extensionBindingPrefixes="xjc" version="2.1">
> <globalBindings
> choiceContentProperty="true" generateIsSetMethod="true" typesafeEnumMaxMembers="2000">
> <xjc:javaType name="java.util.Date" xmlType="xs:date"
> adapter="com.lmco.spacefence.infrastructure.webservices.util.XmlDateAdapter"/>
> <xjc:serializable/>
> </globalBindings>
> </bindings>
> package-info.java
> @XmlJavaTypeAdapters({
> @XmlJavaTypeAdapter(value = XmlDateAdapter.class, type = java.util.Date.class),
> @XmlJavaTypeAdapter(value = XmlDatetimeAdapter.class, type = java.util.Calendar.class)
> })
> package com.lmco.spacefence.infrastructure.webservices.util;
> import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
> import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapters;
> XmlDateAdapter.java
> package com.lmco.spacefence.infrastructure.webservices.util;
> import java.text.SimpleDateFormat;
> import java.util.Date;
> import javax.xml.bind.annotation.adapters.XmlAdapter;
> /**
> * Class is used to marshal/unmarshal String/Date in XML.
> */
> public class XmlDateAdapter extends XmlAdapter<String, Date> {
> /**
> * Parses a Date value from the String.
> *
> * @param value to unmarshal
> * @return the parsed Date
> */
> @Override
> public Date unmarshal(String value) throws Exception {
> if (value == null) {
> return null;
> }
> SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
> return sdf.parse(value);
> }
> /**
> * Prints the Date value as a String.
> *
> * @param value to marshal
> * @return the String of the Date
> */
> @Override
> public String marshal(Date value) throws Exception {
> if (value == null) {
> return null;
> }
> SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
> return sdf.format(value);
> }
> }
> Field in generated source class from cxf-codegen-plugin using binding.xjb
> @XmlJavaTypeAdapter(XmlDateAdapter.class)
> protected Date createDate;
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1396) Delete GlobalOperationHandlers cruft about not register write-attribute handlers on ProcessType.DOMAIN_SERVER
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1396?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1396:
-------------------------------------
Description:
GlobalOperationHandlers.registerGlobalOperations has a block where it appears not to register handlers for write-attribute and undefine-attribute if the process type is ProcessType.DOMAIN_SERVER.
But ProcessType.DOMAIN_SERVER is never the value passed as the param, so the if check has no effect and if the block ever didn't execute the server would not be properly manageable, since the HC sends over write-attribute and undefine-attribute ops.
So delete it.
was:
GlobalOperationHandlers.registerGlobalOperations has a block where it appears not to register handlers for write-attribute and undefine-attribute if the process type is ProcessType.DOMAIN_SERVER.
But ProcessType.DOMAIN_SERVER is never the value passed as the param, so the block has no effect and if it ever took effect the server would not be properly manageable, since the HC sends over write-attribute and undefine-attribute ops.
So delete it.
> Delete GlobalOperationHandlers cruft about not register write-attribute handlers on ProcessType.DOMAIN_SERVER
> -------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1396
> URL: https://issues.jboss.org/browse/WFCORE-1396
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Affects Versions: 2.1.0.CR1
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 3.0.0.Alpha1
>
>
> GlobalOperationHandlers.registerGlobalOperations has a block where it appears not to register handlers for write-attribute and undefine-attribute if the process type is ProcessType.DOMAIN_SERVER.
> But ProcessType.DOMAIN_SERVER is never the value passed as the param, so the if check has no effect and if the block ever didn't execute the server would not be properly manageable, since the HC sends over write-attribute and undefine-attribute ops.
> So delete it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2024) Receiving messages out of order.
by Dylan Turnbull (JIRA)
Dylan Turnbull created JGRP-2024:
------------------------------------
Summary: Receiving messages out of order.
Key: JGRP-2024
URL: https://issues.jboss.org/browse/JGRP-2024
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.8, 3.6.7
Environment: RedHat 6.7
Java 1.8.0 Update 45
Reporter: Dylan Turnbull
Assignee: Bela Ban
Attachments: jGroups Unit Test.zip
After splitting a file into smaller messages and send them down the channel the messages are received on the other side out of order.
Below is a sample output:
*+On the sender:+*
Sending...
Data Sent:
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy te
-----------------------------------------------------
Data Sent:
xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur
-----------------------------------------------------
Data Sent:
vived not only five centuries, but also the leap into electronic typesetting, re
-----------------------------------------------------
Data Sent:
d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passag
*+On the receiver:+*
Listening...
Data Received:
xt ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has sur
-----------------------------------------------------
Data Received:
vived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularise
-----------------------------------------------------
Data Received:
d in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing so
-----------------------------------------------------
Data Received:
ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so
-----------------------------------------------------
Data Received:
ftware like Aldus PageMaker including versions of Lorem Ipsum.Lorem Ipsum passages, and more recently with desktop publishing so
-----------------------------------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6321) Create tool to monitor clustering thread pool usage
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6321?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-6321:
-------------------------------------------
Need to answer two questions:
- why are there never any active threads shown at the monitoring intervals?
- does infinispan ever allocate per-cache executors? (I added code to chjeck for duplicate additions to the map and did not see any)
> Create tool to monitor clustering thread pool usage
> ---------------------------------------------------
>
> Key: WFLY-6321
> URL: https://issues.jboss.org/browse/WFLY-6321
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
>
> Scheduled executors and thread pools are used widely in JGroups and Infinispan for asynchronously executing tasks. When thread pools are not adequately sized to the load they are subjected to, this can lead to performance problems.
> It would be helpful if we could see thread pool usage as a function of elapse time during performance runs, in order to diagnose potential thread pool issues.
> This task will provide a Byteman-based tool to monitor threadpool usage and allow a report to be attached to SmartFrog test jobs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6321) Create tool to monitor clustering thread pool usage
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6321?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-6321:
-------------------------------------------
Example of the output at the end of an ejbremote-dist-async job:
{noformat}
(JGroups Periodic Helper Thread) [BYTEMAN-P] periodicTrigger called by thread
(JGroups Periodic Helper Thread) PERIODIC STATS FOR JGROUPS THREAD POOL EXECUTORS (perf33):
(JGroups Periodic Helper Thread) EXECUTOR: internal, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [2, 0, 0, 720116]
(JGroups Periodic Helper Thread) EXECUTOR: oob, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [20, 0, 0, 71]
(JGroups Periodic Helper Thread) EXECUTOR: regular/default, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [300, 0, 0, 3929261]
(JGroups Periodic Helper Thread)
(Infinispan Periodic Helper Thread) [BYTEMAN-P] periodicTrigger called by thread
(Infinispan Periodic Helper Thread) PERIODIC STATS FOR THREAD POOL EXECUTORS (perf33):
(Infinispan Periodic Helper Thread) EXECUTOR: ejb:org.infinispan.executors.async, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [n/a, n/a, n/a, n/a]
(Infinispan Periodic Helper Thread) EXECUTOR: ejb:org.infinispan.executors.expiration, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 3, 126]
(Infinispan Periodic Helper Thread) EXECUTOR: ejb:org.infinispan.executors.notification, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [n/a, n/a, n/a, n/a]
(Infinispan Periodic Helper Thread) EXECUTOR: ejb:org.infinispan.executors.persistence, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 0, 84]
(Infinispan Periodic Helper Thread) EXECUTOR: ejb:org.infinispan.executors.remote, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 0, 12]
(Infinispan Periodic Helper Thread) EXECUTOR: ejb:org.infinispan.executors.stateTransferExecutor, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 0, 246]
(Infinispan Periodic Helper Thread) EXECUTOR: ejb:org.infinispan.executors.timeout, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 0, 16]
(Infinispan Periodic Helper Thread) EXECUTOR: ejb:org.infinispan.executors.transport, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [7, 0, 0, 7]
(Infinispan Periodic Helper Thread) EXECUTOR: hibernate:org.infinispan.executors.notification, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [n/a, n/a, n/a, n/a]
(Infinispan Periodic Helper Thread) EXECUTOR: hibernate:org.infinispan.executors.remote, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [n/a, n/a, n/a, n/a]
(Infinispan Periodic Helper Thread) EXECUTOR: hibernate:org.infinispan.executors.timeout, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 0, 1]
(Infinispan Periodic Helper Thread) EXECUTOR: hibernate:org.infinispan.executors.transport, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 0, 1]
(Infinispan Periodic Helper Thread) EXECUTOR: server:org.infinispan.executors.notification, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [n/a, n/a, n/a, n/a]
(Infinispan Periodic Helper Thread) EXECUTOR: server:org.infinispan.executors.remote, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [n/a, n/a, n/a, n/a]
(Infinispan Periodic Helper Thread) EXECUTOR: server:org.infinispan.executors.timeout, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 0, 1]
(Infinispan Periodic Helper Thread) EXECUTOR: server:org.infinispan.executors.transport, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 0, 1]
(Infinispan Periodic Helper Thread) EXECUTOR: web:org.infinispan.executors.async, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [n/a, n/a, n/a, n/a]
(Infinispan Periodic Helper Thread) EXECUTOR: web:org.infinispan.executors.expiration, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 4, 168]
(Infinispan Periodic Helper Thread) EXECUTOR: web:org.infinispan.executors.notification, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [n/a, n/a, n/a, n/a]
(Infinispan Periodic Helper Thread) EXECUTOR: web:org.infinispan.executors.persistence, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 0, 126]
(Infinispan Periodic Helper Thread) EXECUTOR: web:org.infinispan.executors.remote, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 0, 16]
(Infinispan Periodic Helper Thread) EXECUTOR: web:org.infinispan.executors.stateTransferExecutor, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 0, 188]
(Infinispan Periodic Helper Thread) EXECUTOR: web:org.infinispan.executors.timeout, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [1, 0, 0, 21]
(Infinispan Periodic Helper Thread) EXECUTOR: web:org.infinispan.executors.transport, THREAD POOL: [pool, activePool, queuedTasks, completedTasks] = [10, 0, 0, 10]
{noformat}
> Create tool to monitor clustering thread pool usage
> ---------------------------------------------------
>
> Key: WFLY-6321
> URL: https://issues.jboss.org/browse/WFLY-6321
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
>
> Scheduled executors and thread pools are used widely in JGroups and Infinispan for asynchronously executing tasks. When thread pools are not adequately sized to the load they are subjected to, this can lead to performance problems.
> It would be helpful if we could see thread pool usage as a function of elapse time during performance runs, in order to diagnose potential thread pool issues.
> This task will provide a Byteman-based tool to monitor threadpool usage and allow a report to be attached to SmartFrog test jobs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1245) Improve readability of missing dependency logs
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1245?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1245:
------------------------------------------
Sorry for the delay on this. 1) seems ok. The change seems consistent with the javadoc at L280:
{code}
// See if any other services are known to the service container as being missing and aren't already
// tracked by this SVH as failed or directly missing. If any are found, that is some additional
// info to the user, so report that
{code}
It's debatable but I don't think this is a real good change for an EAP CP though. It's going to increase the size of the error report, and in some cases that may just be noise. It's fine for WF 11 and EAP 7.1 though.
> Improve readability of missing dependency logs
> ----------------------------------------------
>
> Key: WFCORE-1245
> URL: https://issues.jboss.org/browse/WFCORE-1245
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Dennis Reed
> Attachments: after_1.log, after_2.log, before.log, bz1283294-reproducer.zip
>
>
> When deploying an ear using initialize-in-order option, if one of the subdeployments contains an EJB that depends on an EJB from another subdeployment and the dependency subdeployment fails log output makes it hard to understand the root cause.
> Structure of deployment is as follows:
> {noformat}
> reproducer.ear
> |- service-locator.jar
> | |- ServiceLocator (Stateless EJB)
> | |- TestQueue (JNDI Resource)
> |- client.jar
> |- TestEjb (Stateless EJB)
> |- ServiceLocator
> {noformat}
> If the TestQueue JNDI resource cannot be injected in the ServiceLocator, the deployment failure output lists a number of missing services per each EJB in the dependant subdeployment (.ORB, .HandleDelegate, .ValidatorFactory, etc).
> When the dependant subdeployment has a larger number of EJBs the log output very quickly becomes hard to read.
> Example with a single dependant EJB:
> {noformat}
> 14:27:43,092 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "reproducer-1.0-SNAPSHOT.ear"}) - failure description: {
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".batch.environment is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.ValidatorFactory is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.ORB is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.HandleDelegate is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]",
> "jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".deploymentCompleteService is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".deploymentCompleteService]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.InstanceName is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.Validator is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.service-locator.test_ServiceLocator.env.queue.TestQueue is missing [jboss.naming.context.java.jboss.resources.queue.TestQueue]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.InAppClientContainer is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]"
> ],
> "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".INSTALL",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".CLEANUP",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.JndiBindingsService",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.START",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".deploymentCompleteService",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".jndiDependencyService",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".moduleDeploymentRuntimeInformationStart",
> "jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".CLEANUP"
> ]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month