[JBoss JIRA] (WFLY-248) Loopback addresses in the range 127.0.0.2 - 127.255.255.255 should be supported
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-248?page=com.atlassian.jira.plugin.s... ]
Rostislav Svoboda reassigned WFLY-248:
--------------------------------------
Assignee: Rostislav Svoboda
> Loopback addresses in the range 127.0.0.2 - 127.255.255.255 should be supported
> -------------------------------------------------------------------------------
>
> Key: WFLY-248
> URL: https://issues.jboss.org/browse/WFLY-248
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Environment: Linux Fedora 13
> Reporter: Bela Ban
> Assignee: Rostislav Svoboda
> Fix For: 8.0.0.Beta1
>
>
> When starting JBoss like this: "standalone.sh -b 127.0.0.2 -c standalone-ha.xml", the startup fails because 127.0.0.2 cannot be resolved.
> However, a loopback address should be recognized even if it doesn't resolve to an interface. The code below works for example:
> {code}
> InetAddress addr=InetAddress.getByName("127.0.0.5");
> boolean is_loopback=addr.isLoopback(); // should be true
> {code}
> Loopback addresses are very useful for local testing, ie. starting of multiple JBoss instances on the same box.
--
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
12 years, 4 months
[JBoss JIRA] (JBVFS-188) TimedCachePolicy using unsynchronized Map by default
by Keiichi Sato (JIRA)
[ https://issues.jboss.org/browse/JBVFS-188?page=com.atlassian.jira.plugin.... ]
Keiichi Sato updated JBVFS-188:
-------------------------------
Description:
TimedCachePolicy should be created with synchronized Map by default. If TimedCachePolicy is created unsynchronized Map, ConcurrentModificationException occurs on TimedCachePolicy.getValidKeys() method.
{noformat}
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
at java.util.HashMap$EntryIterator.next(HashMap.java:851)
at java.util.HashMap$EntryIterator.next(HashMap.java:849)
at org.jboss.util.TimedCachePolicy.getValidKeys(TimedCachePolicy.java:364)
at org.jboss.virtual.plugins.cache.IterableTimedVFSCache.findContext(IterableTimedVFSCache.java:65)
at org.jboss.virtual.plugins.cache.CombinedVFSCache.findContext(CombinedVFSCache.java:116)
at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:148)
at org.jboss.virtual.VFS.getRoot(VFS.java:243)
at org.jboss.virtual.VFS.getRoot(VFS.java:313)
{noformat}
When JBoss starts with the default configuration, the following output in boot.log.
{noformat}
21:19:20,173 DEBUG [IterableTimedVFSCache] Creating timed cache policy, lifetime: null, threadSafe: true, resolution: null
{noformat}
This does not mean TimedCachePolicy is threadSafe
{code:title=http://anonsvn.jboss.org/repos/jbossas/projects/vfs/tags/2.2.0.SP1/src/main/java/org/jboss/virtual/plugins/cache/TimedVFSCache.java|borderStyle=solid}
protected TimedCachePolicy createCachePolicy()
-- snip --
log.debug("Creating timed cache policy, lifetime: " + defaultLifetime + ", threadSafe: " + threadSafe + ", resolution: " + resolution);
TimedCachePolicy tcp;
if (defaultLifetime == null)
tcp = new TimedCachePolicy();
else if (resolution != null)
tcp = new TimedCachePolicy(defaultLifetime, threadSafe, resolution);
else
tcp = new TimedCachePolicy(defaultLifetime);
-- snip --
{code}
If defaultLifetime and resolution are null, TimedCachePolicy is created using the default constructor. The default constructor is as the following.
{code:title=http://anonsvn.jboss.org/repos/common/common-core/tags/2.2.18.GA/src/main/java/org/jboss/util/TimedCachePolicy.java|borderStyle=solid}
public TimedCachePolicy()
{
this(30*60, false, 0);
}
{code}
The default constructor specifies threadSafe to false.
was:
TimedCachePolicy should be created with synchronized Map by default. If TimedCachePolicy is created unsynchronized Map, ConcurrentModificationException occurs on TimedCachePolicy.getValidKeys() method.
{noformat}
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
at java.util.HashMap$EntryIterator.next(HashMap.java:851)
at java.util.HashMap$EntryIterator.next(HashMap.java:849)
at org.jboss.util.TimedCachePolicy.getValidKeys(TimedCachePolicy.java:364)
at org.jboss.virtual.plugins.cache.IterableTimedVFSCache.findContext(IterableTimedVFSCache.java:65)
at org.jboss.virtual.plugins.cache.CombinedVFSCache.findContext(CombinedVFSCache.java:116)
at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:148)
at org.jboss.virtual.VFS.getRoot(VFS.java:243)
at org.jboss.virtual.VFS.getRoot(VFS.java:313)
{noformat}
When JBoss starts with the default configuration, the following output in boot.log.
{noformat}
21:19:20,173 DEBUG [IterableTimedVFSCache] Creating timed cache policy, lifetime: null, threadSafe: true, resolution: null
{noformat}
This does not mean TimedCachePolicy is threadSafe
{code:title=http://anonsvn.jboss.org/repos/jbossas/projects/vfs/tags/2.2.0.SP1/src/main/java/org/jboss/virtual/plugins/cache/TimedVFSCache.java|borderStyle=solid}
protected TimedCachePolicy createCachePolicy()
-- snip --
log.debug("Creating timed cache policy, lifetime: " + defaultLifetime + ", threadSafe: " + threadSafe + ", resolution: " + resolution);
TimedCachePolicy tcp;
if (defaultLifetime == null)
tcp = new TimedCachePolicy();
else if (resolution != null)
tcp = new TimedCachePolicy(defaultLifetime, threadSafe, resolution);
else
tcp = new TimedCachePolicy(defaultLifetime);
-- snip --
{code}
If defaultLifetime and resolution are null, TimedCachePolicy is created the default constructor. The default constructor is as the following.
{code:title=http://anonsvn.jboss.org/repos/common/common-core/tags/2.2.18.GA/src/main/java/org/jboss/util/TimedCachePolicy.java|borderStyle=solid}
public TimedCachePolicy()
{
this(30*60, false, 0);
}
{code}
The default constructor specifies threadsafe to false.
> TimedCachePolicy using unsynchronized Map by default
> ----------------------------------------------------
>
> Key: JBVFS-188
> URL: https://issues.jboss.org/browse/JBVFS-188
> Project: JBoss VFS
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Release
> Affects Versions: 2.2.0.SP1
> Reporter: Keiichi Sato
> Assignee: David Lloyd
>
> TimedCachePolicy should be created with synchronized Map by default. If TimedCachePolicy is created unsynchronized Map, ConcurrentModificationException occurs on TimedCachePolicy.getValidKeys() method.
> {noformat}
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
> at java.util.HashMap$EntryIterator.next(HashMap.java:851)
> at java.util.HashMap$EntryIterator.next(HashMap.java:849)
> at org.jboss.util.TimedCachePolicy.getValidKeys(TimedCachePolicy.java:364)
> at org.jboss.virtual.plugins.cache.IterableTimedVFSCache.findContext(IterableTimedVFSCache.java:65)
> at org.jboss.virtual.plugins.cache.CombinedVFSCache.findContext(CombinedVFSCache.java:116)
> at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:148)
> at org.jboss.virtual.VFS.getRoot(VFS.java:243)
> at org.jboss.virtual.VFS.getRoot(VFS.java:313)
> {noformat}
> When JBoss starts with the default configuration, the following output in boot.log.
> {noformat}
> 21:19:20,173 DEBUG [IterableTimedVFSCache] Creating timed cache policy, lifetime: null, threadSafe: true, resolution: null
> {noformat}
> This does not mean TimedCachePolicy is threadSafe
> {code:title=http://anonsvn.jboss.org/repos/jbossas/projects/vfs/tags/2.2.0.SP1/src/main/java/org/jboss/virtual/plugins/cache/TimedVFSCache.java|borderStyle=solid}
> protected TimedCachePolicy createCachePolicy()
> -- snip --
> log.debug("Creating timed cache policy, lifetime: " + defaultLifetime + ", threadSafe: " + threadSafe + ", resolution: " + resolution);
> TimedCachePolicy tcp;
> if (defaultLifetime == null)
> tcp = new TimedCachePolicy();
> else if (resolution != null)
> tcp = new TimedCachePolicy(defaultLifetime, threadSafe, resolution);
> else
> tcp = new TimedCachePolicy(defaultLifetime);
> -- snip --
> {code}
> If defaultLifetime and resolution are null, TimedCachePolicy is created using the default constructor. The default constructor is as the following.
> {code:title=http://anonsvn.jboss.org/repos/common/common-core/tags/2.2.18.GA/src/main/java/org/jboss/util/TimedCachePolicy.java|borderStyle=solid}
> public TimedCachePolicy()
> {
> this(30*60, false, 0);
> }
> {code}
> The default constructor specifies threadSafe to false.
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-221) Batch scripts should show some error message when we set JAVA_HOME to nonexisting folder
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-221?page=com.atlassian.jira.plugin.s... ]
Rostislav Svoboda resolved WFLY-221.
------------------------------------
Fix Version/s: 8.0.0.Alpha3
(was: 8.0.0.CR1)
Resolution: Done
> Batch scripts should show some error message when we set JAVA_HOME to nonexisting folder
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-221
> URL: https://issues.jboss.org/browse/WFLY-221
> Project: WildFly
> Issue Type: Enhancement
> Components: Scripts
> Reporter: Brian Stansberry
> Assignee: Rostislav Svoboda
> Fix For: 8.0.0.Alpha3
>
>
> steps to reproduce:
> ...
> {code}jboss-eap-6.0\bin>set JAVA_HOME=c:\dummy
> jboss-eap-6.0\bin>standalone.bat
> Calling "W:\tmp\pk\jboss-eap-6.0\bin\standalone.conf.bat"
> >{code}
> ...
> batch script will end on this line (standalone.bat)
> l:73 "%JAVA%" -client -version 2>&1 | findstr /I /C:"Client VM" > nul
> On linux we get at least error message:
> ./standalone.sh: line 178: /home/dummy/bin/java: No such file or directory
--
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
12 years, 4 months
[JBoss JIRA] (JBVFS-188) TimedCachePolicy using unsynchronized Map by default
by Keiichi Sato (JIRA)
Keiichi Sato created JBVFS-188:
----------------------------------
Summary: TimedCachePolicy using unsynchronized Map by default
Key: JBVFS-188
URL: https://issues.jboss.org/browse/JBVFS-188
Project: JBoss VFS
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Release
Affects Versions: 2.2.0.SP1
Reporter: Keiichi Sato
Assignee: David Lloyd
TimedCachePolicy should be created with synchronized Map by default. If TimedCachePolicy is created unsynchronized Map, ConcurrentModificationException occurs on TimedCachePolicy.getValidKeys() method.
{noformat}
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810)
at java.util.HashMap$EntryIterator.next(HashMap.java:851)
at java.util.HashMap$EntryIterator.next(HashMap.java:849)
at org.jboss.util.TimedCachePolicy.getValidKeys(TimedCachePolicy.java:364)
at org.jboss.virtual.plugins.cache.IterableTimedVFSCache.findContext(IterableTimedVFSCache.java:65)
at org.jboss.virtual.plugins.cache.CombinedVFSCache.findContext(CombinedVFSCache.java:116)
at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:148)
at org.jboss.virtual.VFS.getRoot(VFS.java:243)
at org.jboss.virtual.VFS.getRoot(VFS.java:313)
{noformat}
When JBoss starts with the default configuration, the following output in boot.log.
{noformat}
21:19:20,173 DEBUG [IterableTimedVFSCache] Creating timed cache policy, lifetime: null, threadSafe: true, resolution: null
{noformat}
This does not mean TimedCachePolicy is threadSafe
{code:title=http://anonsvn.jboss.org/repos/jbossas/projects/vfs/tags/2.2.0.SP1/src/main/java/org/jboss/virtual/plugins/cache/TimedVFSCache.java|borderStyle=solid}
protected TimedCachePolicy createCachePolicy()
-- snip --
log.debug("Creating timed cache policy, lifetime: " + defaultLifetime + ", threadSafe: " + threadSafe + ", resolution: " + resolution);
TimedCachePolicy tcp;
if (defaultLifetime == null)
tcp = new TimedCachePolicy();
else if (resolution != null)
tcp = new TimedCachePolicy(defaultLifetime, threadSafe, resolution);
else
tcp = new TimedCachePolicy(defaultLifetime);
-- snip --
{code}
If defaultLifetime and resolution are null, TimedCachePolicy is created the default constructor. The default constructor is as the following.
{code:title=http://anonsvn.jboss.org/repos/common/common-core/tags/2.2.18.GA/src/main/java/org/jboss/util/TimedCachePolicy.java|borderStyle=solid}
public TimedCachePolicy()
{
this(30*60, false, 0);
}
{code}
The default constructor specifies threadsafe to false.
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-1585) Cached web resources can become corrupt
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1585?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-1585.
----------------------------------
Fix Version/s: 8.0.0.Alpha3
Resolution: Done
> Cached web resources can become corrupt
> ---------------------------------------
>
> Key: WFLY-1585
> URL: https://issues.jboss.org/browse/WFLY-1585
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha2
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 8.0.0.Alpha3
>
>
> Due to a caching bug introduced just before the release it is possible for cached resources to become corrupt. This will occur after a resource has been loaded 5 times and the cache takes effect.
> This can be worked around by removing the <buffer-cache> element in standalone.xml
--
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
12 years, 4 months
[JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JASSIST-163?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on JASSIST-163:
-------------------------------------------------
Brett Meyer <brmeyer(a)redhat.com> made a comment on [bug 900690|https://bugzilla.redhat.com/show_bug.cgi?id=900690]
> RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
> ------------------------------------------------------------------------------------------------
>
> Key: JASSIST-163
> URL: https://issues.jboss.org/browse/JASSIST-163
> Project: Javassist
> Issue Type: Enhancement
> Affects Versions: 3.15.0-GA, 3.16.1-GA
> Environment: hibernate-core 3.6.10.Final
> Reporter: Nikita Tovstoles
> Assignee: Shigeru Chiba
> Fix For: 3.17.0-GA
>
> Attachments: Bean_$$_bulkaccess_0.txt, Bean_$$_bulkaccess_0_Two.txt, blocked-threads.png, BulkAccessorFactory.java.diff, BulkAccessorFactory.java.diff2, BulkAccessorFactory.patch, find2methods-hotspot.png, jassist-163-fix.patch, monitor-backtraces.png, monitor-backtraces.png, Product.java, Product_$$_javassist_0-post-patch.java, Product_$$_javassist_0.java, Tomcat-2012-03-28(2).zip
>
>
> We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
> every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
> ProxyFactory.createClass()).
> In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
> 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
> {code}
> synchronized (methods) {
> if (methods[index] == null) {
> methods[index + 1] = thisMethod == null ? null
> : findMethod(self, thisMethod, desc);
> methods[index] = findSuperMethod(self, superMethod, desc);
> }
> }
> {code}
> Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead of repeatedly executing the above synchronized statement. Instead, currently, it's being called every time (?) a proxied method is executed - see *Invocation Count* in this screen shot:
> https://issues.jboss.org/secure/attachment/12353025/monitor-backtraces.png
> Full [YourKit profile|http://yourkit.com] is [attached as a ZIP archive|^Tomcat-2012-03-28(2).zip]; key screen shots from the snapshot also attached separately
--
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
12 years, 4 months
