February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1062) Deployments from the domain/data/content folder goes missing after few minutes if the Host controller is started with --backup option.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1062?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1062: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1265170|https://bugzilla.redhat.com/show_bug.cgi?id=1265170] from MODIFIED to ON_QA > Deployments from the domain/data/content folder goes missing after few minutes if the Host controller is started with --backup option. > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1062 > URL: https://issues.jboss.org/browse/WFCORE-1062 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR7 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Priority: Blocker > Fix For: 2.0.0.CR8 > > > Host controller started with --backup option deletes the deployments from the domain/data/content folder after approximately 10 mins. > The deployment is restored or recreated if the HostController is started. > Version-Release number of selected component (if applicable): 6.4.x > How reproducible: > Steps to Reproduce: > > 1. Setup domaincontroller > 2. Setup hostcontroller > 3. Start domaincontroller > 4. Start hostcontroller with --backup option. > 5. deploy an application using cli or admin console > ./jboss-cli.sh --connect --controller=x.x.x.x:9999 --command='deploy /PathToApp/App.war --server-groups=main-server-group' > 6. deployments are available under $JBOSS_HOME/domain/data/content > 7. Wait for approximately 10 minutes > 8. Cached deployments are deleted on hostcontroller (domain/data/content is empty). Following is the logging seen on the console : > ++++++++++++++ > [Host Controller] 14:20:40,439 INFO [org.jboss.as.repository] (Host Controller Service Threads - 4) JBAS014903: Content /NotBackedUp/JAR-Folder/EAPs/EAP6/jboss-eap-6.4.3-Patched/domain/data/content/47/1108a27fa1b82e6a92fb56ee25bc76f2625249 is obsolete and will be removed > [Host Controller] 14:20:40,440 INFO [org.jboss.as.repository] (Host Controller Service Threads - 4) JBAS014901: Content removed from location /NotBackedUp/JAR-Folder/EAPs/EAP6/jboss-eap-6.4.3-Patched/domain/data/content/47/1108a27fa1b82e6a92fb56ee25bc76f2625249/content > ++++++++++++++ > 9. After restarting the Host Controller, the deployment is restored and the cached deployment can now be seen under the Host Controller's domain/data/content folder. > Actual results: Deployment folder form domain/data/content folder gets deleted after approx 10 mins and are restored if the Host Controller is restarted > Expected results: The cached deplpyments folder should never be removed from the HostController's domain/data/content folder. > Additional info: This does not affect the availability of the application since the applications are also availbale with the assigned server's under their data/content folder. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5995) Initial calculation of the first expiration time for a scheduled timer is wrong if a start date is set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5995?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5995: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1298651|https://bugzilla.redhat.com/show_bug.cgi?id=1298651] from MODIFIED to ON_QA > Initial calculation of the first expiration time for a scheduled timer is wrong if a start date is set > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-5995 > URL: https://issues.jboss.org/browse/WFLY-5995 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.1.Final, 9.0.2.Final, 10.0.0.CR5 > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Labels: timers, timerservice > Fix For: 10.0.0.Final > > > If a scheduled timer should be created with the following parameters: > ScheduleExpression[second=0 minute=0/5 hour=20-22 dayOfWeek=* dayOfMonth=* month=* year=* start=Thu Jan 14 09:45:35 GMT+1 2016] > The first schedule should be > Thu Jan 17 20:00:20 GMT+1 2016 > but is calculated as > Sun Jan 17 20:45:35 GMT+1 2016 > The minutes are not correctly set according to the schedule and the given start date. > This happen for seconds/minutes if the ScheduleExpression limit the range. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1288) installing CP over one-off fails if the modules patched by the one-off are not patched in the CP

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1288?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1288: ------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1295999|https://bugzilla.redhat.com/show_bug.cgi?id=1295999] from MODIFIED to ON_QA > installing CP over one-off fails if the modules patched by the one-off are not patched in the CP > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1288 > URL: https://issues.jboss.org/browse/WFCORE-1288 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 1.0.1.Final > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Priority: Critical > Fix For: 2.0.8.Final > > > If a CP is installed over active one-off patches, the patch application may fail if the CP does not contain updates for the modules that were patched by the one-offs. > Normally, CP patches accumulate the one-off patches released since the previous CP which is, probably, why this bug has not been discovered for a long time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1311) emptyManagedConnectionPool can cause dead lock

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1311?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1311: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1310671|https://bugzilla.redhat.com/show_bug.cgi?id=1310671] from MODIFIED to ON_QA > emptyManagedConnectionPool can cause dead lock > ---------------------------------------------- > > Key: JBJCA-1311 > URL: https://issues.jboss.org/browse/JBJCA-1311 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: WildFly/IronJacamar 1.3.2.Final, 1.0.35.Final, 1.2.6.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: WildFly/IronJacamar 1.3.3.Final, 1.0.36.Final, 1.2.7.Final > > > Can happen in scenarios where multiple credentials are used for the pool (PoolByCri / PoolByCRIAndSubject) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-313) Deadlock in WsRemoteEndpointImplServer.onWritePossible

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-313?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBWEB-313: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1299057|https://bugzilla.redhat.com/show_bug.cgi?id=1299057] from MODIFIED to ON_QA > Deadlock in WsRemoteEndpointImplServer.onWritePossible > ------------------------------------------------------ > > Key: JBWEB-313 > URL: https://issues.jboss.org/browse/JBWEB-313 > Project: JBoss Web > Issue Type: Bug > Affects Versions: JBossWeb-7.5.0.GA > Environment: JBoss EAP 6.4.5 > Reporter: Aaron Ogburn > Assignee: Remy Maucherat > Attachments: JBWEB-313.patch > > > A deadlock is possible in WsRemoteEndpointImplServer.onWritePossible: > {code} > http-/0.0.0.0:8080-1": > at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:93) > - waiting to lock <0x00000006dee6a1a8> (a java.nio.HeapByteBuffer) > - locked <0x00000006dee6a200> (a java.lang.Object) > at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsWriteListener.onWritePossible(WsHttpUpgradeHandler.java:243) > at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:605) > at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) > at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) > at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) > at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:252) > at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) > at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) > at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228) > at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:232) > at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) > at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:939) > - locked <0x00000006deeeb9c0> (a java.lang.Object) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at org.apache.tomcat.util.net.NioEndpoint$DefaultThreadFactory$1$1.run(NioEndpoint.java:1249) > at java.lang.Thread.run(Thread.java:745) > "EJB default - 1": > at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:81) > - waiting to lock <0x00000006dee6a200> (a java.lang.Object) > at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(WsRemoteEndpointImplServer.java:76) > at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:444) > at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:334) > at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$TextMessageSendHandler.write(WsRemoteEndpointImplBase.java:741) > - locked <0x00000006dee6a1a8> (a java.nio.HeapByteBuffer) > at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(WsRemoteEndpointImplBase.java:239) > at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:182) > at org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2948) Welcome file does not work for *.jsf

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2948?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2948: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1256325|https://bugzilla.redhat.com/show_bug.cgi?id=1256325] from MODIFIED to ON_QA > Welcome file does not work for *.jsf > -------------------------------------- > > Key: WFLY-2948 > URL: https://issues.jboss.org/browse/WFLY-2948 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Reporter: Gulam Samdani > Assignee: Remy Maucherat > Priority: Minor > Fix For: 8.1.0.CR1, 8.1.0.Final > > > Welcome file does not work for *.jsf > -------------------------------------------------------- > same problem not exists in Wildfly Beta but wildfly 8 final /cr1 gives this error ... > > problem : > > http://localhost:8080/hello ------------------------------ NO works*** > @http://localhost:8080/hello/index.jsf ------------- it works fine > ======================================= > <welcome-file-list> > > <welcome-file>index.jsf</welcome-file> > > </welcome-file-list> > <servlet> > <servlet-name>Faces Servlet</servlet-name> > <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> > <load-on-startup>1</load-on-startup> > </servlet> > <servlet-mapping> > <servlet-name>Faces Servlet</servlet-name> > <url-pattern>*.jsf</url-pattern> > </servlet-mapping> > </web-app> > ------------------------------------------------- > Reproduce this error : > https://community.jboss.org/message/857300 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5962) ServletContainerInitializers from jboss-deployment-structure.xml module dependencies are not invoked

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5962?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5962: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1297877|https://bugzilla.redhat.com/show_bug.cgi?id=1297877] from MODIFIED to ON_QA > ServletContainerInitializers from jboss-deployment-structure.xml module dependencies are not invoked > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-5962 > URL: https://issues.jboss.org/browse/WFLY-5962 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR5 > Reporter: Aaron Ogburn > Assignee: Stuart Douglas > Fix For: 10.0.0.Final > > Attachments: WFLY5962test.zip > > > If a module includes a ServletContainerInitializer, that ServletContainerInitializer is not invoked for any applications that include the module in its jboss-deployment-structure.xml module dependencies. It looks like the ServletContainerInitializerDeploymentProcessor only checks server provided dependencies. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-753) When WFCORE is run as a service in linux, the working directory is "/"

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-753?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-753: ------------------------------------------------ Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1222855|https://bugzilla.redhat.com/show_bug.cgi?id=1222855] from MODIFIED to ON_QA > When WFCORE is run as a service in linux, the working directory is "/" > ---------------------------------------------------------------------- > > Key: WFCORE-753 > URL: https://issues.jboss.org/browse/WFCORE-753 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 2.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5242) Inconsistent format for IPv6 addresses in server log

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5242?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5242: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1260566|https://bugzilla.redhat.com/show_bug.cgi?id=1260566] from MODIFIED to ON_QA > Inconsistent format for IPv6 addresses in server log > ---------------------------------------------------- > > Key: WFLY-5242 > URL: https://issues.jboss.org/browse/WFLY-5242 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Beta2 > Reporter: Lyle Wang > Assignee: Chao Wang > Priority: Minor > Fix For: 10.0.0.CR1 > > > Description of problem: > When IPv6 is used, square brackets for IPv6 addresses are missed in some of log entries. Specifically, the address format from Undertow logs is different from those "WFLYSRV" logs. > How reproducible: > Always > Steps to Reproduce: > 1. Config IPv6 (example: https://docs.jboss.org/author/display/WFLY10/Interfaces+and+ports) > 2. Start WildFly and check the log > Actual results: > ---------------------------------------- > 2015-08-31 12:51:47,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /0:0:0:0:0:0:0:1:8080 > ...... > 2015-08-31 12:51:48,431 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[::1]:9993/management > 2015-08-31 12:51:48,432 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[::1]:9993 > ---------------------------------------- > In Undertow logs it's like "/0:0:0:0:0:0:0:1:8080" but in WildFly server logs "http://[::1]:9993/management" > Expected results: > Consistent format should be used for IPv6 address across different components and the address is enclosed in square brackets [ ]. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-358) Wrap all LDAP testing in a single suite

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-358?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-358: -------------------------------- Note: by moving server start into testsuite decreased build time *from 2m:10s to 1m:40s* > Wrap all LDAP testing in a single suite > --------------------------------------- > > Key: ELY-358 > URL: https://issues.jboss.org/browse/ELY-358 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Testsuite > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Fix For: 1.1.0.Beta5 > > > If we wrap all these tests in a single suite we can start up the LDAP server one, run all the tests and then stop the server - this will stop us incurring the set-up / tear-down cost for each test case. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2016