[JBoss JIRA] Created: (JGRP-535) NAKACK: release lock when message is delivered
by Bela Ban (JIRA)
NAKACK: release lock when message is delivered
----------------------------------------------
Key: JGRP-535
URL: http://jira.jboss.com/jira/browse/JGRP-535
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6
When NAKACK receives a message from C, it gets the NakReceiverWindow for C and acquires a lock on C, and then passes up the message. When the call returns, the lock is received (it is actually currently a synchronized(win) statement).
The reason is that this is needed to deliver all messages from C in the order in which they were sent.
The issue is that, while a message from C is delivered, all other threads are blocked on the lock for C's NakReceiverWindow. Especially the case when an up() method calls down() before returning, and down() blocks, this increases the duration during which the lock is kept. Example:
- Message from C acquires a lock on C's NakReceiverWindow
- Message is passed up
- The application gets the receive() callback
- *Inside* the receive(), the application calls Channel.send() which results in a down()
- Only when the down() placed the message on the network and returned will the up() method unwind its stack and return
--> Result: we kept a lock on C's NRW for much longer than we needed to. The lock should be kept until C's message has been *DELIVERED*, but not until the down() method returns !
--> If FC.down() blocks for credits, this makes it even worse !
SOLUTION:
- Investigate associating the lock acquired in NAKACK for C's NakReceiverWindow with the thread local. When the message is delivered (semantics ?), release the lock, this is sooner than when the up() method returns in NAKACK.
- This could also be done for example in STABLE.handleRegularMessage(), where we send the message up first, the release the lock and *only then* multicast the STABLE message
Investigate UNICAST as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 8 months
[JBoss JIRA] Created: (JBMICROCONT-155) java.io.IOException: No context factory for vfsfile
by Scott M Stark (JIRA)
java.io.IOException: No context factory for vfsfile
---------------------------------------------------
Key: JBMICROCONT-155
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-155
Project: JBoss MicroContainer
Issue Type: Bug
Components: VFS
Affects Versions: JBossMC_2_0_0 Beta3
Reporter: Scott M Stark
Assigned To: Scott M Stark
Fix For: JBossMC_2_0_0_CR1
The following org.jboss.test.virtual.test.FileVFSUnitTestCase:
/**
* Test that one can go from a file uri to VirtualFile and obtain the
* same VirtualFile using VirtualFile vfsfile uri
* @throws Exception
*/
public void testVFSFileURIFactory()
throws Exception
{
URL rootURL = getClass().getProtectionDomain().getCodeSource().getLocation();
VFS rootVFS0 = VFS.getVFS(rootURL.toURI());
VirtualFile root0 = rootVFS0.getRoot();
VFS rootVFS1 = VFS.getVFS(root0.toURI());
VirtualFile root1 = rootVFS1.getRoot();
assertEquals(root0, root1);
}
fails with:
java.io.IOException: No context factory for vfsfile:/home/svn/JBossMC/vfs/target/test-classes/
at org.jboss.virtual.VFS.getVFS(VFS.java:83)
at org.jboss.test.virtual.test.FileVFSUnitTestCase.testVFSFileURIFactory(FileVFSUnitTestCase.java:104)
The VFSContextFactory uri mappings need to be updated to include the vfs* forms of the known handlers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months
[JBoss JIRA] Created: (JBMICROCONT-205) Accessing content of vfsfile url fails
by Scott M Stark (JIRA)
Accessing content of vfsfile url fails
--------------------------------------
Key: JBMICROCONT-205
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-205
Project: JBoss MicroContainer
Issue Type: Bug
Components: VFS
Reporter: Scott M Stark
Fix For: JBossMC-2.0.0.Beta4
When trying to create a ManagedProperty for a URL type with a vfsfile: url value, the content fails to be obtained:
Caused by: java.net.UnknownServiceException: no content-type
at java.net.URLConnection.getContentHandler(URLConnection.java:1167)
at java.net.URLConnection.getContent(URLConnection.java:683)
at java.net.URL.getContent(URL.java:1021)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:55)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:108)
at org.jboss.beans.info.plugins.AbstractPropertyInfo.get(AbstractPropertyInfo.java:172)
at org.jboss.beans.info.plugins.AbstractBeanInfo.getProperty(AbstractBeanInfo.java:238)
at org.jboss.metatype.plugins.values.DefaultMetaValueFactory.createCompositeValue(DefaultMetaValueFactory.java:371)
... 23 more
VirtualFileURLConnection should be overriding the getContent method to return the VirtualFile I suppose.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 9 months