[JBoss JIRA] (WFLY-6669) Classloader leak trigerred by DOMNormalizer#abort in xercesImpl-2.11.0.SP4
by Mathieu Lachance (JIRA)
Mathieu Lachance created WFLY-6669:
--------------------------------------
Summary: Classloader leak trigerred by DOMNormalizer#abort in xercesImpl-2.11.0.SP4
Key: WFLY-6669
URL: https://issues.jboss.org/browse/WFLY-6669
Project: WildFly
Issue Type: Bug
Components: XML Frameworks
Affects Versions: 10.0.0.Final
Reporter: Mathieu Lachance
Assignee: Jason Greene
Priority: Critical
XERCESJ-1667 is a fix that was incorporated in the SVN trunk of the apache xerces project. Though it was never ported back in JBoss/Xerces github.
In our case, the classloader leak is triggered by the OpenSAML library which depends on Xerces, but lets be honest, this could have been anything.
{code}
15:08:11.554 [stderr] java.lang.RuntimeException.<init>(RuntimeException.java:51)
15:08:11.555 [stderr] at org.apache.xerces.dom.DOMNormalizer.<clinit>(DOMNormalizer.java:155)
15:08:11.555 [stderr] at org.apache.xml.serialize.DOMSerializerImpl.verify(DOMSerializerImpl.java:973)
15:08:11.555 [stderr] at org.apache.xml.serialize.DOMSerializerImpl.prepareForSerialization(DOMSerializerImpl.java:910)
15:08:11.555 [stderr] at org.apache.xml.serialize.DOMSerializerImpl.write(DOMSerializerImpl.java:692)
15:08:11.555 [stderr] at org.opensaml.xml.util.XMLHelper.writeNode(XMLHelper.java:892)
15:08:11.556 [stderr] at org.opensaml.xml.util.XMLHelper.writeNode(XMLHelper.java:872)
15:08:11.556 [stderr] at org.opensaml.xml.util.XMLHelper.nodeToString(XMLHelper.java:834)
15:08:11.556 [stderr] at org.opensaml.xml.XMLConfigurator.load(XMLConfigurator.java:159)
15:08:11.556 [stderr] at org.opensaml.xml.XMLConfigurator.load(XMLConfigurator.java:143)
15:08:11.556 [stderr] at org.opensaml.DefaultBootstrap.initializeXMLTooling(DefaultBootstrap.java:224)
15:08:11.556 [stderr] at org.opensaml.DefaultBootstrap.initializeXMLTooling(DefaultBootstrap.java:207)
15:08:11.557 [stderr] at org.opensaml.DefaultBootstrap.bootstrap(DefaultBootstrap.java:100)
15:08:11.557 [stderr] at org.opensaml.PaosBootstrap.bootstrap(PaosBootstrap.java:27)
15:08:11.557 [stderr] at org.springframework.security.saml.SAMLBootstrap.postProcessBeanFactory(SAMLBootstrap.java:42)
15:08:11.557 [stderr] at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:284)
15:08:11.557 [stderr] at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:181)
15:08:11.557 [stderr] at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:678)
15:08:11.557 [stderr] at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:520)
15:08:11.558 [stderr] at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:444)
15:08:11.558 [stderr] at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:326)
15:08:11.558 [stderr] at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:107)
15:08:11.558 [stderr] at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
15:08:11.558 [stderr] at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198)
15:08:11.558 [stderr] at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
15:08:11.558 [stderr] at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
15:08:11.559 [stderr] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
15:08:11.559 [stderr] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
15:08:11.559 [stderr] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
15:08:11.559 [stderr] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
15:08:11.559 [stderr] at java.lang.Thread.run(Thread.java:745)
15:08:11.559 [stderr] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
For more information see:
* https://issues.apache.org/jira/browse/XERCESJ-1667
* https://svn.apache.org/repos/asf/xerces/java/trunk/src/org/apache/xerces/...
* https://github.com/jboss/xerces/pull/13
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6665) clustering-web-infinispan: missing error handling when unmarshalling session
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6665?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6665:
------------------------------------
[~podlesakk] First of all - this is an exemplary bug report. Thank you for that.
Second, I'm going to ignore the issues with 9.0.x, as this branch is no longer actively developed.
Third, I'm not 100% convinced that WF10 should handle this specific scenario in the way you expect. Your reproducer attempts to demonstrate a failure reading the contents of a MarshalledValue containing an HttpSession's attributes. Consequently, I'm interpreting the failure triggered in your readObject(...) method as an application bug. In reality, the server would not have reached this point if the failure was due to something more serious, like a corrupted/truncated I/O stream, which would have thrown a generic IOException or some kind of RuntimeException or Error during the unmarshalling of the MarshalledValue itself. Thus, any failures triggered during the unmarshalling of the bytes of the MarshalledValue are due to an asymmetry in the application serialization/deserialization logic. So the question becomes, should the application server interpret buggy serialization logic silently, and instead create a new session? Or is propagating the failure to the client warranted? My sense is that the latter is the most appropriate solution - but this is purely subjective, as there is certainly nothing in the servlet spec that covers this scenario.
> clustering-web-infinispan: missing error handling when unmarshalling session
> ----------------------------------------------------------------------------
>
> Key: WFLY-6665
> URL: https://issues.jboss.org/browse/WFLY-6665
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Kamil Podlešák
> Assignee: Paul Ferraro
>
> When unmarshalling of session throws _unexpected_ exception, it is not handled correctly and is propagated to undertow worker, thus causing generic http 500 error to be shown to user. Problem is that each request tries to unmarshall session again and fails... making this session completely broken (for with no recovery until session cookie expires or is removed (ie browser closed).
> Some exceptions are _expected_ and handled correctly by removing session and continuing (usually, new session is created). They are catched in MarshalledValueMarshaller.read, wrapped by InvalidSerializedFormException and then handled in CoarseSessionAttributesFactory.findValue. Expected exceptions are these:
> * java.lang.ClassNotFoundException
> * java.io.InvalidClassException
> * java.io.InvalidObjectException
> This list is sufficient in *most* of the time, but sometimes even jboss-marshalling-river throws some RuntimeException (not to mention IOException).
> Sample stacktrace (there are several possible variants):
> {noformat}
> 14:26:14,366 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-1) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.IllegalArgumentException] while invoking method [public void org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.activated(org.infinispan.notifications.cachelistener.event.CacheEntryActivatedEvent)] on listener instance: org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager@25e2eac0
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:291)
> at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:21)
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1234)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1229)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1206)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryActivated(CacheNotifierImpl.java:522)
> at org.infinispan.interceptors.ActivationInterceptor.sendNotification(ActivationInterceptor.java:33)
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadInContext(CacheLoaderInterceptor.java:392)
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:362)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:183)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:137)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitDataReadCommand(EntryWrappingInterceptor.java:133)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:123)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:71)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:77)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:92)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:69)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:39)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:61)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:234)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:140)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:726)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:756)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:69)
> 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)
> Caused by: java.lang.IllegalArgumentException: always failing!
> at eu.lmc.experiment.FailingDeserialization2.readObject(FailingDeserialization2.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:149)
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:135)
> at org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:53)
> at org.jboss.marshalling.river.RiverObjectInputStream.readObjectOverride(RiverObjectInputStream.java:307)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:365)
> at java.util.HashMap.readObject(HashMap.java:1396)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.wildfly.clustering.marshalling.jboss.SimpleMarshalledValue.get(SimpleMarshalledValue.java:101)
> at org.wildfly.clustering.marshalling.jboss.SimpleMarshalledValue.get(SimpleMarshalledValue.java:44)
> at org.wildfly.clustering.marshalling.jboss.MarshalledValueMarshaller.read(MarshalledValueMarshaller.java:45)
> at org.wildfly.clustering.marshalling.jboss.MarshalledValueMarshaller.read(MarshalledValueMarshaller.java:32)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionAttributesFactory.findValue(CoarseSessionAttributesFactory.java:84)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionAttributesFactory.findValue(CoarseSessionAttributesFactory.java:48)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:63)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.lambda$activated$24(InfinispanSessionManager.java:300)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$$Lambda$129/153353148.run(Unknown Source)
> at org.wildfly.clustering.service.concurrent.StampedLockServiceExecutor.execute(StampedLockServiceExecutor.java:42)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.activated(InfinispanSessionManager.java:297)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> ... 62 more
> Caused by: an exception which occurred:
> in object of type eu.lmc.experiment.FailingDeserialization2
> in object of type java.util.HashMap
> {noformat}
> Note 1: application must be marked as "distributable" in web.xml or equivalent.
> Note 2: in 9.0.2, this bug is way more serious because handling of "expected" exceptions is completely broken and ends up in infinite recursion. So in addition to completely broken session, server logs is spammed by 40 megabytes of stacktraces per each request.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2073) RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functional
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2073?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2073:
--------------------------------
Thanks for the confirm.
> RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functional
> -----------------------------------------------------------------------------
>
> Key: JGRP-2073
> URL: https://issues.jboss.org/browse/JGRP-2073
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3, 3.4.3, 3.5, 3.6, 3.6.8, 3.6.9
> Environment: tested with windows7 64 bit; oracle java version 1.8.0_60 64bit
> Reporter: Roman Fischer
> Assignee: Bela Ban
> Fix For: 3.6.10, 4.0
>
>
> I have tested with the RelayDemo as the Description in the jgroups manual together with the udp.xml from the 3.6.9 jgroups Version.
> At the Moment if the bridge-cluster is aktiv, the system sent continuously null messages to all Members.
> if we replace pbcast.NAKACK2 with pbcast.NAKACK the demo is ok.
> So i have seen it is planned to remove NAKACK in the Future - i create this issue.
> Thanks for the nice software!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2073) RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functional
by Roman Fischer (JIRA)
[ https://issues.jboss.org/browse/JGRP-2073?page=com.atlassian.jira.plugin.... ]
Roman Fischer commented on JGRP-2073:
-------------------------------------
I can confirm with an self compiled 3.6.10-snapshot RelayDemo with pbcast.NAKACK2 in Stack is now functional.
Thanks!
> RELAY with pbcast.NAKACK2 instead of pbcast.NAKACK in Stack is not functional
> -----------------------------------------------------------------------------
>
> Key: JGRP-2073
> URL: https://issues.jboss.org/browse/JGRP-2073
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3, 3.4.3, 3.5, 3.6, 3.6.8, 3.6.9
> Environment: tested with windows7 64 bit; oracle java version 1.8.0_60 64bit
> Reporter: Roman Fischer
> Assignee: Bela Ban
> Fix For: 3.6.10, 4.0
>
>
> I have tested with the RelayDemo as the Description in the jgroups manual together with the udp.xml from the 3.6.9 jgroups Version.
> At the Moment if the bridge-cluster is aktiv, the system sent continuously null messages to all Members.
> if we replace pbcast.NAKACK2 with pbcast.NAKACK the demo is ok.
> So i have seen it is planned to remove NAKACK in the Future - i create this issue.
> Thanks for the nice software!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBASMP-82) Unable to build the workspace
by Megha Kesharwani (JIRA)
Megha Kesharwani created JBASMP-82:
--------------------------------------
Summary: Unable to build the workspace
Key: JBASMP-82
URL: https://issues.jboss.org/browse/JBASMP-82
Project: JBoss AS Maven Plugins
Issue Type: Bug
Components: build
Environment: Eclipse
Reporter: Megha Kesharwani
Assignee: James Perkins
Priority: Trivial
Attachments: .log
I am using eclipse Kepler with plugins JBOSS(wildfly-8.2.0.Final) and ClearCase, while building the workspace i am getting the following error "ENTRY org.eclipse.core.jobs 4 2 2016-06-02 11:07:19.724
!MESSAGE An internal error occurred during: "Building workspace".
!STACK 0
java.lang.StackOverflowError"
Attached logs.
We have tried the following solutions:
1. We tried increasing the memory size in eclipse.ini file as below but it doesn't seems to work:
--launcher.XXMaxPermSize
1024M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
1024m
--launcher.appendVmargs
-vm "C:\Program Files\Java\jre7"
-Dosgi.requiredJavaVersion=1.7
-Xms2048m
-Xmx2048m
2. When the RAM was checked using task manager eclipse was taking 365MB of memory.
Please guide us some other workaround to resolve the issue.
thanks,
Megha
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1563) Failed CLI batch command with "deploy --force" for replace deployment
by ted won (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1563?page=com.atlassian.jira.plugi... ]
ted won closed WFCORE-1563.
---------------------------
> Failed CLI batch command with "deploy --force" for replace deployment
> ---------------------------------------------------------------------
>
> Key: WFCORE-1563
> URL: https://issues.jboss.org/browse/WFCORE-1563
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.Final, 3.0.0.Alpha1
> Reporter: ted won
> Assignee: ted won
> Priority: Minor
> Labels: cli, jboss
> Fix For: 2.2.0.CR2, 3.0.0.Alpha2
>
> Attachments: jboss-ejb-in-ear.ear
>
>
> Using 'deploy --force' command on CLI batch mode fails and returns an error message: "Request is missing the address part."
> {code:title=Command}
> jboss-cli.sh --connect --controller=127.0.0.1:9999 --user=admin --password=xxx --file="deploy.cli"
> {code}
> {code:title=deploy.cli}
> batch
> deploy --force ./jboss-ejb-in-ear.ear
> run-batch
> {code}
> {panel:title=Full Error message}
> Failed to handle 'run-batch': org.jboss.as.cli.CommandFormatException: Request is missing the address part.: Request is missing the address part.
> or
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): Request is missing the address part.
> {panel}
> {panel:title=Expected message}
> The batch executed successfully
> {panel}
> However, it's working in "WildFly 10 CLI interactive mode" and "JBoss AS 7 CLI batch" without error.
> There is no adding "address" key in buildDeploymentReplace() of DeployHandler like below.
> Even though on CLI batch mode it validates existence of "address" key in request with Util.validateRequest(), when 'run-batch' command execute in org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle()
> -------------------------------------------------------------------------------------------
> * First deploy: add by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentAdd()
> {code}
> {
> "operation" => "add",
> "address" => {"deployment" => "jboss-ejb-in-ear.ear"},
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * After deploy: replace by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * Expected by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "address" => [],
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6441) naming context is not setup when starting the persistence unit
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6441?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6441:
-----------------------------------------------
Chao Wang <chaowan(a)redhat.com> changed the Status of [bug 1320132|https://bugzilla.redhat.com/show_bug.cgi?id=1320132] from ASSIGNED to POST
> naming context is not setup when starting the persistence unit
> --------------------------------------------------------------
>
> Key: WFLY-6441
> URL: https://issues.jboss.org/browse/WFLY-6441
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Affects Versions: JBoss AS7 7.1.1.Final, JBoss AS7 7.2.0.Final, 9.0.2.Final, 10.0.0.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 10.1.0.Final
>
>
> ookup of env-entry throws NameNotFoundException during persistence unit startup
> Version-Release number of selected component (if applicable):
> How reproducible:
> always
> Steps to Reproduce:
> 1. add env-entry in application.xml
> 2. try to lookup during persistent unit startup, e.g.
> public class MyType implements UserType {
> ...
> @Override
> public int[] sqlTypes() {
> try {
> Object ctx = new InitialContext().lookup("java:app/env");
> log.info("java:app/env from JPA = " + ctx);
> } catch (Exception e) {
> log.error("unable to get java:app/env from JPA", e);
> }
> return new int[] { Types.VARCHAR };
> }
> Actual results:
> NameNotFoundException
> Expected results:
> value of env-entry is available
> Additional info:
> On 21.03.2016 23:47, Stuart Douglas wrote:
> > This should fix it (I think): https://github.com/stuartwdouglas/wildfly/tree/jpa-java-namespace
> >
> > Stuart
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6441) naming context is not setup when starting the persistence unit
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6441?page=com.atlassian.jira.plugin.... ]
Scott Marlow closed WFLY-6441.
------------------------------
Resolution: Done
> naming context is not setup when starting the persistence unit
> --------------------------------------------------------------
>
> Key: WFLY-6441
> URL: https://issues.jboss.org/browse/WFLY-6441
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Affects Versions: JBoss AS7 7.1.1.Final, JBoss AS7 7.2.0.Final, 9.0.2.Final, 10.0.0.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 10.1.0.Final
>
>
> ookup of env-entry throws NameNotFoundException during persistence unit startup
> Version-Release number of selected component (if applicable):
> How reproducible:
> always
> Steps to Reproduce:
> 1. add env-entry in application.xml
> 2. try to lookup during persistent unit startup, e.g.
> public class MyType implements UserType {
> ...
> @Override
> public int[] sqlTypes() {
> try {
> Object ctx = new InitialContext().lookup("java:app/env");
> log.info("java:app/env from JPA = " + ctx);
> } catch (Exception e) {
> log.error("unable to get java:app/env from JPA", e);
> }
> return new int[] { Types.VARCHAR };
> }
> Actual results:
> NameNotFoundException
> Expected results:
> value of env-entry is available
> Additional info:
> On 21.03.2016 23:47, Stuart Douglas wrote:
> > This should fix it (I think): https://github.com/stuartwdouglas/wildfly/tree/jpa-java-namespace
> >
> > Stuart
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months