[JBoss JIRA] (WFCORE-210) IO error during deployment scanning triggers undeployment
by James Livingston (JIRA)
James Livingston created WFCORE-210:
---------------------------------------
Summary: IO error during deployment scanning triggers undeployment
Key: WFCORE-210
URL: https://issues.jboss.org/browse/WFCORE-210
Project: WildFly Core
Issue Type: Bug
Components: Server
Affects Versions: 1.0.0.Alpha10
Reporter: James Livingston
Assignee: Jason Greene
If an IO error such as reaching the file descriptor limit occurs during deployment scanning, the scanner continues with an empty deployment list causing it to undeploy applications.
This occurs because FileSystemDeploymentService.scanDirectory() treats File.listFiles() returning null as an empty list rather than an error. http://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles%28%29 notes that it returns an empty array if the directory is empty, and null if it is not a directory or an IO error occurs.
It should instead respond to a null return value by aborting the scanner run, with a log message, and not proceed to undeploy applications.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 11 months
[JBoss JIRA] (WFLY-3754) EJB StatefulSessionComponentInstance methodMap includes final Object methods
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3754?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3754:
-----------------------------------------------
James Livingston <jlivings(a)redhat.com> changed the Status of [bug 1132270|https://bugzilla.redhat.com/show_bug.cgi?id=1132270] from NEW to CLOSED
> EJB StatefulSessionComponentInstance methodMap includes final Object methods
> ----------------------------------------------------------------------------
>
> Key: WFLY-3754
> URL: https://issues.jboss.org/browse/WFLY-3754
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: 8.1.0.Final
> Reporter: James Livingston
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> StatefulSessionComponentInstance has a methodMap which maintains the ChainedInterceptors for each method. That currently includes final Object methods which are not Business Methods for EJBs (EJB 3.1 4.9.5 "The method must not be declared as final or static"), which results in extra memory overhead for what I believe is the useless interceptors.
> The amount of memory a ChainedInterceptor consumes varies between JVMs, but it is between 280 and 400 bytes in some heap dumps I looked at. With 6 final methods (wait, notify*, getClass) on java.lang.Object that adds approximately 2kb of memory use to each instance of each SFSB.
> This can affect all BasicComponentInstance subclasses, but it is most noticeable for SFSBs due to the larger number of instances.
> The list of methods comes from ComponentConfiguration.getDefinedComponentMethods(), but I'm not sure if filtering the final methods out should be done there or an EJB-specific class since the rule about final methods is from the EJB spec. I'm also not sure if toString, equals and hashCode() should be treated as EJB business methods either.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 11 months
[JBoss JIRA] (WFLY-3873) AJP-connector mangles SOAP-request
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3873?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3873:
--------------------------------------
This should be fixed, do you have any way of reproducing it?
> AJP-connector mangles SOAP-request
> ----------------------------------
>
> Key: WFLY-3873
> URL: https://issues.jboss.org/browse/WFLY-3873
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Linux
> reverse-proxy from Apache 2.2 via mod_proxy_ajp to AJP connector on WildFly 8.1.0-Final
> Reporter: Gerke Ephorus
> Assignee: Stuart Douglas
> Labels: .net, ajp, soap
>
> When connecting to WildFly 8.1.0-Final SOAP-service from a .NET application via a reverse-proxy (Apache 2.2 with mod_proxy_ajp to the AJP-connector) it looks like the payload SOAP package gets mangled:
> {noformat}
> 2014-09-19 08:45:05,206 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-99) Interceptor for {http://ephorus.com/document-processor/ws/}DocumentProcessor has thrown exception, unwinding now: java.lang.RuntimeException:
> Couldn't parse stream.
> at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1447)
> at org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:123)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241)
> at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:93)
> at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:133)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-2.2.2.Final.jar:2.2.2.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:101) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0x95 (at char #4, byte #-1)
> at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:536)
> at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:585)
> at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:610)
> at com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:316)
> at __redirected.__XMLInputFactory.createXMLStreamReader(__XMLInputFactory.java:142) [jboss-modules.jar:1.3.3.Final]
> at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1445)
> ... 40 more
> Caused by: java.io.CharConversionException: Invalid UTF-8 start byte 0x95 (at char #4, byte #-1)
> at com.ctc.wstx.io.UTF8Reader.reportInvalidInitial(UTF8Reader.java:303)
> at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:189)
> at com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250)
> at com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133)
> at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:531)
> ... 45 more
> {noformat}
> Connecting to the same SOAP-service via the reverse-proxy via the AJP from a different party/client does not show this problem.
> Connecting to the same SOAP-service directly to the http-connector on the same WildFly 8.1.0-Final server does not show this problem.
> Wild guess is that it depends somehow on the HTTP-headers of the .NET client. These are the headers captured via Fiddler-http-proxy on the client-side:
> {noformat}
> POST http://some.host.com/doce/Foo/Bar HTTP/1.1
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.3082)
> Content-Type: text/xml; charset=utf-8
> SOAPAction: "http://host/some/soap-action/ws/addDocument"
> Host: some.host.com
> Content-Length: 6592
> Expect: 100-continue
> Connection: Keep-Alive
> Accept: application/json, text/plain, */*
> {noformat}
> There is a small change it's the same root-cause as [WFLY-2999]. Maybe I'll find the time to test this on 9.0.0-Beta1.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 11 months
[JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4037?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4037:
--------------------------------------
It looks like an issue with clustered SSO
> Error 500 accessing png,css, rest
> ---------------------------------
>
> Key: WFLY-4037
> URL: https://issues.jboss.org/browse/WFLY-4037
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Marcial Atiénzar Navarro
> Assignee: Paul Ferraro
> Priority: Critical
>
> I've this error:
> {code}
> 09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.CacheImpl.get(CacheImpl.java:377)
> at org.infinispan.CacheImpl.get(CacheImpl.java:369)
> at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
> at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
> at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
> at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77)
> at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38)
> at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50)
> at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 11 months
[JBoss JIRA] (JGRP-1888) FD_SOCK race condition during stop
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/JGRP-1888?page=com.atlassian.jira.plugin.... ]
Dennis Reed updated JGRP-1888:
------------------------------
Attachment: jgrp-1888-test.tar.gz
Attached test case (instead of checking it in, because it uses Byteman which isn't that easy to integrate into 2.6.x tests)
> FD_SOCK race condition during stop
> ----------------------------------
>
> Key: JGRP-1888
> URL: https://issues.jboss.org/browse/JGRP-1888
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.6.16
> Reporter: Dennis Reed
> Assignee: Dennis Reed
> Fix For: 2.6.23
>
> Attachments: jgrp-1888-test.tar.gz
>
>
> There is a race condition in FD_SOCK between stop() shutting down the pinger thread and the BroadcastTask.
> It first shuts down the broadcast task, and then the pinger thread.
> If the pinger thread generates a new suspected event in this interval, it re-starts the broadcast task, which creates a new thread suspecting that node repeatedly until the JVM exits.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 11 months
[JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.... ]
Karl Nicholas commented on WFLY-4044:
-------------------------------------
Just to add to the information: my fedora box is recently installed, and it installed OS updates and LibreOffice updates yesterday. I have a bit of python stuff on there, but nothing major. I have PyCharm (3.0.4?) installed.
> Wildfly service will not start on fedora 20 - 64 bit
> ----------------------------------------------------
>
> Key: WFLY-4044
> URL: https://issues.jboss.org/browse/WFLY-4044
> Project: WildFly
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.1.0.Final
> Environment: Fedora 20 - updates installed
> Reporter: Karl Nicholas
> Assignee: Marek Goldmann
>
> standalone.sh starts wildfly ok but systemctl start service fails:
> [root@localhost system]# yum install wildfly
> Loaded plugins: langpacks, refresh-packagekit
> Package wildfly-8.1.0-3.fc20.noarch already installed and latest version
> Nothing to do
> [root@localhost system]# systemctl start wildfly
> [root@localhost system]# systemctl status wildfly
> wildfly.service - The WildFly Application Server
> Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled)
> Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago
> Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE)
> Main PID: 7658 (code=exited, status=1/FAILURE)
> Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server.
> Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE
> Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state.
> [root@localhost system]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 11 months
[JBoss JIRA] (JGRP-1893) ENCRYPT: Thread safety issues during key changes
by Borisa Zivkovic (JIRA)
[ https://issues.jboss.org/browse/JGRP-1893?page=com.atlassian.jira.plugin.... ]
Borisa Zivkovic commented on JGRP-1893:
---------------------------------------
I am getting same exception (Windows 8, Hotspot (build 1.7.0_51-b13), JGroups 3.5.1.Final
Nov 02, 2014 3:01:59 PM org.jgroups.logging.JDKLogImpl error
SEVERE: failed setting ip_ttl
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339)
at org.jgroups.protocols.UDP.createSockets(UDP.java:368)
at org.jgroups.protocols.UDP.start(UDP.java:270)
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
at org.jgroups.JChannel.startStack(JChannel.java:889)
at org.jgroups.JChannel._preConnect(JChannel.java:547)
at org.jgroups.JChannel.connect(JChannel.java:282)
at org.jgroups.JChannel.connect(JChannel.java:273)
I am using udp.xml from jgroups-3.5.1.Fina.jar
> ENCRYPT: Thread safety issues during key changes
> ------------------------------------------------
>
> Key: JGRP-1893
> URL: https://issues.jboss.org/browse/JGRP-1893
> Project: JGroups
> Issue Type: Bug
> Reporter: Tero Leppikangas
> Assignee: Bela Ban
>
> For symmetric encryption, ENCRYPT has members with shared state: secret key, version and ciphers. In order for to provide consistent state between different threads accessing these members, they should be synchronized.
> I have implemented one solution by wrapping the state in separate object which can be found here:
> https://github.com/tepitebson/JGroups/tree/ENCRYPT_Thread_safety
> I also have replaced the WeakHashMap holding the previous keys with Cache in google's guava library so my solution probably is not suitable for an official solution.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 11 months
[JBoss JIRA] (JGRP-1893) ENCRYPT: Thread safety issues during key changes
by Borisa Zivkovic (JIRA)
[ https://issues.jboss.org/browse/JGRP-1893?page=com.atlassian.jira.plugin.... ]
Borisa Zivkovic edited comment on JGRP-1893 at 11/2/14 10:05 AM:
-----------------------------------------------------------------
I am getting same exception (Windows 8, Hotspot (build 1.7.0_51-b13), JGroups 3.5.1.Final
Nov 02, 2014 3:01:59 PM org.jgroups.logging.JDKLogImpl error
SEVERE: failed setting ip_ttl
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339)
at org.jgroups.protocols.UDP.createSockets(UDP.java:368)
at org.jgroups.protocols.UDP.start(UDP.java:270)
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
at org.jgroups.JChannel.startStack(JChannel.java:889)
at org.jgroups.JChannel._preConnect(JChannel.java:547)
at org.jgroups.JChannel.connect(JChannel.java:282)
at org.jgroups.JChannel.connect(JChannel.java:273)
I am using udp.xml from jgroups-3.5.1.Final.jar
was (Author: borisha):
I am getting same exception (Windows 8, Hotspot (build 1.7.0_51-b13), JGroups 3.5.1.Final
Nov 02, 2014 3:01:59 PM org.jgroups.logging.JDKLogImpl error
SEVERE: failed setting ip_ttl
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339)
at org.jgroups.protocols.UDP.createSockets(UDP.java:368)
at org.jgroups.protocols.UDP.start(UDP.java:270)
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
at org.jgroups.JChannel.startStack(JChannel.java:889)
at org.jgroups.JChannel._preConnect(JChannel.java:547)
at org.jgroups.JChannel.connect(JChannel.java:282)
at org.jgroups.JChannel.connect(JChannel.java:273)
I am using udp.xml from jgroups-3.5.1.Fina.jar
> ENCRYPT: Thread safety issues during key changes
> ------------------------------------------------
>
> Key: JGRP-1893
> URL: https://issues.jboss.org/browse/JGRP-1893
> Project: JGroups
> Issue Type: Bug
> Reporter: Tero Leppikangas
> Assignee: Bela Ban
>
> For symmetric encryption, ENCRYPT has members with shared state: secret key, version and ciphers. In order for to provide consistent state between different threads accessing these members, they should be synchronized.
> I have implemented one solution by wrapping the state in separate object which can be found here:
> https://github.com/tepitebson/JGroups/tree/ENCRYPT_Thread_safety
> I also have replaced the WeakHashMap holding the previous keys with Cache in google's guava library so my solution probably is not suitable for an official solution.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 11 months
[JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-4044:
---------------------------------
Assignee: Marek Goldmann (was: Jason Greene)
> Wildfly service will not start on fedora 20 - 64 bit
> ----------------------------------------------------
>
> Key: WFLY-4044
> URL: https://issues.jboss.org/browse/WFLY-4044
> Project: WildFly
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.1.0.Final
> Environment: Fedora 20 - updates installed
> Reporter: Karl Nicholas
> Assignee: Marek Goldmann
>
> standalone.sh starts wildfly ok but systemctl start service fails:
> [root@localhost system]# yum install wildfly
> Loaded plugins: langpacks, refresh-packagekit
> Package wildfly-8.1.0-3.fc20.noarch already installed and latest version
> Nothing to do
> [root@localhost system]# systemctl start wildfly
> [root@localhost system]# systemctl status wildfly
> wildfly.service - The WildFly Application Server
> Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled)
> Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago
> Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE)
> Main PID: 7658 (code=exited, status=1/FAILURE)
> Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server.
> Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE
> Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state.
> [root@localhost system]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 11 months