July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1389) Align domain.sh and standalone.sh logic about adding -server

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1389?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1389: ------------------------------------------ [~ctomc] is this still valid? > Align domain.sh and standalone.sh logic about adding -server > ------------------------------------------------------------ > > Key: WFCORE-1389 > URL: https://issues.jboss.org/browse/WFCORE-1389 > Project: WildFly Core > Issue Type: Task > Components: Scripts > Reporter: Brian Stansberry > > The domain.sh script has a number of JVM vendor checks it uses to decide whether to add -server to the jvm launch command. In standalone.sh it's simpler; it simply checks for OSX. > I can't see any reason this logic should be significantly different between the two cases, either the JVM vendor checks are needed in both or they aren't needed in either. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-346) Serve gzip encoded resources

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-346?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-346: ----------------------------------------- [~swd847] Does undertow support this? Since management no longer has its own webserver, this is now more of an Undertow RFE, perhaps with some Domain Management (and subsystem=undertow) integration to turn it on/off. > Serve gzip encoded resources > ---------------------------- > > Key: WFCORE-346 > URL: https://issues.jboss.org/browse/WFCORE-346 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Heiko Braun > > Generally you want two things to happen: > # serve files using #sendfile > # serve gzipped versions resources > Compressing resources in memory saves bandwidth but is suboptimal since the whole resource needs to be loaded into memory. > Jetty implements this like this: > - if the Accept-Encoding includes "gzip" > - and there is a ".gz" version of the file (eg. you request "style.css" and there is "style.css.gz") > then the ".gz" version is served. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6895) TimerService problem(duplicated resource)

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-6895?page=com.atlassian.jira.plugin.... ] Tomasz Adamski reassigned WFLY-6895: ------------------------------------ Assignee: Tomasz Adamski (was: Jason Greene) > TimerService problem(duplicated resource) > ----------------------------------------- > > Key: WFLY-6895 > URL: https://issues.jboss.org/browse/WFLY-6895 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Environment: Two standalone instances connected into a cluster. > *Master WildFly* > {code} > standalone.bat -c standalone-full-ha.xml -Djboss.node.name=master > {code} > *Slave WildFly* > {code} > standalone.bat -c standalone-full-ha.xml -Djboss.node.name=slave -Djboss.socket.binding.port-offset=100 > {code} > Both instances has the same singleton policy defined in singleton-full-ha.xml: > {code} > <singleton-policy name="scada-singleton" cache-container="server"> > <simple-election-policy> > <name-preferences>master</name-preferences> > </simple-election-policy> > </singleton-policy> > {code} > Reporter: Artur Kowalczyk > Assignee: Tomasz Adamski > > I found a problem with TimerService that occurs when your application is configured as a singleton deployment. > *Test Case* > # Start master node, the app is also started - OK > # Start slave node, the app is deployed but bot stared - OK > # Stop master node, the app is started on slave - OK > # Start master node, there is a preference for node name so the app will be started again on master and stopped in slave - OK > # Stop master node, the app should be started again on slave but an exception occur. - ERROR > {code} > 09:50:42,115 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."wildfly-ejb-in-ear.ear"."wildfly-ejb-in-ear-ejb.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "wildfly-ejb-in-ear-ejb.jar" of deployment "wildfly-ejb-in-ear.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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) > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0086: Failed to install management resources for TimerEJB > at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:82) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) > ... 5 more > Caused by: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource timer-service > at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290) > at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169) > at org.jboss.as.server.deployment.DeploymentResourceSupport.register(DeploymentResourceSupport.java:322) > at org.jboss.as.server.deployment.DeploymentResourceSupport.registerDeploymentSubResource(DeploymentResourceSupport.java:219) > at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.installManagementResource(EjbManagementDeploymentUnitProcessor.java:119) > at org.jboss.as.ejb3.deployment.processors.EjbManagementDeploymentUnitProcessor.deploy(EjbManagementDeploymentUnitProcessor.java:79) > ... 6 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3805) JGroupsBroadcastGroupConfiguration Serialization Problem

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3805?page=com.atlassian.jira.plugin.... ] Jason Greene closed WFLY-3805. ------------------------------ Resolution: Done Reopened to remove version > JGroupsBroadcastGroupConfiguration Serialization Problem > -------------------------------------------------------- > > Key: WFLY-3805 > URL: https://issues.jboss.org/browse/WFLY-3805 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final > Reporter: Yong Hao Gao > Assignee: Yong Hao Gao > Fix For: No Release > > > When configuring JMS connection factories using jgroups discovery group, the client will get serialization exceptions because we pass a JChannel which is not serializable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3805) JGroupsBroadcastGroupConfiguration Serialization Problem

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3805?page=com.atlassian.jira.plugin.... ] Jason Greene reopened WFLY-3805: -------------------------------- > JGroupsBroadcastGroupConfiguration Serialization Problem > -------------------------------------------------------- > > Key: WFLY-3805 > URL: https://issues.jboss.org/browse/WFLY-3805 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final > Reporter: Yong Hao Gao > Assignee: Yong Hao Gao > Fix For: 10.1.0.CR1 > > > When configuring JMS connection factories using jgroups discovery group, the client will get serialization exceptions because we pass a JChannel which is not serializable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3805) JGroupsBroadcastGroupConfiguration Serialization Problem

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3805?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3805: ------------------------------- Fix Version/s: No Release (was: 10.1.0.CR1) > JGroupsBroadcastGroupConfiguration Serialization Problem > -------------------------------------------------------- > > Key: WFLY-3805 > URL: https://issues.jboss.org/browse/WFLY-3805 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final > Reporter: Yong Hao Gao > Assignee: Yong Hao Gao > Fix For: No Release > > > When configuring JMS connection factories using jgroups discovery group, the client will get serialization exceptions because we pass a JChannel which is not serializable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-264) Add support for use1PcForAutoCommitTransactions

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-264?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-264: ------------------------------ Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > Add support for use1PcForAutoCommitTransactions > ----------------------------------------------- > > Key: WFLY-264 > URL: https://issues.jboss.org/browse/WFLY-264 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Priority: Minor > Fix For: 10.1.0.Final > > > Since clustered web sessions/SFSBs won't ever incur inter-node concurrent access, we can tolerate a 1PC commit optimization - which will reduce the number of RPCs involved in replication/distribution. This should result it a significant performance gains for REPL_SYNC and DIST_SYNC caches. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2845) On WildFly clean shutdown: failed marshalling rsp (UnsuccessfulResponse)

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-2845?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-2845: ------------------------------- Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > On WildFly clean shutdown: failed marshalling rsp (UnsuccessfulResponse) > ------------------------------------------------------------------------ > > Key: WFLY-2845 > URL: https://issues.jboss.org/browse/WFLY-2845 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.CR1 > Environment: RHEL6 x86_64; Oracle JDK 7 > Reporter: Michal Karm Babacek > Assignee: Paul Ferraro > Labels: clustering > Fix For: 10.1.0.Final > > > I've got two standalone-ha instances running on a one box. Each of these instances has {{<distributable/>}} [clusterbench|https://github.com/Karm/clusterbench/tree/simplified-and-pure] app deployed. When I start to shut the instances down via CLI command, one of them throws: > {noformat} > 08:59:33,341 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,shared=udp) ISPN000094: Received new cluster view: [jboss-eap-8.0/web|4] (1) [jboss-eap-8.0/web] > 08:59:33,368 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher > 08:59:33,379 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-0) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException > 08:59:33,380 ERROR [org.jgroups.blocks.RequestCorrelator] (remote-thread-1) failed marshalling rsp (UnsuccessfulResponse): java.lang.NullPointerException > 08:59:33,392 INFO [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Final-SNAPSHOT "WildFly" stopped in 558ms > {noformat} > In the log. It's a non-deterministic problem and it does not emerge always. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2297) Log reasons for implicit dependencies

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-2297?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-2297: ------------------------------- Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > Log reasons for implicit dependencies > ------------------------------------- > > Key: WFLY-2297 > URL: https://issues.jboss.org/browse/WFLY-2297 > Project: WildFly > Issue Type: Enhancement > Reporter: David Lloyd > Priority: Minor > Fix For: 10.1.0.Final > > > We should log a {{DEBUG}} or {{TRACE}} message whenever we add an implicit dependency to a module, documenting the reason for the addition (e.g. adding because it's a servlet deployment, or because a particular annotation was used, etc.) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2100) Vault.sh logging improvements

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-2100?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-2100: ------------------------------- Fix Version/s: 10.1.0.Final (was: 10.1.0.CR1) > Vault.sh logging improvements > ----------------------------- > > Key: WFLY-2100 > URL: https://issues.jboss.org/browse/WFLY-2100 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 8.0.0.Alpha4 > Reporter: Chris Dolphy > Assignee: Peter Skopek > Fix For: 10.1.0.Final > > > Several errors with vault.sh (ineractive Vault Tool) do not display enough information to debug. > For example, "Exception occurred:PBOX000128: Unable to encrypt data". It would be nice if there was some way to see the cause of this exception either with additional logging options, a verbose option or by default. This one is caused by VaultInteraction.java only displaying the localized error message of the exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016