[JBoss JIRA] (WFLY-1428) Extra resource root added to WARs
by David Lloyd (JIRA)
David Lloyd created WFLY-1428:
---------------------------------
Summary: Extra resource root added to WARs
Key: WFLY-1428
URL: https://issues.jboss.org/browse/WFLY-1428
Project: WildFly
Issue Type: Bug
Components: Web (JBoss Web), Web (Undertow)
Reporter: David Lloyd
Assignee: Remy Maucherat
Fix For: 8.0.0.Alpha2
When the class path for WAR deployments is being assembled, it appears that the WAR's root is being added as a resource root. This seems to be counter to spec; by default this should not be done. Now that we have the ability to iterate class loader resources, this causes unusual things to be listed.
Some users may desire this non-standard behavior though. So, we should have a way (preferably simpler than {{jboss-deployment-structure.xml}}) to enable it; however in this case, the following paths *must* be excluded:
* {{WEB-INF/lib}}
* {{WEB-INF/classes}}
* Any additional configured library or source directories
* Any other nested, mounted JAR files
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (AS7-4594) do not resolve socket-bindings used by messaging
by SBS JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-4594?page=com.atlassian.jira.plugin.s... ]
SBS JIRA Integration updated AS7-4594:
--------------------------------------
Forum Reference: https://community.jboss.org/message/738099#738099
> do not resolve socket-bindings used by messaging
> ------------------------------------------------
>
> Key: AS7-4594
> URL: https://issues.jboss.org/browse/AS7-4594
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 7.1.2.Final (EAP)
>
>
> HornetQ remote acceptors and connectors can be configured using socket-bindings.
> The current code tries to resolve the socket address to get its host name that is serialized into JMS connection factories.
> The client will then lookup a CF with the hostname to connect to AS7's HornetQ server. If the clients can not look up the host name, the connection will fail.
> The messaging subsystem should not try to resolve the address but serialize it "as is" so that the client will use it directly.
> The only exception is that *by default*, we use the loopback address for RemoteConnectionFactory. We need to check whether the socket address is a loopback and resolve it before serializing it for the client use.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JGRP-1638) Memory leak
by Bela Ban (JIRA)
Bela Ban created JGRP-1638:
------------------------------
Summary: Memory leak
Key: JGRP-1638
URL: https://issues.jboss.org/browse/JGRP-1638
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Critical
Fix For: 3.4
Running MPerf with conf/fast-local.xml (2 members on the same host, 20 million messages each) creates a memory leak in 3.4.x.
This runs perfectly 3.2.8.Final, so it must be something that was introduced in 3.3.x (3.4.x at this time has almost no diffs to 3.3.0.Final).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (WFLY-1406) Hibernate cannot process package-info.java any more
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1406?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-1406:
------------------------------------------
I just tried to replace the 4 Hibernate JARs in WildFly by Hibernate's new 4.3.0.Beta3, and the issue still exists.
> Hibernate cannot process package-info.java any more
> ---------------------------------------------------
>
> Key: WFLY-1406
> URL: https://issues.jboss.org/browse/WFLY-1406
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Scott Marlow
> Attachments: server.log, tar.log
>
>
> I tried the snapshot which contains Hibernate 4.3.0.Beta2. However, package-info.java files are causing problems. For instance, the package de.shop.artikelverwaltung.domain has a package-info.java which causes a NoClassDefFoundError:
> "IllegalName: de/shop/artikelverwaltung/domain.package-info". Please see the stacktrace below.
> Here is an example for package-info.java which was working with WildFly 8.0.0.Alpha1:
> @XmlAccessorType(FIELD)
> @Vetoed
> package de.shop.artikelverwaltung.domain;
> import static javax.xml.bind.annotation.XmlAccessType.FIELD;
> import javax.enterprise.inject.Vetoed;
> import javax.xml.bind.annotation.XmlAccessorType;
> The stacktrace:
> ...
> 09:29:53,880 WARN [org.jboss.modules] Failed to define class de/shop/artikelverwaltung/domain.package-info in Module "deployment.shop2.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link de/shop/artikelverwaltung/domain/package-info (Module "deployment.shop2.war:main" from Service Module Loader)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:427) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:260) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:75) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.Module.loadModuleClass(Module.java:526) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader.findClass(ClassLoaderServiceImpl.java:218) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356) [rt.jar:1.7.0_21]
> at org.hibernate.annotations.common.util.ReflectHelper.classForName(ReflectHelper.java:160) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.packageForName(JavaReflectionManager.java:121) [hibernate-commons-annotations-4.0.2.Final.jar:4.0.2.Final]
> at org.hibernate.cfg.AnnotationBinder.bindPackage(AnnotationBinder.java:262) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.cfg.Configuration.addPackage(Configuration.java:792) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildHibernateConfiguration(EntityManagerFactoryBuilderImpl.java:1174) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:839) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368) [hibernate-core-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:142) [hibernate-entitymanager-4.3.0.Beta2.jar:4.3.0.Beta2]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.createContainerEntityManagerFactory(PersistenceUnitServiceImpl.java:213) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl.access$800(PersistenceUnitServiceImpl.java:58) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:107) [wildfly-jpa-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.lang.NoClassDefFoundError: IllegalName: de/shop/artikelverwaltung/domain.package-info
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:646) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:785) [rt.jar:1.7.0_21]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:344) [jboss-modules.jar:1.2.0.Final]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:422) [jboss-modules.jar:1.2.0.Final]
> ... 28 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JGRP-1037) Ergonomics: size thread pools dynamically
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1037?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1037:
--------------------------------
As a first stept, we're adding stats to the transport on how long it takes on average to start processing a message (or batch) [avg dead time] and how long it takes for a message to be processed, from the time the pool starts execution until the message has been processed [avg processing time]
> Ergonomics: size thread pools dynamically
> -----------------------------------------
>
> Key: JGRP-1037
> URL: https://issues.jboss.org/browse/JGRP-1037
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> Ergonomics are a step towards less configuration and more dynamic setting of values. Example: a thread pool's min and max sizes can be dynamically changed, based on observations. When we have a min size of 10, but the thread pool is always 75, then we should set the min size to 75 and possibly change the idle time too.
> This is just a first step towards ergonomics and needs to be expanded on in 3.x releases
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JGRP-1037) Ergonomics: size thread pools dynamically
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1037?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1037:
--------------------------------
OK, so for the regular pool, we could use the following strategy to set the max thread pool size:
* We know the cluster size
* If we received a message from *every member at the same time*, then we'd need N threads to process those messages
* Any additional messages received from member P would get added to the table for P and then the thread would return immediately, so this is quick
* To be able to take incoming messages and place them into that table *when all threads are busy*, we should add a buffer of 1-2 threads
* So the formula for the max thread pool size of the regular pool could be CLUSTER-SIZE + 2 (to be investigated)
> Ergonomics: size thread pools dynamically
> -----------------------------------------
>
> Key: JGRP-1037
> URL: https://issues.jboss.org/browse/JGRP-1037
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> Ergonomics are a step towards less configuration and more dynamic setting of values. Example: a thread pool's min and max sizes can be dynamically changed, based on observations. When we have a min size of 10, but the thread pool is always 75, then we should set the min size to 75 and possibly change the idle time too.
> This is just a first step towards ergonomics and needs to be expanded on in 3.x releases
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JGRP-1037) Ergonomics: size thread pools dynamically
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1037?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1037:
--------------------------------
Not so sure automatically adjusting the thread pool sizes makes sense:
* Even if we compute the average number of messages to be serviced by the pool, setting a large max size for the OOB pool should be enough, as the pool will increase the number of threads (the OOB has no queue by default) automatically
* For the OOB pool, if we set the max threads too high, we'd get too many threads, leading to increased context switching and contention. We'd rather lose a few requests, as this will throttle the sender because it won't get credits sent back by the receivers quickly
* For the regular pool, we have to deliver messages from a given sender P in the order in which P sent them, so setting the max thread pool size to be greater than the average number of messages in the system would be wrong, as we cannot process all regular messages right away. For example, if we have 5 messages from P, then we only need 1 thread to deliver those messages. If we had a message from P, one from Q and one from R, we'd need 3 threads. So the best way to compute the max thread pool size for regular messages is to simply set it to the current cluster size, e.g. 10 nodes == max-size of 10 (plus perhaps 1-2 spare threads). However, we also need to think about whether the queue created by default for the regular thread pool should be removed.
> Ergonomics: size thread pools dynamically
> -----------------------------------------
>
> Key: JGRP-1037
> URL: https://issues.jboss.org/browse/JGRP-1037
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> Ergonomics are a step towards less configuration and more dynamic setting of values. Example: a thread pool's min and max sizes can be dynamically changed, based on observations. When we have a min size of 10, but the thread pool is always 75, then we should set the min size to 75 and possibly change the idle time too.
> This is just a first step towards ergonomics and needs to be expanded on in 3.x releases
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month