[JBoss JIRA] (WFLY-6082) NullPointerException on jar fetch from server by client
by George Turner (JIRA)
[ https://issues.jboss.org/browse/WFLY-6082?page=com.atlassian.jira.plugin.... ]
George Turner closed WFLY-6082.
-------------------------------
This issue no longer occurred in 10 Final
> NullPointerException on jar fetch from server by client
> -------------------------------------------------------
>
> Key: WFLY-6082
> URL: https://issues.jboss.org/browse/WFLY-6082
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR5
> Environment: RedHat 7 server
> java version "1.8.0_05"
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
> Reporter: George Turner
> Assignee: Stuart Douglas
>
> JNLP client requests is jars and this error is thrown for all requests, but the client successfully retrieves the jar(s)
> 2016-01-27 11:16:10,549 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /premiereclient/plugins/org.eclipse.swt.win32.win32.x86_64_3.103.2.v20150203-1351.jar: java.lang.NullPointerException
> at io.undertow.server.protocol.http.HttpResponseConduit.transferFrom(HttpResponseConduit.java:664)
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.transferFrom(AbstractFixedLengthStreamSinkConduit.java:193)
> at org.xnio.conduits.ConduitStreamSinkChannel.transferFrom(ConduitStreamSinkChannel.java:142)
> at io.undertow.channels.DetachableStreamSinkChannel.transferFrom(DetachableStreamSinkChannel.java:127)
> at io.undertow.server.HttpServerExchange$WriteDispatchChannel.transferFrom(HttpServerExchange.java:1951)
> at org.xnio.channels.Channels.transferBlocking(Channels.java:512)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.transferFrom(ServletOutputStreamImpl.java:528)
> at io.undertow.io.BlockingSenderImpl.performTransfer(BlockingSenderImpl.java:142)
> at io.undertow.io.BlockingSenderImpl.transferFrom(BlockingSenderImpl.java:135)
> at io.undertow.server.handlers.resource.PathResource$1TransferTask.run(PathResource.java:217)
> at io.undertow.server.handlers.resource.PathResource.serveImpl(PathResource.java:247)
> at io.undertow.server.handlers.resource.PathResource.serve(PathResource.java:105)
> at org.wildfly.extension.undertow.deployment.ServletResource.serve(ServletResource.java:95)
> at io.undertow.server.handlers.resource.CachedResource.serve(CachedResource.java:168)
> at io.undertow.servlet.handlers.DefaultServlet.serveFileBlocking(DefaultServlet.java:358)
> at io.undertow.servlet.handlers.DefaultServlet.doGet(DefaultServlet.java:180)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> I can access the URL with a browser and see the list of the files using:
> http://localhost:8080/premiereclient/plugins/
> which is the same path shown in the error
--
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 George Turner (JIRA)
[ https://issues.jboss.org/browse/WFLY-6057?page=com.atlassian.jira.plugin.... ]
George Turner commented on WFLY-6057:
-------------------------------------
I flat gave up on trying to get it to work and stayed with XMLGregorianCalendar.
> 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] (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 resolved WFLY-6321.
---------------------------------------
Resolution: Done
The first draft of the tool is complete and in use on the example job.
> 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 edited comment on WFLY-6321 at 3/7/16 9:56 AM:
-------------------------------------------------------------------
Need to answer two questions:
- why are there never any active threads shown at the monitoring intervals?
-- can't say why, other than the tasks involved my have a very short duration
-- writing up an example program which monitors executors and uses long running tasks, the active tasks are clearly visible
- does infinispan ever allocate per-cache executors?
-- I added code to check for duplicate additions to the map and did not see any ...
was (Author: rachmato):
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-5437) Occassional stale data with remote EJB invocations and sync cache
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-5437?page=com.atlassian.jira.plugin.... ]
Michal Vinkler commented on WFLY-5437:
--------------------------------------
Our tests seem to be working as expected.
In ER6, this issue was observed only in one async scenario, 55 occurrences.
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
In ER5, there were some occurrences in 3 async scenarios, and also 1 occurrence in sync scenario (it happened 30 seconds after perf19 was killed, so it doesn't seem to be tied directly to the failover):
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
It was not observed at all in ER4.
To summarize: the issue happens intermittently in async scenarios, very rarely in sync scenarios. The issue doesn't seem to be tied directly to the failover.
> Occassional stale data with remote EJB invocations and sync cache
> -----------------------------------------------------------------
>
> Key: WFLY-5437
> URL: https://issues.jboss.org/browse/WFLY-5437
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR1
> Reporter: Richard Janík
> Assignee: Paul Ferraro
>
> Hi,
> we're occasionally getting stale data on remote EJB invocations (number counter returns number 1 lower than expected, see example). -This is usually preceded (~6 seconds before that) by cluster wide rebalance after a node is brought back from dead.-
> - 2000 clients, stale data is uncommon
> - requests from a single client are separated by a 4 second window.
> An example of stale data:
> {code}
> 2015/08/28 13:01:35:442 EDT [WARN ][Runner - 640] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Response serial does not match. Expected: 86, received: 85, runner: 640.>
> {code}
> And a link to our jobs if you're interested:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-...
> This behavior has so far been observed with jvmkill and undeploy scenario, on REPL-SYNC and DIST-SYNC caches.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6330) Problems with ActiveMQ-client-global-threads
by Lukasz Pater (JIRA)
[ https://issues.jboss.org/browse/WFLY-6330?page=com.atlassian.jira.plugin.... ]
Lukasz Pater updated WFLY-6330:
-------------------------------
Issue Type: Bug (was: Feature Request)
> Problems with ActiveMQ-client-global-threads
> --------------------------------------------
>
> Key: WFLY-6330
> URL: https://issues.jboss.org/browse/WFLY-6330
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Lukasz Pater
> Assignee: Jeff Mesnil
>
> Hello
> when using MDB to consume messages the system indefinitely creates ActiveMQ-client-global-threads (I don't need to produce/consume a message, it is enough for the MDB to be present). Moreover when redeploying the application the created threads remain in the memory.
> Cheers
> Lukasz
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6330) Problems with ActiveMQ-client-global-threads
by Lukasz Pater (JIRA)
Lukasz Pater created WFLY-6330:
----------------------------------
Summary: Problems with ActiveMQ-client-global-threads
Key: WFLY-6330
URL: https://issues.jboss.org/browse/WFLY-6330
Project: WildFly
Issue Type: Feature Request
Components: JMS
Affects Versions: 10.0.0.Final
Reporter: Lukasz Pater
Assignee: Jeff Mesnil
Hello
when using MDB to consume messages the system indefinitely creates ActiveMQ-client-global-threads (I don't need to produce/consume a message, it is enough for the MDB to be present). Moreover when redeploying the application the created threads remain in the memory.
Cheers
Lukasz
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6329) Deployment scanner logs ERROR when server is shutting down
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6329?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka reassigned WFLY-6329:
--------------------------------------
Assignee: Brian Stansberry (was: Jason Greene)
> Deployment scanner logs ERROR when server is shutting down
> ----------------------------------------------------------
>
> Key: WFLY-6329
> URL: https://issues.jboss.org/browse/WFLY-6329
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.Final
> Reporter: Ondřej Chaloupka
> Assignee: Brian Stansberry
> Priority: Minor
>
> It happens time to time that deployment scanner can throw and log error [1] when server is shutting down.
> It's in case of clean startup and clean shutdown when error messages should not be shown. I can hit it when unbounding a datasource takes a bit longer and scan of deployment scanner hits that time.
> [1]
> {code}
> ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /mnt/hudson_workspace/workspace/eap-70-jbossts-crashrec-tests-mssql2014/90fac01f/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/deployments threw Exception: java.lang.RuntimeException: WFLYDS0036: Deployment model operation failed. WFLYCTL0271: Operation cancelled
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.getDeploymentsStatus(DefaultDeploymentOperations.java:83)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1614)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1563)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:568)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:489)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:250)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6329) Deployment scanner logs ERROR when server is shutting down
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6329?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka updated WFLY-6329:
-----------------------------------
Priority: Major (was: Minor)
> Deployment scanner logs ERROR when server is shutting down
> ----------------------------------------------------------
>
> Key: WFLY-6329
> URL: https://issues.jboss.org/browse/WFLY-6329
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.Final
> Reporter: Ondřej Chaloupka
> Assignee: Brian Stansberry
>
> It happens time to time that deployment scanner can throw and log error [1] when server is shutting down.
> It's in case of clean startup and clean shutdown when error messages should not be shown. I can hit it when unbounding a datasource takes a bit longer and scan of deployment scanner hits that time.
> [1]
> {code}
> ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /mnt/hudson_workspace/workspace/eap-70-jbossts-crashrec-tests-mssql2014/90fac01f/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/deployments threw Exception: java.lang.RuntimeException: WFLYDS0036: Deployment model operation failed. WFLYCTL0271: Operation cancelled
> at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.getDeploymentsStatus(DefaultDeploymentOperations.java:83)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1614)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1563)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:568)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:489)
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:250)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month