trac.tracnav 256 TracNav cannot handle non-ASCII text in r3085 or later trac.tracnav defect major moschny closed 2006-04-13T09:49:46+02:00 2006-04-14T11:39:11+02:00 "In changes in r3085, it is changed to use cStringIO.
By this change, we cannot use japanese TOC text.
I made workaround for this by simply reverting use of cStringIO.
{{{
#!diff
Index: tracnav.py
===================================================================
--- tracnav.py (revision 3091)
+++ tracnav.py (working copy)
@@ -64,10 +64,7 @@
from trac.web.chrome import ITemplateProvider, add_stylesheet
from trac.wiki.model import WikiPage
from trac.wiki.formatter import Formatter, OneLinerFormatter
-try:
- from cStringIO import StringIO
-except ImportError:
- from StringIO import StringIO
+from StringIO import StringIO
TRACNAVHOME = ""http://svn.ipd.uka.de/trac/javaparty/wiki/TracNav""
}}}
" gotoh@…
trac.tracnav 298 Layout problem IE7 trac.tracnav defect minor moschny closed 2009-04-05T01:46:39+02:00 2012-12-04T10:08:25+01:00 There is a minor layout problem in IE7 where 'Edit' appears overlayed on the first heading making it hard to read. anonymous
trac.tracnav 266 """TracNav menu"" is always the main header" trac.tracnav defect minor moschny closed 2006-11-27T09:42:33+01:00 2007-03-27T09:19:58+02:00 "Hi,
it seems that after upgrading trac to 0.11dev my TracNav looks weird. I have the default header ""TracNav menu"" beeing displayed all the time, even if i define another heading, which is beeing ignored.
" anonymous
trac.tracnav 261 "TracNav cause ""pre"" ({{{}}} texts to display wrong/strange" trac.tracnav defect minor moschny closed 2006-07-28T10:59:08+02:00 2012-12-03T23:13:02+01:00 "long texts display like
{{{
asdf asdf asdf asdf asdf asdf asd fasd fasd fas dfas dfasd fasd fasd fasd fas dfasd fasd fasdf asdf asdf asdf asdf asdf asdf asdf asdf asdf
}}}
get broken with tracnav:
* iexplore: it is broken if the TOC is on the side of it
* firefox: the width of all ""pre"" belob the TOC is also adjusted to the ""pre"" left to the TOC, even if below there is more room for them." ThurnerRupert
trac.tracnav 257 TracNav: Highlighting hides 'edit' link on IE trac.tracnav defect minor moschny closed 2006-05-01T06:01:02+02:00 2012-12-04T10:09:23+01:00 "The latest TracNav plugin (TracNav-3.92pre3) doesn't work for IE.
Specifically, something about the CSS for the 'edit' link in the TracNav panel cause the entire content to disappear. I will attach a screenshot demonstrating the problem." leedm777@…
trac.tracnav 246 TracNav trac.tracnav 1.00 defect minor hauma closed 2005-07-04T17:59:09+02:00 2005-10-27T15:21:38+02:00 "I've tried to use your TracNav.2 macro within newest Trac (0.9.pre)
and found problem that collapsed menu branches are not expanded
on click.
{{{
...snip...
* [wiki:Subsystem/StatGate Overview]
* [wiki:Subsystem/StatGate/Proto Proto]
* [wiki:Subsystem/StatGate/Server Server]
* [wiki:Subsystem/StatGate/Clients Clients]
...snip...
}}}" tiger@…
trac.tracnav 304 Option to disable `JPNav` trac.tracnav enhancement normal moschny closed 2010-02-12T20:40:10+01:00 2010-10-11T01:17:09+02:00 Adding `JPNav` as a synonym for `TracNav` causes both entries to be listed on the WikiMacros page. It would be nice to have an option to disable `JPNav` as a macro name. ryano@…
trac.tracnav 299 Problem with python 2.3 trac.tracnav defect normal moschny closed 2009-11-01T23:32:25+01:00 2011-09-08T03:23:01+02:00 "Hi there,
I had to fix this in order to get it working on python 2.3
In Invocation.__init you are using string.partition which is not available, so I rewrote it like this:
{{{
#!python
# Python 2.3 compatibility - String.partition is 2.5
def split_on_equals(string):
splitted = string.split(""="")
if 1 == len(splitted):
splitted += [""""]
return splitted
class Invocation(object):
def __init__(self, formatter, args):
# shortcuts
self.env = formatter.env
self.req = formatter.req
self.ctx = formatter.context
# needed several times
self.preview = self.req.args.get('preview', '')
self.curpage = self.req.args.get('page', 'WikiStart')
self.modify = self.req.perm.has_permission('WIKI_MODIFY')
# parse arguments
self.names = []
self.collapse = True
self.reorder = True
self.allowed_macros = 'Image'
if args:
for arg, values in map(split_on_equals, args.split('|')):
arg = arg.strip()
if arg == 'nocollapse':
self.collapse = False
elif arg == 'noedit':
self.modify = False
elif arg == 'noreorder':
self.reorder = False
elif arg == 'allowed_macros':
self.allowed_macros = map(lambda s: s.strip(), values.split(','))
else:
self.names.append(arg)
}}}" anonymous
trac.tracnav 296 'unicode' object has no attribute 'partition' trac.tracnav tracnav-devel defect normal moschny closed 2008-11-08T22:00:17+01:00 2008-11-09T13:48:17+01:00 "Hi,
I upgraded from trac 0.10 to 0.11.1
Upgrading TracNav to 4.1 didn't work. I get
Error: Macro TracNav(TracNav/Main) failed
'unicode' object has no attribute 'partition'
thanks for any hints resolving this.
cheers,
Hanspeter" hkunz@…
trac.tracnav 295 Other Macros inside TOC Page are not rendered trac.tracnav defect normal moschny closed 2008-11-05T09:38:01+01:00 2008-11-05T21:39:25+01:00 "I like your Plugin, very nice :)
But I want to add the ChildNav Plugin inside the TracNav TOC Page.
http://trac-hacks.org/wiki/ChildNavPlugin
{{{
[[ChildNav(...)]]
}}}
At the moment that's not working. Could you please implement that other macros are renderd :)
" trachacks@…
trac.tracnav 294 TracNav not found when installed in python2.4/site-packages directory trac.tracnav tracnav-devel defect normal moschny closed 2008-09-29T21:08:57+02:00 2008-09-30T19:10:44+02:00 "I built my own egg for trac 0.11 and python 2.4 (centos5).
When I installed the egg in the global location it wasn't found.
When I installed it in the trac/plugins directory it was found.
Shouldn't it be also found in the global location?
" ejs@…
trac.tracnav 292 Error: Macro JPNav(foobar) failed after update from trac 0.11dev to trac 0.12dev trac.tracnav tracnav-devel defect normal moschny closed 2008-07-11T21:43:34+02:00 2008-08-08T13:06:59+02:00 "After updating trac I got this error
{{{
Error: Macro JPNav(migration/Description for Migration) failed
_make_link() takes exactly 5 arguments (6 given)
}}}
I'm using tracnav 4.0pre7
" didley@…
trac.tracnav 290 Installing tracnav on trac-0.11-trunk gives upexpected html page trac.tracnav defect normal hauma closed 2008-03-20T22:38:44+01:00 2008-03-20T22:59:20+01:00 "{{{
# easy_install --prefix /opt/csw/testing http://svn.ipd.uka.de/repos/javaparty/JP/trac/plugins/tracnav-0.11/
Downloading http://svn.ipd.uka.de/repos/javaparty/JP/trac/plugins/tracnav-0.11/
error: Unexpected HTML page found at http://svn.ipd.uka.de/repos/javaparty/JP/trac/plugins/tracnav-0.11/
}}}" anonymous
trac.tracnav 289 "tracnav 4.0pre ""unexpected html page""" trac.tracnav tracnav-devel defect normal moschny closed 2008-01-21T23:29:05+01:00 2008-01-21T23:45:32+01:00 "{{{
# easy_install http://svn.ipd.uka.de/repos/javaparty/JP/trac/plugins/tracnav-0.11/ Downloading http://svn.ipd.uka.de/repos/javaparty/JP/trac/plugins/tracnav-0.11/
error: Unexpected HTML page found at http://svn.ipd.uka.de/repos/javaparty/JP/trac/plugins/tracnav-0.11/
}}}" anonymous
trac.tracnav 288 __init__() takes exactly 3 arguments (2 given) trac.tracnav defect normal moschny closed 2008-01-01T11:40:26+01:00 2008-01-01T20:47:18+01:00 "I'm using Trac 0.11dev. TracNav works but since I have changed from one Trac revision to revision 6371 it works not. it comes up the message[[BR]]
Error: Macro TracNav(Description for Migration) failed
__init__() takes exactly 3 arguments (2 given)
" didley@…
trac.tracnav 284 TracNav Causes Invalid XHTML To Be Generated trac.tracnav defect normal moschny closed 2007-09-18T11:06:31+02:00 2008-09-29T16:57:11+02:00 "The use of the TracNav macro anywhere on a page causes invalid XHTML code to be generated. This is because code to the following effect is produced:
{{{
to be inside of a
." freddie@…
trac.tracnav 281 Allow the edit link to be disabled trac.tracnav tracnav-3.92 enhancement normal moschny closed 2007-04-25T00:56:36+02:00 2008-01-06T16:32:46+01:00 "When dealing with non technical users the edit link can tend to confuse them.
Especially if the Trac site is mainly for showing information - and not necessarily expected to have a lot of user edits.
I made a quick change to the code adding a 'noeditlink' argument in a similar way to `nocollapse` which would allow disabling of the edit link.
Technical users can still edit the page - by either re-saving without that parameter - or by looking at the link text in the Plain text and copy and pasting into the address box.
Please find the diff attached. (against 3.92)" anonymous
trac.tracnav 280 How to modifyTracNav position and height. trac.tracnav tracnav-devel enhancement normal moschny closed 2007-03-02T15:33:38+01:00 2012-12-03T23:04:59+01:00 "I've tried to modify trac nav, in order to have the full size of the page.
But the ""height: 100%"" does not work.
any experience with this?
(btw: moving it to the left works fine with ""float: left;"")
{{{
#!css
.wiki-toc.trac-nav {
background-color: #f7f7f0;
float: right;
width: 160px;
margin: 0 .5em 0 0;
padding-top: 0.5em;
padding-right: 0pt;
padding-bottom: 0.2em;
padding-left: 0pt;
height: 100%;
}
}}}" ilias@…
trac.tracnav 277 "Provide a ""noreorder"" argument" trac.tracnav enhancement normal moschny closed 2007-02-27T08:32:33+01:00 2008-01-07T20:43:50+01:00 "from TracNav: ""Since r3088, TracNav knows the nocollapse argument, which prevents the TOC from being sorted or collapsed.""
If would be of benefit to have a separate ""noreorder"" argument.
This way a user can '''only''' disable the menu from beeing reordered, thus a clicked section is '''not''' move at the top of the menu.
" ilias@…
trac.tracnav 276 Display menu on all the wiki pages trac.tracnav tracnav-3.92 enhancement normal moschny closed 2007-02-23T15:27:52+01:00 2007-03-02T01:49:13+01:00 Is there a way to include TracNav on all the wiki pages? anonymous
trac.tracnav 272 tracnav does not work under python 0.5? trac.tracnav defect normal moschny closed 2007-01-25T11:09:25+01:00 2007-01-25T15:58:04+01:00 "After upgrading, we see:
Error: Macro TracNav(None) failed
env" anonymous
trac.tracnav 270 TracNav for 0.10 installed but thows an error trac.tracnav defect normal moschny closed 2007-01-17T11:07:46+01:00 2007-01-17T12:55:50+01:00 "I'm running Trac 0.10 on debian etch, and installed the TracNav Plugin.
It appears on the WikiMacros overview page, copmiled with no problems.
So I added a ""Nav"" Page w.g. /wiki/TracNav/Test
but when adding the {{{[[TracNav(TracNav/Test)]]}}} on any page I get:
{{{
Error: Macro TracNav(TracNav/Test) failed
'Request' object has no attribute 'env'
}}}
=== LogFile ===
{{{
2007-01-17 10:03:47,152 Trac[__init__] ERROR: Macro TracNav(TracNav/Test) failed
Traceback (most recent call last):
File ""/var/lib/python-support/python2.4/trac/wiki/formatter.py"", line 439, in
_macro_formatter
return macro.process(self.req, args, True)
File ""/var/lib/python-support/python2.4/trac/wiki/formatter.py"", line 112, in
process
text = self.processor(req, text)
File ""/var/lib/python-support/python2.4/trac/wiki/formatter.py"", line 100, in
_macro_processor
return self.macro_provider.render_macro(req, self.name, text)
File ""build/bdist.linux-i686/egg/tracnav/tracnav.py"", line 303, in render_macr
o
File ""build/bdist.linux-i686/egg/tracnav/tracnav.py"", line 115, in __init__
AttributeError: 'Request' object has no attribute 'env'
}}}" jc@…
trac.tracnav 269 TracNav needs trac to be in the python path when installation trac.tracnav defect normal moschny closed 2007-01-11T12:16:31+01:00 2007-01-11T14:14:38+01:00 "TracNav setup.py in line 4 imports tracnav.py only to have the version information:
{{{
from tracnav.tracnav import __version__ as version
}}}
which in turn imports several trac components:
{{{
from trac.core import Component, implements
...
}}}
Therefore TravNav can only be installed if Trac is already installed, and PYTHONPATH is appropriately set. One consequence is that it is not possible to do a batch installation, where Trac and TracNav is installed in one run and PYTHONPATH is set later." robi@…
trac.tracnav 268 Error: Macro TracNav(Menu) failed 'Formatter' object has no attribute 'args' trac.tracnav defect normal moschny closed 2007-01-05T14:29:10+01:00 2007-01-08T12:02:33+01:00 "Using Trac trunk 0.11dev (rev 4507), I get the following error:
Error: Macro TracNav(Menu) failed 'Formatter' object has no attribute 'args'
It seems like trac/wiki/formatter.py has changed functionality?" Gunnar Johansson
trac.tracnav 267 'Formatter' object has no attribute 'args' trac.tracnav defect normal moschny closed 2006-12-27T16:22:58+01:00 2007-01-22T17:57:15+01:00 "If i include TracNav to my Trac i get this error:
{{{
'Formatter' object has no attribute 'args'
}}}
I using trac 0.11dev. I included TracNav at the Page ""Team"" with:
{{{
[[TracNav(Team/Menu)]]
}}}" anonymous
trac.tracnav 265 broken links with latest SVN trac.tracnav defect normal moschny closed 2006-11-06T23:14:19+01:00 2006-11-07T08:25:00+01:00 "Hello,
I recently upgraded to the latest SVN version of Trac (4155) and have noticed that all the links are broken. I'm using multiple trac servers on the same host, for example:
https://trac.bobbens.dyndns.org/naev
Is one of the servers, therefore the wiki is at
https://trac.bobbens.dyndns.org/naev/wiki
Which is viewed fine from my TracNav page, yet on the main page the links appear as
https://trac.bobbens.dyndns.org/wiki/foo
This was working fine with 0.11dev until now. I've also noticed that the webadmin and other plugins are broken, but many other things work fine, like inter-wiki links and the timeline links, so I'm guessing its a change in the api. Hope you can fix it :)
Thanks for such a great plugin." bobbens
trac.tracnav 263 unable to check out TracNav repository trac.tracnav defect normal moschny closed 2006-09-24T17:44:03+02:00 2012-01-19T02:28:42+01:00 "tried to check out (as per the front page instructions) from the ""anonymous access"" repository http://svn.ipd.uni-karlsruhe.de/repos/javaparty/JP/trac/plugins/tracnav.
I get the following error:
RA layer request failed: PROPFIND request failed on '/repos/javaparty/JP': PROPFIND of '/repos/javaparty/JP': 403 Forbidden (http://svn.ipd.uni-karlsruhe.de)
" clive@…
trac.tracnav 252 tracnav does not render anchors properly trac.tracnav 1.00 defect normal moschny closed 2005-10-19T09:26:28+02:00 2006-02-21T17:56:00+01:00 "Hi,
I am trying to use tracnav to link to a single web page with anchors. When I enter the following ![wiki:TracLinks#EscapingLinks TracLinks # Escaping Links] tracnav renders the # in %23 instead of leaving it as a regular # thus making the anchor not working." eric.moret@…
trac.tracnav 247 No Wiki processing trac.tracnav 1.00 defect normal moschny closed 2005-07-08T16:30:11+02:00 2006-02-21T19:38:33+01:00 "It doesn't appear that the TOC does any Wiki processing before displaying itself. For example inserting http links doesn't work as expected. The wiki text itself is valid since it is displayed correctly in the preview.
I'd look at the code myself but I'm not well up on the trac or wiki system and would probably break more than I'd fix!" anthony@…
trac.tracnav 279 CSS file missing from source distribution trac.tracnav tracnav-3.92 defect trivial moschny closed 2007-03-02T11:37:28+01:00 2007-03-02T16:28:45+01:00 The `TracNav-3.92/tracnav/htdocs/css/tracnav.css` file is missing in `TracNav-3.92.zip`. schodet
uka.gm 152 Method with large byte[] argument crashes with NullPointerException uka.gm defect critical reopened 2003-02-14T20:08:38+01:00 2007-09-29T08:06:38+02:00 "The server-side execution of a method with a large (4096) byte[] argument crashes. The effect is similar to a DGC problem, where a method of a no longer existing object is invoked. The object ID seen by the server is illegal and depends on the contents of the byte array argument. This behavior can only be observed when using the GM transport technology.
=== Problem ===
With GM technology writeHugeByteArray() did send the data out of order, because the buffer was not flushed before transmission.
=== Test ===
{{{
jp.test.TestLargeArgument
}}}
'''fixed''' since 1.07d.
" Ning Li (nli at uiuc dot edu)
uka.gm 243 "Collective replication over GM requires ""server-less"" connections" uka.gm 1.09c defect normal hauma new 2005-03-24T14:53:37+01:00 2005-03-24T14:53:37+01:00 "In particular collective updates (see: ticket:157) are much slower when using KaRMI/GM instead of KaRMI/Ethernet. The reason seems to be that collective operations involve lots of (server-) threads for accumulating the required connections. Currently, a collective operation is mapped to multiple connections that normally serve as transport for remote method invocations. Each such connection is associated on one end with a server thread that is either responsible for executing the remote method invocation, or for forwarding the call to a waiting segment of a transparent distributed thread (see ticket:140).
The problem could be mitigated by introducing a second connection abstraction in KaRMI that is not automatically associated with a server thread. Such server-less connection can only be used, if two threads on both ends agree on a collective operation.
" hauma
uka.gm 242 KaRMI GM technology hangs under heavy traffic uka.gm 1.07i defect normal hauma new 2005-03-22T16:41:11+01:00 2005-03-22T16:41:11+01:00 "Under heavy traffic (especially during replicated object updates) a vitual machine locks up in the native method gmReceive(). The effect is reproducible with {{{jp.bench.BenchReplication -none -frozen}}}.
" hauma
uka.gm 136 Synchronized blocks on expressions of type Object uka.gm 1.07f enhancement minor closed 2002-09-05T11:23:00+02:00 2006-07-18T18:53:18+02:00 "If a block is synchronized on an expression of type Object, the complier can not decide statically, whether the synchronization will be a remote or a local synchronization at runtime.
=== Problem ===
The current transformation creates a double synchronization if the object the synchronization is performed on is a remote object at runtime. If the object is a remote object at runtime, first a lock is acquired on the implementation object, and afterwards a synchronization is performed on the handle object. This synchronization scheme is OK for mutual exclusion, but it does not work signaling on remote objects. If one threads waits in a synchronized block on a remote object, only the lock at the implementation object is released while waiting. Since this thread still holds the monitor of the handle object, another thread that has a reference to the same object handle can not aquire the remote monitor for signaling, because it is blocked at the local handle.
=== Solution ===
At runtime the decision must be made, whether the object the synchronization is performed on is a remote or a local object. If it is a local object, only a local synchronization should be performed. If the object is a remote object at runtime, only the lock of the remote implementation object should be set, and no local synchronization should be happen. The problem could be solved in three ways: 1. Duplicating the code of the synchronized block (one copy with local and one copy with remote synchronization). 2. By transforming the synchronized code into a private method of the same class that is called from within a locally synchronized block, or from within a remote monitor access/release pair. 3. By directly creating Java ByteCode and creating a local subroutine for the code within the synchronized block and calling that local subroutine from within local synchronization or from within a remote monitor access/release pair. Possibility 3 is bad, because it breaks the source to source transformation. Possibility 2 is difficult, because it requires a data-flow analysis to identify the values used within the synchronized block and those that may escape the synchronized block. The transformation into a separate method is not possible, if more than one value must be returned from that method. Therefore possibility 1 seems to be the best one.
=== Test ===
{{{
jp.test.TestSyncBlock
}}}
'''fixed''' since 1.06d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.gm 81 VM dump if no cards available uka.gm defect normal closed 2001-07-16T15:22:27+02:00 2001-07-16T15:22:27+02:00 "With IBM-JDK the initialization fails, if no Myrinet cards are available.
=== Solution ===
Allocate global references for exception classes in native code.
'''fixed''' since 1.05.
" Bernhard Haumacher (haui at haumacher dot de)
uka.graph 251 graph partitioning uka.graph 1.00 defect normal anonymous closed 2005-08-26T03:17:02+02:00 2005-12-29T11:10:20+01:00 vinothkumar_pec@…
uka.karmi 144 TestReenterSyncBlock sometimes fails uka.karmi 1.06d defect major new 2002-09-05T11:23:00+02:00 2005-02-07T14:56:14+01:00 "{{{
Diagnostic output:
Unexpected ERROR marker: remote reentrance RemoteReenter r failed.
Missing OK marker 16.
Test log:
vm0: JPTEST: OK 1: started
...
vm0: JPTEST: OK 13: entered synchronized(r)
vm0: JPTEST: OK 15: exited synchronized r.foo()
vm1: JPTEST: OK 14: entered synchronized r.foo()
vm1: CallHandler: receiving thread crashed:
java.lang.NullPointerException
vm1: java.lang.NullPointerException
vm1: at uka.karmi.rmi.CallHandler.run(CallHandler.java:394)
vm1: at java.lang.Thread.run(Thread.java:536)
vm1: JPTEST: OK 18: entered synchronized r.bar()
vm1: JPTEST: OK 19: entered synchronized(r)
vm1: JPTEST: OK 20: exited synchronized(r)
vm0: JPTEST: ERROR: remote reentrance RemoteReenter r failed
vm0: JPTEST: OK 17: created RemoteReenter r on remote node
vm0: JPTEST: OK 21: exited synchronized r.bar()
vm0: JPTEST: LAST-OK 22: finished
vm0: CallHandler: receiving thread crashed: \
java.net.SocketException: Connection reset by peer:
Connection reset by peer
vm0: java.net.SocketException: Connection reset by peer:
Connection reset by peer
vm0: at java.net.SocketInputStream.socketRead0(Native Method)
vm0: at java.net.SocketInputStream.read(
SocketInputStream.java:116)
vm0: at java.io.BufferedInputStream.read1(
BufferedInputStream.java:220)
vm0: at java.io.BufferedInputStream.read(
BufferedInputStream.java:277)
vm0: at uka.transport.UnmarshalStream.requestTest(
UnmarshalStream.java:1070)
vm0: at uka.transport.UnmarshalStream.readByte(
UnmarshalStream.java:1126)
vm0: at uka.transport.MarshalContext.receiveSingleByte(
MarshalContext.java:142)
vm0: at uka.karmi.rmi.CallHandler.run(CallHandler.java:394)
vm0: at java.lang.Thread.run(Thread.java:536)
}}}
=== Evaluation ===
Seems to occur rarely. Only seen with DEBUG-DGC enabled.
'''todo''' since 1.06d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 106 Remote calls with with large (non-transportable) arguments fail with uka.gm uka.karmi 1.05b defect major new 2001-09-14T19:01:00+02:00 2005-02-02T22:26:24+01:00 "The exception reported is
{{{
jp.lang.RemoteError: : KaRMI: transport problem
'java.io.IOException: received message to large'
}}}
=== Problem ===
KaRMI/GM messages are size bounded. There is a maximum message size that is handled by the transport subsystem. The uka.transport MarshalStream is aware of this fact and can be configured to create write request with a bounded size (by overriding the method writeLongByteArray()). But there is another requirement when using a message passing subsystem: A message that is received must always be accepted as a whole. This is not always met by the UnmarshalStream implementation. When reading plain byte arrays, the read requests are forwarded directly to the underlying stream without buffering. Especially because the fall-back serialization does not adhere to the rule that send and receive requests have to be paired with exactly the same size.
'''todo''' since 1.05b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 189 A CallHandler is unnecessarily associated with each connection. uka.karmi 1.09a defect normal new 2004-08-11T16:43:00+02:00 2005-03-12T18:36:37+01:00 "Each connection in KaRMI is a call handler. This is not useful for each kind of connection (e.g. the connections used in the replicated wait process or the collective or exclusive update operations on replicated objects).
The calls {{{StreamClientConnection.openSendCall()}}} and {{{StreamClientConnection.closeReceiveResult()}}} register and unregister their corresponding call handler, if the connection's command identifier is {{{APP_CALL}}}. The registration of a call handler marks it responsible for handling incoming calls for the current distributed thread. Multiple registrations of call handlers for the same thread identifier build up a stack of call handlers that models the distributed stack of the current distributed thread. During unregistering a call handler, the top of this stack is removed. Obviously, the call handler registration is unnecessary for special remote operations that cannot cause a recursive call back.
If call handlers are not unregistered in exactly the reverse order of their registration, the distributed stack gets completely confused.
=== Workaround ===
If a thread opens more then one connection in {{{APP_CALL}}} mode, it has to close them in reverse order.
=== Solution ===
A new sort of connections is required that are not associated with a call handler. Or at least a new command identifier should be introduced that causes the remote operation to be executed in the local representative thread (like {{{APP_CALL}}}), but does not require a call handler registration, because no recursive call is possible. The new command identifier could be called {{{APP_CALL_NR}}} for non-recursive application calls.
'''todo''' since 1.09a.
" Bjoern-Oliver Hartmann, Bernhard Haumacher
uka.karmi 187 Multiple TCP/IP Interfaces are not supported uka.karmi 1.07g enhancement normal new 2003-09-10T12:43:00+02:00 2005-02-07T15:01:06+01:00 "Currently it is not possible in a clean and transparent way to direct KaRMI communication over secondary TCP/IP interfaces.
The standard way to setup a cluster with an additional fast interconnect such as Myrinet or Infiniband is to assign IP addresses from a private subnet to the fast interconnect adapters. In most cases {{{InetAddress.getLocalHost()}}} however will return the address of the primary adapter, connected to the (standard) slow Ethernet network. The socket technology only uses this address and thus communicates always using the primary interface.
=== Solution ===
Introduce an additional configuration parameter for the socket technology that allows to specify the interface that shall be used by KaRMI, for example a subnet identifier. This way several instances of the socket technology can be used, each of them using a different network. The existing technology selection mechanism could select the appropriate instance for each pair of VMs, totally transparent to the user.
'''todo''' since 1.07g.
" Thomas Moschny
uka.karmi 164 Insufficient error message in case of internal errors uka.karmi 1.07f defect normal new 2003-09-02T10:32:00+02:00 2003-09-02T10:32:00+02:00 "When a stream server crashes during internal processing (before the application method is invoked, or during service calls), no error message is marshaled back to the client. Instead the connection is closed silently. In these cases, the client gets a RemoteException that was caused by an EOFException during requesting the remote method return code.
'''todo''' since 1.07f.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 153 CallHandler theads never die uka.karmi 1.07a defect normal new 2002-11-12T19:20:43+01:00 2005-03-24T15:02:06+01:00 "CallHandlers can never die, even if their connection (uka.karmi.rmi.ClientConnection) object would be garbage collected. Server-side call handlers are kept in a pool (uka.karmi.rmi.ServerConnection.handlers) for re-usage, but they have also no chance to die, even if they are without work for a long period of time.
=== Workaround ===
As work-around, you could disable the transparent distributed thread feature (if you do not rely on that) by setting the runtime properties uka.karmi.useDistributedThreads and uka.karmi.useThreadID to false. This will prevent CallHandlers from being created.
'''todo''' since 1.07a.
" Dan Hanley (dan at magus dot co dot uk)
uka.karmi 148 RemoteServerRef.getClientHost() and distributed threads uka.karmi 1.06d defect normal new 2002-09-05T11:23:00+02:00 2002-09-05T11:23:00+02:00 "The implementation of getClientHost() does rely on the fact that a remote server method is executed in an ExecutionThread. With distributed threads the thread that executes a server method can also be an application thread. This causes getClientHost() to throw an exception.
=== Evaluation ===
In the context of distributed threads the getClientHost() interface seems not to be appropriate.
'''todo''' since 1.06d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 107 uka.util.PeriodicTask broken uka.karmi 1.05b defect normal new 2001-09-14T19:01:00+02:00 2010-07-26T13:25:57+02:00 "Singleton thread is never initialized. Should also be checked for further possible bugs.
=== Solution ===
In method add(Runnable task), replace ""if (thread != null)"" with ""if (thread == null)"".
'''todo''' since 1.05b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 99 GM on only one VM per node uka.karmi 1.05a defect normal new 2001-08-23T13:48:11+02:00 2001-08-23T13:48:11+02:00 "GM technology is only supported on one Java VM per node. All other nodes keep using TCP/IP.
'''todo''' since 1.05a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 64 Interoperability with RMI uka.karmi 1.04b defect normal new 2001-02-13T19:11:00+01:00 2001-02-13T19:11:00+01:00 "If KaRMI is used in an application that also uses RMI objects, these RMI objects are not treated as expected: In remote method calls such RMI server objects are copied instead of transformed to a stub. The same problem occurs with KaRMI objects in RMI remote method calls.
=== Evaluation ===
Maybe can not be fixed satisfactory.
'''todo''' since 1.04b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 30 Missing test case for bridge objects uka.karmi 1.03d defect normal new 2000-11-20T22:44:25+01:00 2000-11-20T22:44:25+01:00 "The effectiveness of the fix for ticket:28 must be shown with a test case. In ""normal"" one-technology operation the code for bridge objects is never executed.
'''todo''' since 1.03d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 13 No stub transmission outside a remote call uka.karmi 1.00 defect normal new 2000-11-15T13:50:36+01:00 2000-11-15T13:50:36+01:00 "Stubs or remote references can not be transmitted outside a remote method invocation. This is not the case for remote server implementation objects. They can be transmitted outside a marshal stream. So object migration with KaRMI is possible in principle, but not practical, because the remote implementation object can not be marshalled into a byte array if it contains remote references to other remote objects.
=== Workaround ===
Migration can be implemented as service call. Addidtionally advantage: better performance.
=== See also ===
ticket:21, ticket:51
'''todo''' since 1.00.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 190 Connections should be cleaned up asynchronously. uka.karmi 1.09a enhancement normal new 2004-08-11T16:43:00+02:00 2005-02-02T23:17:02+01:00 "After each usage, a KaRMI connection is cleaned up and put back into a connection pool. This cleanup is done in closeReceiveResult() on the client side and in closeSendResult() on the server side. Under certain circumstances (see uka.transport.MarshalStream.symmetricReset()), this cleanup requires sending and receiving additional data. Since the cleanup phase of a connection should not be on the critical path of a remote operation, it should be handled asynchronously in a helper thread. The only requirement is that the cleanup is finished before the connection is reused.
'''todo''' since 1.09a.
" Bernhard Haumacher
uka.karmi 216 Stubs built by the client from an URL interfere with transparent distributed threads uka.karmi 1.07a defect minor hauma closed 2005-02-08T14:32:07+01:00 2005-02-08T14:40:42+01:00 "The basic KaRMI test cases (e.g. TestReplace) hang when enabling
DEBUG-CLEANUP. This is due to a problem with stubs built from an URL
(which is done during locating the KaRMI registry) and the transparent
distributed threads feature in KaRMI. For the initial contact, the
client (which wants to get a remote reference to the registry) need to
build a special stub object from an URL identifying the host where the
registry runs. This special stub is not part of the distributed
garbage collector and does not know, whether it points to a local or
remote object. Therefore, method calls processed through this stub
cannot use the local shortcut, but always make use of a network
connection.
Especially when DEBUG-CLEANUP is enabled, this causes a deadlock for
local calls (Registry.lookup() from the host where the registry is
located), because the receiving server thread tries to dispatch the
call back to the calling thread, but this thread does a blocking
receive operation from the network connection trying to read the
cleanup pattern (which is never sent).
" hauma
uka.karmi 203 Remote monitor acquire (RMA) uka.karmi enhancement normal closed 2002-11-12T19:20:43+01:00 2002-11-12T19:20:43+01:00 "Implement remote monitor acquire functionality to remotely synchronize on the server implementation instead of on a local stub object. This is the remote correspondence to synchronized blocks on local Java objects. A RMA acquire operation requests entering a monitor of a remote server implementation object by a remote representative for a distributed thread. A RMA release requests unlocking the remote server implementation.
=== Test ===
{{{
jp.test.TestRawRMA
}}}
'''implemented''' since 1.07a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 202 Interrupt forwarding uka.karmi enhancement normal closed 2002-11-12T19:20:43+01:00 2002-11-12T19:20:43+01:00 "Forward interrupts sent to a local representative thread in an out-of-order invocation along a remote call to dispatch the interrupt condition to the head of the distributed thread.
=== Test ===
{{{
jp.test.TestInterrupt
}}}
'''implemented''' since 1.07a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 201 Thread re-usage uka.karmi enhancement normal closed 2002-11-12T19:20:43+01:00 2002-11-12T19:20:43+01:00 "Reuse threads for all segments of the distributed thread that are located in the same virtual machine. While a local representative for a distributed thread is waiting for a remote call to return it can also process all more recent segments of the same distributed thread on the same machine. This enables monitor reentrance for distributed threads.
=== Test ===
{{{
jp.test.TestThreadPreserve
}}}
'''implemented''' since 1.07a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 200 Thread ID uka.karmi enhancement normal closed 2002-11-12T19:20:43+01:00 2002-11-12T19:20:43+01:00 "Set a thread ID for each thread and transmit this ID with each remote call to keep track of the flow of control in a distributed thread.
=== Test ===
{{{
jp.test.TestThreadID
}}}
'''implemented''' since 1.07a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 195 Additional method identifiers in the stubs uka.karmi defect normal closed 2000-11-20T22:44:25+01:00 2011-05-05T02:38:23+02:00 "KaRMI uses randomly generated numbers for the identification of remote methods. These numbers are used during the invocation of a method in a stub and guide the dispatch process of the method in the skeleton object on the server side. These numbers are part of the wire protocol that has to be known to invoke a method on a remote server object. Without the knowledge of these method numbers a JavaParty handle can not directly invoke a remote method. The numbers are hardcoded into the generated stub and skeleton classes by the stub generator.
=== Solution ===
The skeleton now defines a constants for each method number. The name of such a constant is determined by the name and type of the method. With this knowledge that is available during handle generation the correct method dispatch number can be used to invoke a remote method directly.
'''fixed''' since 1.03d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 194 Eliminate parameter objects uka.karmi defect normal closed 2000-11-20T22:44:25+01:00 2000-11-20T22:44:25+01:00 "KaRMI stubs use parameter objects during method invocations to store all parameters of a method invocation. These parameter objects are responsible for parameter marshaling and unmarshaling. They are used as a container object for tunneling the method parameters through the deeper KaRMI layers.
The parameter objects are created during the generation of the stub and skeleton classes. Their name is build from the remote implementation class by appending a randomly chosen number. At the time of the JavaParty transformation these parameter classes are not yet known and their class name can not be predicted, because it is chosen in a non-deterministic fashion. Because the skeleton implementation depends on the parameter objects, a method can only be invoked on a remote server when using these parameter objects. From an other perspective these parameter objects are part of the protocol for a KaRMI remote method invocation.
=== Evaluation ===
The parameter objects make the proposed optimization of JavaParty very hard, because the wire protocol used to do remote method invocations with KaRMI depends on more or less randomly chosen class names of classes that are generated during the stub/skeleton generation. These parameter objects should be eliminated because of two other reasons: They slow down remote method invocation in general, because of the additional object allocation. When performing frequent remote method invocations, the additional allocation of parameter objects stresses the local garbage collector, because the parameter object is subject to deallocation immediately after the return of the method.
=== Solution ===
Change the interface to the KaRMI reference layer in a way that the parameter marshaling can be inlined into the server stub without allocation additionally objects. The unmarshaling must be inlined into the skeleton object in the same way. This approach removes the randomly generated class names of the parameter objects from the KaRMI wire protocol and enables even remote method invocation without the usage of general stub objects.
'''fixed''' since 1.03d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 166 Final variables in transportable classes uka.karmi defect normal closed 2004-03-25T11:13:14+01:00 2012-02-07T12:57:17+01:00 "Since references to other objects are unmarshaled after the transportable constructor completes, final variables of reference type cannot be declared final. The unmarshaling of references must be delayed until the current unmarshaled object is added to the object space of the unmarshaling stream to enable cycle resolution. Therefore the unmarshaling is split into the construction of the transportable object (performed in the transportable constructor along with the unmarshaling of primitive values) and the unmarshaling of references that is performed in a separate method unmarshalReferences(), which is called by the unmarshaling stream after the object is constructed and added to the object space.
=== Solution ===
The unmarshaling process could also actively register the object being unmarshaled at the unmarshaling stream from the transportable constructor in the transportable root class (the top-most transportable class in the class hierarchy). But assigning reference fields also directly in the unmarshaling constructor leads to interleaving the unmarshaling of primitive and reference fields (each constructor in the class hierarchy does unmarshaling of primitive values and references). But marshaling and unmarshaling all primitive fields of an object at once leads to better performance, because the size of primitive values can be computed at compile time, which can be used for enhanced buffer management.
=== Evaluation ===
The implementation of non-recursive marshaling (see ticket:174) does explicitly support classes with final fields (primitive types and references).
'''fixed''' since 1.08b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 150 Hierarchical DGC fails with localEnter error uka.karmi defect normal closed 2002-11-12T19:20:43+01:00 2002-11-12T19:20:43+01:00 "When trying to look up an object from a registry that runs in the same virtual machine using an URL of the form ""rmi://localhost/server-name"", the call to Naming.lookup() fails with the following error message:
{{{
java.lang.UnsupportedOperationException
at uka.karmi.dgc.HierarchicalDGC$EnterContext.localEnter(
HierarchicalDGC.java:130)
at uka.karmi.rmi.SingleRemoteClientRef.readExternal(
SingleRemoteClientRef.java:354)
at uka.karmi.rmi.SingleRemoteClientRef.unmarshalReferences(
SingleRemoteClientRef.java:458)
at uka.transport.UnmarshalStream.readObject(
UnmarshalStream.java:318)
at uka.karmi.rmi.server.RemoteStub.unmarshalReferences(
RemoteStub.java:208)
at uka.transport.UnmarshalStream.readObject(
UnmarshalStream.java:318)
at uka.transport.MarshalContext.receiveObject(
MarshalContext.java:92)
at uka.karmi.registry.RegistryImpl_KStub.lookup(
RegistryImpl_KStub.java)
at uka.karmi.rmi.Naming.lookup(Naming.java:99)
}}}
The lookup (with the same URL) from another virtual machine running on the same host works fine.
=== Evaluation ===
The method localEnter() of the hierarchical garbage collector's enter context did throw unconditionally an UnsupportedOperationException. This was due to the following assumption:
A reference to a local object does not arrive at a virtual machine during ""normal"" operation. Passing a reference to a remote object to another machine always causes a bridge object to be created on the machine that passes the reference. This makes sure that a passed remote reference always points to an object that resides on the machine that passed the reference. When receiving a reference the referenced object can not be local.
This assumption is wrong, because under special circumstances a reference pointing to a local object may ""enter"" a virtual machine: When using an artificial reference (e.g. to the registry) to make a call to a server object that resides on the same local machine, the locality of this call can not be detected and all references passed along that call are marshaled and unmarshaled instead of being passed by reference. During the unmarshaling process of such a reference the localEnter() method is called, if the referenced object also resides on the local machine. Therefore this method should not throw an UnsupportedOperationException! See ticket:150.
=== Test ===
{{{
uka.karmi.test.TestBase -master -nodes 2
uka.karmi.test.TestBase -host localhost
}}}
'''fixed''' since 1.07a.
" Brien Oberstein (brien dot oberstein at transacttools dot net)
uka.karmi 147 Slow method invocations with reference arguments uka.karmi defect normal closed 2002-11-12T19:20:43+01:00 2002-11-12T19:20:43+01:00 "Passing a ""new"" remote reference in a remote method invocation is slow. A new remote reference is one that was just created (by passing an old one in a remote method invocation). While passing an old reference costs time(ping(ref)) - time(ping()) = 238.974 - 93.008 = 145.966 us, the cost of passing the new reference in the pingPong() method costs time(pingPong(ref)) - time(pingPong()) - time(passing-old-ref) = 1049.859 - 264.632 - 145.966 = 639.261 us.
{{{
# JP/KaRMI/RemoteResident/DistributedThreads/ParaStation/Myrinet
void ping() : 93.008us
void pingPong() : 264.632us
void ping(ref) : 238.974us
void pingPong(ref) : 1049.859us
void ping2(ref) : 1020.029us
synchronized(r) : 168.109us
}}}
The reason for that is the hierarchical garbage collector. It uses so called bridge objects for locally (per remote reference) counting the number of references passed to other VMs. But a bridge object can also serve as a communication proxy. Such bridge object requires more initialization that can be done lazily. When initializing bridge objects lazily, the reference passing overhead can be greatly reduced:
{{{
# JP/KaRMI/RemoteResident/DistributedThreads/ParaStation/Myrinet
void ping() : 93.441 us +- 1.101us
void pingPong() : 260.262 us +- 4.386us
void ping(ref) : 237.287 us +- 20.265us
ref ping(ref) : 358.264 us +- 55.810us
void pingPong(ref) : 536.787 us +- 36.892us
void ping2(ref) : 565.000 us +- 50.006us
synchronized(r) : 172.106 us +- 0.168us
}}}
{{{
# JP/KaRMI/RemoteResident/DistributedThreads/TCP/Ethernet100
void ping() : 200.295us +- 1.855us
void pingPong() : 416.443us +- 4.801us
void ping(ref) : 328.531us +- 24.257us
ref ping(ref) : 538.933us +-111.142us
void pingPong(ref) : 709.770us +- 69.030us
void ping2(ref) : 730.650us +- 79.527us
synchronized(r) : 359.134us +- 0.326us
}}}
For comparison here is the corresponding section form the RMI benchmark:
{{{
# JP/RMI/RemoteResident/TCP/Ethernet100
void ping() : 295.238us +- 1.102us
void pingPong() : 628.288us +- 11.353us
void ping(ref) : 1090.861us +-138.926us
ref ping(ref) : 2255.411us +-135.265us
void pingPong(ref) : 2224.026us +- 58.650us
void ping2(ref) : 2232.143us +- 61.107us
synchronized(r) : 586.212us +- 0.719us
}}}
'''fixed''' since 1.07a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 145 TestRef hangs uka.karmi defect normal closed 2002-11-12T19:20:43+01:00 2002-11-12T19:20:43+01:00 "Test-case with heavy remote reference passing hangs.
=== Evaluation ===
From the thread-dumps the situation looks like a remote method invocation is being dispatched to a call handler, but no thread is listening any longer at this handler to execute the call.
=== Problem ===
The problem was due to a race condition in the connection clean-up code. The thread identifier was unregistered, after the connection was already put back into the connection pool. Immediately after putting the connection back into the pool, a concurrent DGC call reused this connection. The late unregister call now never occurred, because service calls (like a DGC call) do not use thread identifiers. The result was a call handler that is still registered for a thread identifier, without a thread actually executing method calls for that distributed thread. The next remote method invocation to that node blocked, because the method execution was redirected to the non-existing representative thread.
'''fixed''' since 1.07a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 143 broken DGC produces dangling remote references uka.karmi defect normal closed 2002-11-12T19:20:43+01:00 2002-11-12T19:20:43+01:00 "The hierarchical DGC frees objects early because the bridge objects do not keep a local reference to the remote reference object they are a proxy for. This breaks the hierarchical reference counting scheme. The result are failing remote method calls (internal NullPointerException), because on the server side the corresponding server implementation is no longer available. In rare cases also an internal ""illegal method number"" or ""stream corrupted"" exception can be seen, if the object identifier is reused in the meantime for a server of another type, and a call to that server is performed via the out-of-date dangling reference of another type. This can happen, because the ""second object identifier"" that is responsible to prevent dangling references from accessing new server implementations is not used.
'''fixed''' since 1.07a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 141 Adoption of thread IDs on the server-side uka.karmi defect normal closed 2002-11-12T19:20:43+01:00 2002-11-12T19:20:43+01:00 "During the dispatch of a remote method call, the dispatching server thread adopts the thread ID transmitted with the call. After the call is finished, the the thread ID must be reset to prevent interrupts from being dispatched to this server thread now unrelated to the distributed thread with this thread ID. If the thread that actually dispatches the remote method implementation is an application thread that does the dispatch during a callback invocation, the thread ID transmitted with the call is the same as the currently set thread ID.
=== Problem ===
On the server-side the thread ID was adopted by the dispatching thread and reset to zero after the dispatch completed. This is OK for level 0 invocations, where the server thread is a thread belongs to the runtime system. In a callback invocation, the thread doing the dispatch is actually an application thread. In this case, the application thread forgets its thread ID after servicing the first callback invocation.
=== Solution ===
A thread servicing a remote method invocation now keeps its former thread ID and restores it after the call is complete.
=== Problem ===
The above solution prevents application threads from forgetting their thread IDs, but is still inefficient, because an application thread that is servicing a callback invocation does not need to adopt the thread ID transmitted with the call, because it already has the correct thread ID set.
=== Solution ===
ServerConnection gets an parameter ""isCallback"" in its service() method. This value is stored and can later be used to decide whether to set thread IDs transmitted along with the call.
=== Problem ===
The flag isCallback provides the wrong information. A service call is never dispatched as callback, but is should never set the thread ID transmitted with the call. The above solution breaks TestInterrupt, because the interrupt service call gets set the thread ID of the thread it should interrupt - so it interrupts itself.
=== Solution ===
Pass a flag useTID to the server connection's service() method that is initialized correctly from the context.
'''fixed''' since 1.07a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 124 memory leak in logical thread IDs uka.karmi defect normal closed 2002-11-12T19:20:43+01:00 2002-11-12T19:20:43+01:00 "For application threads, a logical thread ID is created at the time, the thread enters the KaRMI subsystem to perform a remote method invocation. A new logical thread ID is created for each (!) top-level call that is performed directly form an application thread, instead of once per thread. There are three problems: First, this thread ID is never deleted from the tables resulting in a memory overflow. Second, if the ID was deleted after the top-level call returns, the frequent memory allocation per call triggering the GC is prohibitive (KaRMI can perform a whole remote call without '''any''' memory allocations). Third if the ID stay assigned to the application thread, it can not be decided, whether this thread has died and when the allocated ID can be released. This also is a memory leak, but a much smaller one.
'''partially-fixed''' since 1.06a.[[br]]
Replace the thread2id hash table with a java.lang.ThreadLocal variable. This does also fix the problem that new thread IDs are allocated for every top-level call. New thread IDs in each call render thread IDs useless in tracing threads and their remote method invocations. This solution does not prevent object allocation per call, because the thread ID is entered into a hash table on the remote side and discarded from there when the call returns.
'''partially-fixed''' since 1.07a.[[br]]
To avoid continually allocating Long objects and storing them into the thread local variable, a thread information object should be allocated once and the thread identifier should be stored as instance variable to that thread information object. Maybe, this object can also be used for information necessary for object replication.
=== Evaluation ===
STEP/b is fixed in the context of distributed thread implementation.
=== See also ===
ticket:140
'''fixed''' since 1.07a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 103 DGCThread does busy local GC uka.karmi defect normal closed 2001-12-05T12:01:54+01:00 2001-12-05T12:01:54+01:00 "An instance of the class uka.karmi.rmi.DGCThread is instantiated during KaRMI initialization. It activates the '''local''' garbage collector every few seconds. In a Java VM there should be no need for explicitly invoking the local GC. Because the distributed GC in KaRMI is implemented by means of the finalization() methods called by the local GC, this class seems to be completely superfluous.
=== Solution ===
Removed class DGCThread and all its usages.
'''fixed''' since 1.05c.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 102 DeepClone crashes with boolean arrays uka.karmi defect normal closed 2001-12-05T12:01:54+01:00 2001-12-05T12:01:54+01:00 "Objects with member variables of type boolean[] can not be cloned.
'''fixed''' since 1.05c.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 92 remove ParaStation 2 support uka.karmi defect normal closed 2001-08-23T13:48:11+02:00 2001-08-23T13:48:11+02:00 "Removed packages uka.ps and uka.karmi.ps
'''fixed''' since 1.05a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 76 synchronization problem in stream technology uka.karmi defect normal closed 2001-05-09T23:30:00+02:00 2001-05-09T23:30:00+02:00 "Synchronization was missing handing back a connection to the stream technology class. Programs failed if concurrent activities tried to invoke methods on co-located remote objects from the same node.
=== Test ===
{{{
jp.test.TestConcurrent
}}}
'''fixed''' since 1.04e.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 72 shortcut to remote server must be declared transient uka.karmi defect normal closed 2001-05-07T13:41:12+02:00 2001-05-07T13:41:12+02:00 "In KARMI_PACKAGE.server.RemoteStub the short-cut reference to the implementation object of a remote server must be declared transient, otherwise is the implementation object marshaled if a remote reference is transmitted. The bug did only affect versions of KaRMI that were compiled without the SMART_STUBS option.
'''fixed''' since 1.04d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 70 Connection code mixed with socket technology uka.karmi defect normal closed 2001-05-07T13:41:12+02:00 2001-05-07T13:41:12+02:00 "The general purpose connection handling code should be extracted from the socket technology into a new stream technology. The stream technology should be used as new base technology for all connection oriented technologies.
'''fixed''' since 1.04d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 60 Build with SERIAL_JDK uka.karmi defect normal closed 2001-05-07T13:41:12+02:00 2001-05-07T13:41:12+02:00 "The source tree for building with JDK serialization was not maintained. This version does not build.
'''fixed''' since 1.04d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 55 Array class loading uka.karmi defect normal closed 2001-01-30T18:09:53+01:00 2001-01-30T18:09:53+01:00 "This bug can be discovered using the IBM-JDK 1.3 on Linux and the SUN-JDK 1.2.2 on Solaris with TestEnvironment. TestEnvironment with SUN-JDK 1.3 works fine on Linux and Solaris.
=== Evaluation ===
setSibblings([Ljp.test.TestEnvironment;) does crash while the skeleton tries to parse the array parameter (exact location: after the array element type has been read the control flow immediately jumps to closeSendResult() without a call to closeReceiveCall() and openSendResult() has been seen). It seems that an exception was thrown when the server tried to load the class of the array type.
The call to closeSendResult() happens because in ServerThread.dispatch() the invocation of the skeleton method is guarded by a try {} catch block. Exceptions caught here are not thrown from the application, because the skeleton already handles application exceptions by marshaling them back to the client.
=== Problem ===
This internal exception was not marshaled back to the client.
=== Solution ===
This is now fixed by retrying openSendResult(false), sendObject(ex), closeSendResult() in the dispatch() method of ServerThread. The reason of the exception occurred is still unknown, but now the exception is marshaled back to the client. This causes an internal error to be thrown on the client side, because the ClassNotFoundException has not been declared by the client method but was thrown internally by KaRMI.
=== Evaluation ===
With IBM-JDK on Linux a ClassNotFoundException for the class ""[Ljp.test.TestEnvironment;"" is thrown during unmarshaling an array. This works pretty fine with SUN-JDK 1.3. It is not clear how to load the meta-representation of an array class ""platform independent"".
=== Evaluation ===
The JDK loads such classes in a private native method of ObjectInputStream loadClass0(). The documentation to loadClass0() says that the appropriate class loader is searched on the call stack for loading the class. It is not clear how to load the meta representation of an array class in pure Java if ClassLoader.getSystemClassLoader().loadClass(className) is the wrong way.
=== Code ===
{{{
socket.ServerThread.dispatch()
}}}
=== See also ===
ticket:98
'''closed''' since 1.03r.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 54 jpp.perl contains path /usr/bin/perl uka.karmi defect normal closed 2002-05-29T15:59:00+02:00 2002-05-29T15:59:00+02:00 "On (for example) solaris, perl is installed under /export/opt/bin/perl. Hence, the build script for KaRMI will fail.
=== Solution ===
Call perl via /bin/sh script, assuming that sh is installed under /bin/sh on all supported plattforms and that perl can be found via the PATH environment variable, if executed by an sh script. Pipe the input to the perl script's standard input.
=== Evaluation ===
Since JavaParty is now built using GTML and Apache ant, there is no need for jpp any more.
'''fixed''' since 1.06a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 46 library classes with value semantics uka.karmi defect normal closed 2001-01-17T19:29:20+01:00 2001-01-17T19:29:20+01:00 "Objects with value semantics do not need parameter duplication in local remote calls. Classes with value semantics are for example
{{{
java.lang.Boolean, java.lang.Byte, java.lang.Short,
java.lang.Integer, java.lang.Long, java.lang.Float,
java.lang.Double
}}}
but also
{{{
java.lang.String
}}}
=== See also ===
ticket:20
'''fixed''' since 1.03p.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 45 stub method invocation protocol uka.karmi defect normal closed 2001-01-30T18:09:53+01:00 2001-01-30T18:09:53+01:00 "The functionality of RemoteClientRef.getContext(...) can be merged with Connection.openSendCall(). The resulting method should be named RemoteClientRef.openCallContext() in RemoteClientRef.
The methods Connection.closeSendCall() and Connection.openReceiveResult() could be merged, too. The problem here is that openReceiveResult() blocks until the result of the method invocation is available from the remote side. With a merged version of these two methods the implementation of an asynchronous invocation is no longer possible. These two methods should '''not''' be joined.
=== Evaluation ===
This modification is not expected to improve the performance but only to make the fat stub classes a little lighter. It does not seem to be worth the effort.
'''closed''' since 1.03r.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 32 File hierarchy restructuring uka.karmi defect normal closed 2000-12-19T11:43:12+01:00 2000-12-19T11:43:12+01:00 "Moved karmi/src/java.rmi -> karmi/src/uka/karmi.rmi and adapted all imports, uses, build scripts, etc. Created Makefiles for GJ and KaRMI. Fixed lot of uka.karmi references by replacing them with PACKAGE_KARMI or @KaRMIPackage@ macros. Added rcs keywords to nearly all files in karmi. Removed cyclic references from packages gjc/v6/comp, gjc/v6/jp and gjc/v6 so that they can basically be compiled one after each other (though there is still a bug in GJ that does not allow gjc/v6 to be compiled separately).
'''fixed''' since 1.03f.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 29 Local technology no longer needed uka.karmi defect normal closed 2000-11-20T22:44:25+01:00 2000-11-20T22:44:25+01:00 "Local method invocations are handeled by the stub object directly (see ticket:20). The local technology class is no longer needed, the administration of the copy environments used to duplicate method parameters and results is moved to the transport class. Support classes for object duplication are moved to KARMI_PACKAGE.
'''fixed''' since 1.03d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 28 BridgeServerRef implementation broken uka.karmi defect normal closed 2000-11-20T22:44:25+01:00 2000-11-20T22:44:25+01:00 "It's not yet clear how to support bridged objects with the new call protocol introduced in fix for ticket:27. Because stubs and skeletons now are responsible for the signature of a method this knowledge is no longer available in the remote reference layer. Bridge objects need to forward a remote method invocation, but can no longer forward the parameters and result values, because their types are no longer known in this generic context.
=== Solution ===
The bridge object uses a combination of a skeleton and a stub object to receive the call and forward it to the target location. Instead of connecting a skeleton object to a remote server, it is connected to a remote stub object that references the remote server. The skeleton receives the method call and its parameters and invokes the same method again on the stub instead of the remote server itself.
=== Problem ===
At the reference layer, the concrete class of the referenced server is not known to create a stub and skeleton object of a suitable type matching the remote server.
=== Solution ===
Therefore the stub is created in a pseudo remote method invocation on ther server side where the concrete type is known and sent back to the place where the bridge object is needed. This remote method invocation on the remote reference is no normal KaRMI remote method invocation, because it is not handeled by the remote server itself but by the technology that exported the remote server object in a SERVICE call.
=== Cave ===
For that approach the implementation of the skeleton objects must be present in all address spaces that might create bridge objects. In normal RMI skeleton classes must only be present in the address space where the remote server object lives.
'''fixed''' since 1.03d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 26 Unnecessary type cast in local KaRMI calls uka.karmi defect normal closed 2000-11-15T13:50:45+01:00 2000-11-15T13:50:45+01:00 "The shortcut invocation of remote server objects use a reference declared in the superclass uka.karmi.server.RemoteStub of interface type Remote. Each local method invocation must cast this reference to the concrete server implementation type.
=== Solution ===
Move the declaration of the reference to the generated stub class. Declare the reference with the concrete type in each generated stub class.
=== Evaluation ===
Did not significantly improve the performance.
'''fixed''' since 1.03b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 24 Java environment detection within KaRMI build uka.karmi defect normal closed 2000-11-15T13:50:45+01:00 2000-11-15T13:50:45+01:00 "Detection did relay on JAVA_HOME.
'''fixed''' since 1.03a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 21 Premature object replacement uka.karmi defect normal closed 2000-11-20T22:44:25+01:00 2000-11-20T22:44:25+01:00 "All objects that implement the remote interface are replaced to their corresponding stubs during a remote method invocation. This happens without distinction whether the remotely called method expects a parameter of interface or implementation type. With the utmost probability this leads to a type conflict after unmarshaling the parameter.
=== Evaluation ===
The same problem exists in RMI, too. Remote server objects can not be marshaled in a remote method invocation. This is a principal problem, because object replacement during the serialization process occurs independent of the expected type of the instance variable or parameter that holds the original object. There is no workaround or fix for this problem.
=== Test ===
{{{
uka.test.replace.Main [-server | -client]
}}}
=== See also ===
ticket:13
'''closed''' since 1.03d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 20 Method call on a local server is too slow uka.karmi defect normal closed 2000-11-15T13:50:41+01:00 2000-11-15T13:50:41+01:00 "In KaRMI already exists a shortcut for a method call where the server object lives in the same address space. In comparison to a standard Java method invocation it is from 600 up to 1700 times slower (with JIT). This is because of the interface hierarchy that has to be tunneled through and the parameter duplication to simulate the remote semantics.
=== Solution ===
Most methods have only parameters and return values of basic type, so they can be called directly from the stub. Therefore we need a shortcut Stub->Server in case the references are SingleRemoteClientRef->UnicastRemoteServerRef pairs and the server is local to the stub.
=== Solution ===
Handling of parameter and return types: * boolean, byte, char, int, float, long, double can be passed by value without marshaling and unmarshaling.
* String objects are immutable, therefore they do not need to be copied. They can be passed by reference.
* Objects that implement the uka.lang.Immutable interface are declared to be immutable by the programmer and can be passed by reference, too.
* Parameters that are declared of a type that '''extends''' the remote interface uka.karmi.Remote are either stubs or remote server objects '''at runtime'''. Stubs can be passed by reference because they are immutable, remote servers have to be converted to a stub pointing to the local server object to simulate the remote method call behavior.
* All other objects have to be costly copied.
'''partially-fixed''' since 1.02a.[[br]]
Add a new instance variable ""Remote server"" to uka.karmi.server.RemoteStub that points to a local server implementation if the combination SingleRemoteClientRef->UnicastRemoteServerRef is available.
declare ""RemoteClientRef remoteClientRef"" protected to detect all usages of this field within KaRMI. The protected access modifier ensures that the generated stubs can further on access/read that field directly. Declare get and set methods in RemoteStub for remoteClientRef. The set method can be used to update the shortcut reference. Modify all direct usages of remoteClientRef in KaRMI to the appropriate access method.
'''partially-fixed''' since 1.02b.[[br]]
Modify the generated stubs to make use of the shortcut. For example for class XXX, a stub XXX_KStub is generated. Before the modification for a method XXX_intf mmm() in XXX, the following method within the stub was generated:
{{{
public XXX_intf mmm() throws uka.karmi.RemoteException {
try {
return (XXX_intf) remoteClientRef.applicationCallObject(0, null);
} catch (...) {
...
}
}
}}}
After the modification, the following method should be generated:
{{{
public XXX_intf mmm() throws uka.karmi.RemoteException {
try {
if (remoteServer != null) {
return (XXX_intf) uka.karmi.ExportPoint.toStub(
((XXX) remoteServer).mmm() );
} else {
return (XXX_intf) remoteClientRef.applicationCallObject(0, null);
}
} catch (...) {
...
}
}
}}}
Parameters and return values are handled according to their types:
* boolean, byte, char, int, float, long, double are passed by value
* String and uka.lang.Immutable are passed by reference
* parameters of interface type that extends uka.karmi.Remote are converted with uka.karmi.ExportPoint.toStub(.)
* all other objects are duplicated.
'''partially-fixed''' since 1.02c.[[br]]
The JavaParty transformation makes the methods of all objects aware of object migration without distinction whether the object can migrate or not. But having the option to migrate a remote object incurs a large overhead of counting the number of methods actually running on a remote object. If the programmer declares a class to be resident by implementing the jp.lang.Resident interface the administration overhead can be saved for objects of this class.
'''fixed''' since 1.02c.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 19 Method of wrong server invoked uka.karmi defect normal closed 2000-11-15T13:50:36+01:00 2000-11-15T13:50:36+01:00 "When two server objects were marshaled in one remote method invocation, a callback method invocation on both server stubs on the remote side was executed on the same server object.
=== Problem ===
Each remote client reference is marshaled with a list of UTID objects identifying the technologies that can be used to communicate with that server. These UTID objects have a reference to the object id that identifies the server. All server objects in the same address space refer to the same list of UTIDs. If two of them are marshaled in the same method invocation they get a common list of UTIDs on the remote side. But the backward reference to the object id only points to the object id of one server object. This object id reference was use when invoking methods on the server.
=== Solution ===
Each remote client reference has also a reference to an object id in addition to the UTID list. Now the object id is used to identify the remote server object in stead of the UTID. See SingleRemoteClientRef.
'''fixed''' since 1.02.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 18 Misleading error message uka.karmi defect normal closed 2001-04-03T11:25:00+02:00 2001-04-03T11:25:00+02:00 "Trying to export a stub for class XXX gives a ClassNotFoundException for a class XXX_KStub_KStub.
=== Solution ===
A RemoteException with the real problem description is thrown.
'''fixed''' since 1.04c.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 17 Missing copy in shortcut call uka.karmi defect normal closed 2000-11-15T13:50:36+01:00 2000-11-15T13:50:36+01:00 "Objects as results of local shortcut calls were not copied in the local technology.
'''fixed''' since 1.01.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 16 Useless error message uka.karmi defect normal closed 2000-11-20T22:44:25+01:00 2000-11-20T22:44:25+01:00 "Crazy error message (NullPointerException) when shipping unexported objects in remote invocations.
'''fixed''' since 1.03d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 15 Transport compatibility problem uka.karmi defect normal closed 2000-11-20T22:44:25+01:00 2000-11-20T22:44:25+01:00 "Class CopySubstitute was not public, could not be deserialized with uka.transport.
'''fixed''' since 1.03d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 11 Default configuration uka.karmi defect normal closed 2000-11-15T13:50:36+01:00 2000-11-15T13:50:36+01:00 "sources/java/rmi/Transport.djava: Default configuration added that is read as resource (/uka/karmi/karmi.properties)
'''fixed''' since 1.00.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 10 Configuration values uka.karmi defect normal closed 2000-11-15T13:50:36+01:00 2000-11-15T13:50:36+01:00 "sources/uka/util/ConfigBundle.java: The iterator returned from getKeys() did advance by calling hasMoreElements() instead of nextElement().
'''fixed''' since 1.00.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 9 Configuration default values uka.karmi defect normal closed 2000-11-15T13:50:36+01:00 2000-11-15T13:50:36+01:00 "In sources/uka/util/ConfigBundle.java the method getConfigString(key, defaultValue) may throw a java.util.MissingResourceException instead of returning the default value. The problem was a possible confusion between java.util.MissingResourceException and uka.util.ConfigEntryMissingError.
=== Solution ===
uka.util.ConfigEntryMissingError is completely superfluous, because java.util.MissingResourceException is a subclass of java.lang.Runtimeexception an has not to be declared, too. Exceptions uka.util.ConfigEntryMissingError and uka.util.ConfigError removed, code cleaned up.
'''fixed''' since 1.00.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 6 Naming class in the uka.karmi package uka.karmi defect normal closed 2000-11-15T13:50:36+01:00 2000-11-15T13:50:36+01:00 "sources/java/rmi/Naming.djava does only compile with preprocessor switch 'PATCH'. UnknownHostException is declared to be thrown as 'UnknownHostException' and thrown as 'java.rmi.UnknownHostException'. If the actual package is not 'java.rmi' these declarations do not reference the same types.
=== Solution ===
prefix 'java.rmi.' removed.
'''fixed''' since 1.00.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 5 Marshaling of ExampleUTID objects uka.karmi defect normal closed 2000-11-15T13:50:36+01:00 2000-11-15T13:50:36+01:00 "sources/uka/karmi/example/ExampleUTID.djava was not ready for fast marshaling.
=== Solution ===
fixed in combination with ticket:3.
'''fixed''' since 1.00.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 4 Marshaling of RemoteClientRef objects uka.karmi defect normal closed 2000-11-15T13:50:36+01:00 2011-08-18T04:25:11+02:00 "Abstract class java.rmi.RemoteClientRef is declared Serializable without declaring it Transportable as well. Because RemoteClientRef has no instance variables that have to be serialized in specialized marshaling routines, the declaration of Serializable has been removed.
'''fixed''' since 1.00.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 2 Redundant name definitions uka.karmi defect normal closed 2000-11-15T13:50:36+01:00 2000-11-15T13:50:36+01:00 "Multiple occurances (5 in 3 files) of the stub and skeleton extension string constants (See also: ticket:1).
=== Files ===
{{{
sources/uka/karmi/rmic/Constants.djava
sources/java/rmi/server/UnicastRemoteObject.djava
sources/java/rmi/server/UnicastRemoteServerRef.djava
}}}
=== Solution ===
Define these constants once in new interface sources/java/rmi/server/Constants.djava
'''fixed''' since 1.00.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karmi 1 Namespace of KaRMI stubs uka.karmi defect normal closed 2000-11-15T13:50:36+01:00 2007-03-30T13:02:23+02:00 "Change the namespace of KaRMI stubs to be different from RMI stubs. This enables the user to experiment with both more easily.
=== Files ===
{{{
sources/uka/karmi/rmic/Constants.djava
}}}
=== Solution ===
Change the extensions to ""_KStub"" for the stub class and ""_KSkel"" for the skeleton class.
'''fixed''' since 1.00.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 213 Optimized collective updates uka.karo 1.08a defect critical boh new 2005-02-04T17:43:19+01:00 2010-07-26T13:22:06+02:00 A collective update on a replicated object that does not employ PartialReplication corresponds to an all-to-all operation in MPI, because each replica must communicate its changes to each other replica. But if a replicated object is partially replicated, changes to one replica are only relevant for a small subset of all replicas. This fact should be used to optimize collective updates for partially replicated objects. hauma
uka.karo 167 Final variables in replicated objects uka.karo 1.08a defect major new 2004-03-25T11:13:14+01:00 2005-02-03T17:26:02+01:00 "Final instance variables never change after the object is constructed. This property is used in replicated objects. Final variables are simply excluded from the update process. This would be fine, if those variables were initialized on all replicas in a consistent manner. But this is not the case, because after construction only the primary replica is initialized. All secondary replicas are allocated uninitialized and wait for an update. Since final variables are excluded from the update process, their state stays inconsistent even after the first update.
=== Evaluation ===
Final variables cannot be updated during the regular update process, because assignments to them are only allowed within their constructor.
=== Evaluation ===
Secondary replicas are created uninitialized, because the constructor in the replicated root class (ReplicatedObject) triggers the creation of the secondary replicas. At this time, the primary replica is not yet completely initialized. The problem could be fixed by delaying the creation of the secondary replicas to the time the construction of the primary replica has completed.
'''todo''' since 1.08a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 223 Difficulties defrosting objects uka.karo 1.09b defect normal hauma new 2005-02-16T12:30:37+01:00 2005-02-16T12:30:37+01:00 "An object can be frozen during a collective or exclusive synchronization according to ticket:222. Since frozen objects are excluded from updates, collective updates can be optimized according to ticket:213.
Unfortunately, defrosting an object is an operation that modifies the state of the replicated object on all machines holding a copy of the frozen object. Therefore, an optimized collective update cannot be used to bring a replicated object with defrosted objects up-to-date. Defrosting must either be restricted to exclusive updates, or a special collective operation must be introduced for object defrosting." hauma
uka.karo 222 Optimized collective updates require frozen objects uka.karo 1.09b defect normal hauma new 2005-02-16T12:23:31+01:00 2005-02-16T12:23:31+01:00 "The replicated root object is present at each rank of a replicated object. Since this could have been modified during a collective update, the underlying communication is always potentially all-to-all. To optimize collective updates effectively according to ticket:213, there must be the possibility to ""freeze"" at some point in time after construction. A frozen object must no longer be modified and is excluded from updates." hauma
uka.karo 219 Missing backup copies for objects transmitted in a CollectiveExchange uka.karo 1.09b defect normal hauma new 2005-02-09T10:31:13+01:00 2005-02-09T10:31:13+01:00 "Refactoring the order of backup creation and reference filtering in [2528] broke CollectiveExchange. Backup copies are now created immediately after creating a patch (directly within the method {{{PatchAdapterImpl.Output.createPatch()}}}). The exchange is done after creating patches to bring the replicated state up to date. If a shared object is transmitted during the exchange operation to a rank, where previously no copy existed, no backup copy is created for that object.
" hauma
uka.karo 215 NaN values in replicated state produce continuous updates uka.karo 1.08a defect normal hauma new 2005-02-08T10:20:26+01:00 2005-02-08T10:27:08+01:00 "The update mechanism used in CollectiveReplication only marshals
updates form one replica to another, only if the actual value in one
replica has changed. This test uses the built-in (==) operator for all
primitive types. Since {{{Double.NaN != Double.NaN}}}, this test
detects always an update for replicated {{{float}}} and {{{double}}}
values that are {{{NaN}}}.
A side effect of this behavior is that {{{NaN}}} values are likely to
dominate changes to replicas of such {{{double}}} or {{{float}}}
variables. After some has set a variable to {{{NaN}}}, it is hard to
override this in a collective update, because each rank generates an
update for its {{{NaN}}} value.
" hauma
uka.karo 208 Redistribution of partially replicated graphs uka.karo 1.08a enhancement normal new 2004-03-25T11:13:14+01:00 2005-03-12T18:30:39+01:00 "With partial replication (see ticket:171), the application may want to change the distribution of single objects or reorganize the distribution of a whole replicated object graph.
'''todo''' since 1.08a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 180 Semantics of collective exchange operations uka.karo 1.08b defect normal reopened 2004-03-25T11:13:14+01:00 2005-02-08T23:14:35+01:00 "The collective exchange (see ticket:177) was originally designed as pure data exchange (without touching the replicated state of the corresponding replicas). But two things might happen:
* The exchanged data may reference parts of the replicated state (by incident).
* The application might use the exchange operation to actively ""migrate"" parts of the replicated state from on rank to another by means of an exchange.
To deal with both cases, during the exchange, data that is unrelated to the replicated object is passed by value as in a regular remote method invocation, while data that was '''already''' part of the replicated object is passed ''by reference'' (by transmitting the corresponding object identifiers and resolving them on the target node to the already existing copy of the object).
This approach causes two semantic problems:
* Exchanging references to replicated data may behave unexpected, because the exchanged data can differ on the sending and receiving side, if the replicated state is currently inconsistent (e.g. in the middle of a collective update operation). The effect is similar when passing a volatile reference from one thread to another, without ensuring that the receiver will see fresh values upon dereferencing.
* Since an exchange operation is meant for exchanging data that is not directly related to the state of a replicated object, it is acceptable that the argument passing semantics depends on the fact, whether a referenced object is part of the replicated graph, or not. But within a temporarily inconsistent replicated object, it is not clear, which object currently belongs to the replicated state and which does not. E.g., an object that is just entered to the replicated graph in a running collective update is at the one hand already referenced form the graph, but not yet registered, because it was not yet detected by an update. Such object would be passed by value, instead of by reference. This will result in unexpected behavior.
=== Solution: Update before exchange ===
Both problems described above can be solved by preventing an exchange operation on a temporarily inconsistent replicated object. If the replicated object is in a consistent state, all ranks have a consistent view to all shared objects. Then, there does not exist a newly created object that is not yet registered at the replicated graph. The only way of preventing an exchange within an inconsistent replicated object is to perform an update before the exchange operation.
=== Evaluation: Non-shared objects are not registered ===
For performance reasons, objects that are not shared between ranks of a replicated object are not registered. If such object takes part in an exchange operation it will be passed by value regardless whether the replicated object is in a consistent state, or not. This limits the exchange operation to shared objects. An exchange may therefore not be used to share an otherwise unshared object. It depends on the application, whether this restricts the usability of the exchange operation. Ensuring that all referenced objects (shared and non-shared) are registered requires traversal of the whole replicated graph during each update and will result in prohibitive cost.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 177 Collective exchange uka.karo 1.08a enhancement normal new 2004-03-25T11:13:14+01:00 2005-02-03T17:25:40+01:00 "The only collective operation introduced in ticket:157 was the collective update. This operation consists of an exchange of concurrent modifications done to a replicated object. In addition to that, an application may need a more basic form of data exchange, without modifying the state of the replicated object. In general, cooperating threads might want to use all collective operations for pure data exchange known from MPI: barrier, broadcast, (all-)scatter, (all-)gather, all-to-all. Even the combined communication/computation operations (all-)reduce, and scan are conceivable.
=== Evaluation ===
Implementing all flavors of MPI-style collective communications is to time consuming. As prove of concept, the most powerful ""all-to-all"" communication should be implemented.
=== Solution ===
A collectively replicated object serves as context for a collective data exchange. Therefore, the base class of replicated objects provides a set of collective methods that are inherited by subclasses. The all-to-all communication is implemented in the {{{Object[] exchange(Object[])}}} method. The caller must provide a list of arguments, one for each rank of the replicated object. The method returns a list of results, one from each rank (data from rank {{{r}}} is stored at index {{{r}}} in the result list). The object at position {{{caller-rank}}} is copied from the argument list to the corresponding index within the result list.
=== Problem ===
The semantic of the exchange operation is problematic. See ticket:180 for details.
'''todo''' since 1.08a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 220 Garbage collection witin repicated object graphs breaks consistency uka.karo 1.09b defect critical hauma closed 2005-02-11T08:57:29+01:00 2005-02-11T15:46:29+01:00 "Immediately after the replicated garbage collector has completely reclaimed the state of an object that was part of a replicated graph (including its identifier), updates to the replicated graph do no longer yield consitent results. Some of the objects are no longer part of the replicated state and become reinserted afterwards. This produces dangling copies of objects that are no longer kept consistent.
" hauma
uka.karo 227 Two replicated object graphs may not have objects in common. uka.karo 1.08a defect major hauma closed 2005-02-23T15:26:59+01:00 2011-09-07T07:45:46+02:00 The problem is described further on the page ConnectedState. hauma
uka.karo 241 Stress test fails for replicated objects uka.karo 1.09c defect normal hauma closed 2005-03-21T14:26:00+01:00 2005-03-21T16:56:37+01:00 "The stress test {{{jp.test.TestStress}}} fails (mostly during collective and exclusive updates) with various error messages (including StreamCorruptedException and BrokenPipe). When enabling magic connection cookies, infrequently illegal codes are received.
" hauma
uka.karo 235 Likely name clashes with autogenerated clone() in Patchable uka.karo 1.09a defect normal hauma closed 2005-02-25T14:23:33+01:00 2005-03-12T18:26:10+01:00 "Patchable declares a public {{{clone()}}} method, which is automatically implemented by a program transformation. This makes name clashes with applicaton-provided {{{clone()}}} methods likely. The method {{{clone()}}} in Patchable should be renamed to {{{flatClone()}}}.
" hauma
uka.karo 226 Low-level API for insider patch creation uka.karo 1.09b defect normal hauma closed 2005-02-21T23:11:36+01:00 2005-02-22T16:12:24+01:00 "Distribution-aware classes (e.g. collective arrays) need custom-tailored routines for patch creation. Patch creation methods for those classes must be able to decide, to which rank a patch is sent and from which rank a patch is currently received. For performance reasons, it may be inadequate for custom patch routines to rely on the high-level PatchOutput interface. Instead, direct access to the underlying marshal streams should be provided.
" hauma
uka.karo 206 Explicitly distributing arrays within a replicated graph uka.karo enhancement normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "If partial replication (see ticket:171) requires to declare the class of an explicitly distributed object to implement a special interface (as described in ticket:205), there is no way to explicitly distribute array objects. Therefore, there should be another way to specify the distribution of an object without requiring its class to be modified. This could be achieved with a distribution API within the replicated object class. After creating an arbitrary object, the application could call {{{distributeTo(Object obj, int[] ranks)}}} to restrict the distribution of {{{obj}}} to the ranks of the replicated object specified by {{{ranks}}}.
=== Solution ===
The specified and actual distribution of objects within a replicated graph are stored explicitly. The distribution is part of the state of a replicated object, and the view to it is kept consistent on all nodes, where a copy of the corresponding object is allocated. To send incremental updates to the distribution, there is also a backup copy of the distribution that can be used to find local modifications by comparing it with the current distribution. This backup copy (that represents the distribution at the start of an update) is also used for deciding about the receivers for a certain patch, see ticket:183.
=== Test ===
{{{
jp.test.TestReplicaDistribution
}}}
=== See also ===
ticket:178
'''implemented''' since 1.08b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 205 Main objects and accompanying objects within a replicated graph uka.karo enhancement normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "When constructing a partially replicated graph as described in ticket:171, the application must be able to specify the distribution of objects in a convenient way. Since there are lots of heterogeneous objects within a replicated graph, one cannot specify the distribution for every object. There are objects, which the application is aware of, and objects that only accompany other objects. Those accompanying objects represent values or private properties of other objects. The application should be able to specify the distribution of the main objects, while the system should find out the proper distribution of accompanying objects automatically.
=== Solution: Distributable and non-distributable objects ===
Main objects, which should be distributed explicitly, could be declared to implement a marker interface {{{uka.patch.Distributable}}}. The application can now attach a distributor to a replicated object that decides about the placement of distributable objects. All non-distributable objects are managed by the runtime system automatically. A non-distributable object is made available to a node, if it is reachable from a distributable object that was distributed to that node.
=== Test ===
{{{
jp.test.TestPartialReplication
}}}
=== See also ===
ticket:206
'''implemented''' since 1.08b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 188 Simple collective barrier() method for replicated objects uka.karo 1.09a enhancement normal closed 2005-01-17T15:56:00+01:00 2005-02-03T17:23:29+01:00 "A collective barrier() method is added to replicated objects. A collective synchronization without modifying the state of a replicated object is equivalent but less efficient than a simple barrier. This barrier implementation is mainly good for experimenting with notification trees with varying fanout to see its effect on the latency of the barrier() call.
=== Test ===
{{{
jp.test.TestReplication#benchBarrier
}}}
'''implemented''' since 1.09b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 183 Superfluous patches for newly marshaled objects uka.karo defect normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "Patches are sent to all ranks that have actually a copy of the corresponding object. If a modified reference is transmitted to a rank, where the target object is not available, this object is marshaled along with the patch. But marshaling an object modifies its distribution. If an object is replicated to more than two ranks, the situation can occur, where within one update an object is marshaled to a target rank and a patch for that object is sent later on to the same rank, where this object is already up to date, because it was marshaled during the same update.
=== Solution ===
The decision whether to send a patch to a certain rank must be based on the state of the distribution that was valid at the beginning of the updated. Fortunately, the distribution is also versioned, and a backup copy of the distribution exists to detect changes in the distribution for sending incremental distribution updates (see ticket:206). This backup copy can also be used to decide about the patch distribution.
'''fixed''' since 1.08b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 182 Distribution specifications may be lost uka.karo defect normal closed 2004-03-25T11:13:14+01:00 2011-01-20T01:58:21+01:00 "The fix for ticket:178 introduced the problem that distribution specifications could be lost. If the corresponding object, for which the distribution was specified, is a non-shared object, it is not entered to the object space and its distribution specification is lost. If the object in question stays non-shared until its death, the behavior is exactly the desired one. But if this object becomes shared later on, because it gets referenced from another shared object, it is treated as if it was distributed to all ranks. Such behavior is problematic and may cause memory leaks.
=== Solution ===
Instead of simply clearing the table with distribution specifications after each update, all specifications can be moved to the object space before updating the distribution.
'''fixed''' since 1.08b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 181 Updates for locally dead objects cause inconsistencies uka.karo defect normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "The solution to garbage collection within a replicate object graph (ticket:207) describes an approach that allows to cope with arriving patches for locally dead objects. Those patches can occur, because an object may die at any time, and the local node may have no chance to announce that it has no longer a copy of a particular object. The solution suggested was to apply an arriving patch for a locally dead object to its surviving backup copy, and only revive the object itself (by cloning its backup copy), if a reference to the object is received that may reenter the object to the reference graph of the replicated object.
Unfortunately, this approach is broken, because the following might (and does) happen: An object {{{A}}} dies locally on node {{{#0}}}, just before node {{{#1}}} sends a patch for this object. This patch is applied on node {{{#0}}} to the surviving backup copy {{{A'}}} of object {{{A}}}. The patch adds a reference to object {{{B}}}, which is new to node {{{#0}}} and is therefore marshaled along with the patch. But the object {{{B}}} contains a reference back to object {{{A}}}. While unmarshaling {{{B}}}, the object {{{A}}} must be revived by cloning its backup copy and reentering this fresh local version of {{{A}}} to the local object table. Unfortunately, this reviving of object {{{A}}} occurs during the application of the patch to its backup copy {{{A'}}}. If the patch contains more state updates than the introduction of the new reference to {{{B}}}, this update is only applied to the backup copy {{{A'}}} of {{{A}}}. This inconsistency on node {{{#0}}} is fixed during the next update and marshaled back to node {{{#1}}}, where a part of the last modification is reverted. Magically, this patch is received from a dead object on node {{{#0}}}.
In combination with merge annotations according to ticket:179, another problem occurs. Since the patch method takes two parameters (the original and its backup copy), both of them pointed to the same object in case of receiving a patch for a locally dead object. If no special care is take when applying incremental updates, the update is applied twice (to the original and its backup copy, which actually point to the same object).
=== Solution: Eagerly reviving objects ===
When eagerly reviving locally dead objects (at the time a patch for them is received), both problems described above will dissappear. But this approach increases the danger of object thrashing.
'''fixed''' since 1.08b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 178 Distributing objects within collective synchronizations uka.karo 1.08b defect normal closed 2004-03-25T11:13:14+01:00 2005-02-03T17:25:26+01:00 "It is not possible to specify the distribution of objects by means described in ticket:206 within collective synchronized regions. The reason is that a call to the {{{distributeTo()}}} API directly enters the object to the object space of the local replica. If multiple threads do that concurrently within a collective synchronized region, then those changes are not merged during the update. This corrupts the consistency of the object spaces of the replicas.
=== Solution: Buffer distribution specifications ===
Objects are now not directly entered into the object space when specifying their distribution. Instead, the specified distribution is stored separately, until the object is inserted into the object space during the next update.
=== Cave: Distribution specifications may be lost ===
If the object is not entered into the object space during the next update, the distribution specification is lost. This may happen, because the object in question is a non-shared object (and is not directly referenced from a shared object) and is therefore not entered into the object space. The buffer with the distribution specifications is cleared after each update to prevent memory leaks.
=== Problem: Distribution specifications may be lost ===
Loosing distribution specifications may have strance effects, if the object in question becomes shared during a following update ticket:182.
'''fixed''' since 1.08b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 172 Relation of uka.patch and uka.transport uka.karo defect normal closed 2004-03-25T11:13:14+01:00 2007-01-17T19:46:47+01:00 "Within the patch protocol, object marshaling is used to transmit references to objects that were added to the replicated object graph. This causes a high dependency between marshaling and patch creation, because object marshaling must reuse object references that are already known on both sides, but must transmit new objects and enter them to the known objects of the replicated object graph.
=== Evaluation: Connection between marshaling and differencing ===
The processes ""object marshaling"" and ""object differencing"" are connected through so called object spaces. An object space is a set of objects, where each object has an identifier assigned to it. An object space consists of a function (ID -> Object) and an optional function (Object -> ID) for identifier lookup. The object marshaling process uses the object space to remember objects that have already been transmitted. This information is used to resolve cyclic object graphs at the receiving side. The object differencing process uses object spaces to build a mapping between corresponding objects in different graphs. This mapping is used to find the matching object for patch application. The mapping is also used to associate a backup copy to each object to find differences.
=== Evaluation ===
At the first glance, object differencing does not require an object marshaling facility, because object marshaling of object x to node B could be simulated by the creation of an uninitialized instance of x.getClass() at B plus sending and applying a patch that describes the difference of x to an uninitialized instance of its class. This does work well just after creating a new object in a replicated object graph, because at this time there is an uninitialized backup copy of x that can be used to compute the difference against. Unfortunately, it might be necessary to transmit x later on, when x and its backup copy are in equal state. This might happen during a redistribution of a partially replicated object graph. At least at this time, regular object marshaling with reference resolution against existing objects of the replicated graph at the target node is necessary. Therefore, an object marshaling facility is useful also for transmission of newly created objects.
'''closed''' since 1.08a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 171 Partial replication uka.karo enhancement normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "A replicated object graph consists of a large amount of objects. Not all of them are required on all nodes. Therefore, fully replicating all objects on all nodes should be avoided. For each node, there is a set of required objects. Typically, these sets overlap. As consequence, there are objects that are required on more than one node, and objects that are required on exactly one node. (Partial) replication should only deal with the first sort of objects.
=== Problem: Relative new objects ===
When introducing a new object into a replicated object graph, this new object has to be transmitted to all nodes where it is required. Without partial replication this occurs exactly once, during the update that created the new object. With partial replication, an object may be found new for some node, even if it was created a long time ago, but now this object is referenced from another object that is replicated to a node, where the first object was not yet replicated to.
=== Solution: Relative new objects ===
A special object space (a so called partitioned object space) deals with relative new objects. A partitioned object space is able to translate object references depending on the target node a reference is marshaled to. It monitors the distribution of objects, remembers whether an object was already marshaled to a certain node.
=== Problem: Interactions with object marshaling ===
When introducing partial replication, the marshaling process must additionally decide, whether to block a reference during transmission. If an object x is not distributed to node A, but it is referenced from object y that is distributed to A, then the reference y.x in the replica of y on node A is null. But at the time, y is transmitted through a marshal stream to node A, the valid reference y.x on the originating node must be replaced by a null reference during marshaling.
=== Solution: Interactions with object marshaling ===
The partitioned object space mentioned above decides whether an object is visible at some node. In case, the partitioning of a replicated graph specifies that a certain subgraph is not replicated to some node, the marshaler that is responsible for the target node transparently replaces those object references with the {{{null}}} reference. The API of object spaces is extended with a {{{isAccepted(int id)}}} method that allows an object space to accept or deny the marshaling of certain object.
=== See also ===
ticket:205, ticket:206, ticket:207, ticket:208
'''implemented''' since 1.08b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 169 Patch creation performance is bad uka.karo 1.08a defect normal closed 2004-03-25T11:13:14+01:00 2005-02-02T23:05:49+01:00 "Creating a patch for a large graph of small objects takes incredible long. A graph of approximately 1024 objects takes on an AMD Athlon XP1900+ with JDK-1.4.2_01-b06 4227.679us +- 16.926us for patch creation, if the graph was '''not''' modified. If a single double value was modified at half the objects, patch creation takes 4405.714us +- 47.754us. Therefore, only 4% of the time is spent for productive work. Simply traversing the graph takes 2709.444us +- 10.123us, which is 60% of the time to create an empty patch. Because each graph node in the benchmark graph has approximately 4 neighbors, the rest of the time seems to be spent checking whether the graph references have been modified.
=== Problem ===
Profiling the patch creation process shows that most of the time is spent resolving object references in hash tables. Such hash table lookups are required at two steps during the patch creation process. First, during each patch creation the object graph is traversed completely to find all currently referenced objects. For each object reference encountered, its object identifier must be searched through a hash table lookup. This identifier is required for finding the backup copy of the current object and for labeling the patch record that is potentially created. The second source of hash table lookups is the change detection of object references. The original and the backup graph are isomorphic. Nodes of the original graph point to objects in the original graph and nodes in the backup graph point to corresponding objects in the backup graph. When comparing an original object with its backup copy, references can not be compared directly. Instead, the object identifier for the referenced object must be found to discover its backup copy. This backup copy can then be compared with the object referenced from the backup of the original object.
=== Solution ===
Instead of traversing the graph during patch creation, the object space can be iterated. This may create patch records for objects that were removed from the replicated graph. But the changes in the reference structure of the graph are detected during the reference comparison of the patch creation phase. Structure changes can now trigger a garbage collection phase that traverses the graph. This optimizes patch creation of graphs whose structure never or only slowly changes.
=== Solution ===
Reference comparison can be sped up by changing the structure of backup objects. Instead of pointing to objects in the backup graph, those objects could point to the corresponding original objects. With this modification, a value comparison of references is sufficient. In exchange, creating the backup copies becomes slightly more complicated. An original object can not simply be clone()d, because the corresponding method in java.lang.Object is protected. One way is to invoke this method reflectively and relying on the convention to declare a public clone() method, when declaring a class Cloneable. Another way would be a deep clone process that resolves all references to their corresponding original values. A deep clone process might be preferably, because all object in the original graph have to be cloned anyway, no reflection is required, and deep clone through serialization/deserialization provides automatic reference traversal for non-transportable objects.
'''todo''' since 1.08a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 165 Deadlock when collective updates produce large patches uka.karo 1.08a defect normal closed 2004-03-25T11:13:14+01:00 2005-02-03T17:26:15+01:00 "Collective update of replicated objects was built with the assumption that each participating thread has to create its patch before being able to apply patches from other participants, because its own patch would otherwise include the early applied patches from the other parties. An additional assumption was that this strategy of patch creation before patch application would maximize concurrency. The first assumption is void, but the second one probably holds for replicated objects that use partial replication (ticket:171). The drawback of the ""patch creation before application"" approach is that the created patches must be buffered, because there are no consumers. All recipients are currently creating their own patches. The first implementation relied on the buffering of the underlying network layer. But this is limited to ""small"" patches. Once the network layer decides to block because of missing consumers, the collective update operation gets stuck in a deadlock.
=== Evaluation ===
The assumption that patches must be created, before other patches can be applied is void, because a patch is always applied to the original object and the corresponding backup copy. Therefore, after a patch has been applied to an already modified object, this patch will not be included in a patch that is created thereafter for the same object. The only restriction is that a patch can not be applied while a patch is created concurrently. This would corrupt the identifier assignments for objects.
=== Evaluation ===
Creating and applying patches on all replicas in a unique order (patch on replica with rank 0 is created/applied first, all other patches follow in rank order) has an additional benefit. The consistency of the replicated object after the collective update does not depend on correct partitioning of the replicated state by the application. Changes made to a replicated object have priorities: Changes on replicas with lower rank have priority over changes on replicas with higher rank.
=== Evaluation ===
Creating and applying patches on all replicas in a unique order may have negative impact on performance, if partial replication (ticket:171) is used. Here, replicas may wait for the application of a patch before creating their own patch. Unfortunately the awaited patch may be very small or empty at all, but its creation may take a non-negligible amount of time, because the same patch is a large one for other replicas.
=== Evaluation ===
Deadlock freeness and replica consistency for now are more valuable than optimal performance.
=== Solution ===
Patches during collective updates are now created and applied in global unique order. Patches for the same replica are applied all by the thread that performs the collective update. To accomplish this, an additional command type for remote invocations has been added to KaRMI. Besides application calls, service calls, and DGC operations, there is now also a so called collective operation. Such a collective operation is never executed by a KaRMI server thread, but delivered to a replicated object that is awaiting the collective operation. The thread that performs the collective operation on the local replica now has control over all connections belonging to the same collective operation.
=== See also ===
ticket:156
'''fixed''' since 1.08a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 163 Patchable object graphs and object replacement does not fit uka.karo defect normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "During patch creation, objects that were newly inserted into a patchable object graph are marshaled into the patch. If the marshaled object is e.g. the root of another patchable object graph, this object is replaced with a corresponding stub during the marshaling process. Without further means, this new stub object is marshaled into the patch as well as added to the original patchable object graph by assigning it an identifier that belongs to the object space of this graph. This has three unwanted effects: First, patch creation adds temporary objects to the patchable graph that are only required to create a wire representation of an original object. Second, if the patch is created for multiple destinations (e.g. for all replicas of a replicated object) the number of created temporary objects is multiplied by the number of created patches, because the object replacement that creates the temporary objects occurs individually for each marshal stream. Third, the original object that triggered the replacement does not get an identifier. But the identifier that was assigned to its replacement gets useless after the current patch is applied. In each subsequent patch that writes a reference to the same original object, another replacement occurs that creates new stubs and adds more temporary objects to the graph.
=== Problem ===
This problem manifests in countless identifier that are assigned within an object space of a replicated object which has references to other replicated objects or references to remote objects. After patch creation, there are also missing objects that are transmitted after the patch, even if full replication is used. The reason for this is that the replacement objects are created for the individual marshal streams, but are all assigned to the global object space of the replicated object. After patch creation, replacement objects are transmitted to those streams that did not yet see them, because the replacements were created for another stream.
=== Solution ===
The solution consists of three parts: First, the protocol of the marshal stream is changed that it does also assign identifiers to original objects that are replaced during marshaling. To accomplish this, object replacement must be announced to the reading side. This change prevents that the original object is replaced again, when written to a future patch. In this case, its assigned identifier is marshaled instead of a newly created stub and directly resolved to the correct object at the reading side. Second, a class of objects is defined that are always passed by value through a marshal stream. No identifier is required for those objects since there is no need for cycle resolution during marshaling them. This class of objects are the immutable ones. Therefore, the semantic of immutable objects was extended to value semantics during marshaling. This requires the additionally property that there is no cycle in an object graph that consists only of immutable objects. Those immutable objects that do not pollute the identifier space of a marshal stream are now good candidates for representing stubs in transit. Third, all KaRMI classes whose objects are part of stubs were declared to have value semantics. With the rule that all objects returned form replaceObject() have to have value semantics, pollution of the identifier space of a patchable object graph can be completely prevented.
'''fixed''' since 1.08a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 157 Replicated objects with collective update uka.karo 1.07h enhancement normal closed 2004-03-25T11:13:14+01:00 2005-02-03T17:26:42+01:00 "Besides regular remote objects, KaRMI now supports replicated objects. A replicated object is created concurrently on a specified set of virtual machines. Creation of a replicated object is issued on a single node and results in a reference to the local replica of the created replicated object. To make the newly created replicated object programmatically known to other nodes, its local replica is passed in remote method invocations. On the remote node, parameters representing replicas on the sending side are resolved to their corresponding local replica on node executing the remote method call. Other than remote objects, replicated objects are always locally available and represented by their local replica. There are no remote invocations on replicated objects, only local regular Java method calls on their local replicas. There are two ways, a replicated object can be used. The first way is exclusive update with possibly multiple observers. In this mode, the replicated object is locked as a whole, updated locally, and the modifications are distributed to all replicas during an exclusive update. The second was is the collective update with multiple concurrent writers. In this mode there have to be as many participating threads as replicas exist for the replicated object. Each thread acquires a lock on its local replica, updates a partition of its state and performs a collective update which merges all changes made by all thread and makes them available at all replicas.
=== See also ===
ticket:156, ticket:177, ticket:179
'''implemented''' since 1.08a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.karo 156 Differencing and patching object graphs uka.karo enhancement normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "There is a new package within the ""uka"" hierarchy that provides the computation of object graphs differences, patch creation from such difference sets and the application of patches to corresponding object graphs. The new package is called ""uka.patch"". The main entry points into this package are the interface Patchable that describes an object that supports differencing and the class PatchAdapter that manages patch creation and application. The implementation of replicated objects heavily depends upon this feature. See ticket:157 for details.
=== See also ===
ticket:157
'''implemented''' since 1.08a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 240 Arrays of anonymous objects are always handled embedded. uka.transport 1.09c defect normal hauma new 2005-03-09T23:54:37+01:00 2005-04-03T14:29:21+02:00 This is a workaround for the problematic ticket:232. The embedded annotation cannot be used within KaRMI source files, but it is required to generate correct marshaling code e.g. for ReplicaStub. hauma
uka.transport 184 Generation of marshaling routines does not respect user-provided implementations uka.transport 1.08b defect major new 2004-03-25T11:13:14+01:00 2005-03-12T18:40:05+01:00 "The JavaParty compiler declares classes transportable and generates appropriate implementations of marshaling methods. Unfortunately, it does not respect user-provided implementations of the Transportable interface. Instead it generates duplicate methods and crashes when compiling generated sources.
=== Test ===
{{{
jp.test.TestStringTransport_SendPackage
}}}
=== Evaluation ===
There should be a possibility to specify user-defined marshaling routines in a more abstract way that is suitable for java.io serialization '''and''' uka.transport mashaling. These user-defined methods should only use the general interfaces java.io.Object{In|Out}put instead of the concrete implementations java.io.Object{In|Out}putStream and uka.transport.{Unm|M}arshalStream." Bernhard Haumacher (haui at haumacher dot de)
uka.transport 250 gjc.v6.RetroTransport: public inner classes make use of variable this$0 in generated code uka.transport 1.07i defect normal hauma new 2005-08-23T14:58:12+02:00 2005-08-23T14:58:12+02:00 "Let us assume we have this code:
{{{
..
public class Outerclass
{
public class InnerClass
{
}
}
}}}
then the gjc.v6.RetroTransport compiler generates the following:
{{{
protected void deepCloneReferences(uka.transport.DeepClone _helper)
throws CloneNotSupportedException
{
this.this$0 = (com.x.Outerclass) _helper.doDeepClone(this.this$0);
}
}}}
This is wrong cause the inner class is independent of outer objects." Burkhard Kuehlert
uka.transport 249 gjc.v6.RetroTransport: final variable is assigned a value in generated method uka.transport 1.07i defect normal hauma new 2005-08-23T14:02:48+02:00 2005-08-23T14:02:48+02:00 "A class has a non static variable, e.g. EMPTY_VALUE which is final:
{{{
..
private final String EMPTY_VALUE = ""-"";
}}}
The code generator generates the following method:
{{{
protected void deepCloneReferences(uka.transport.DeepClone _helper)
throws CloneNotSupportedException
{
super.deepCloneReferences(_helper);
this.EMPTY_VALUE = (java.lang.String) _helper.doDeepClone(this.EMPTY_VALUE);
}
}}}
The javac compiler will stumble across this method, cause a final variable is assigned a value." burkhard.kuehlert@…
uka.transport 236 Remove the interface uka.transport.Transportable uka.transport 1.09c defect normal hauma new 2005-02-28T15:56:25+01:00 2005-03-12T18:37:47+01:00 "The property of being transportable is determined at runtime by checking the availability of a static field {{{TRANSPORT_DESCRIPTOR}}} in the class. This makes the interface {{{Transportable}}} superfluous.
Since, it is not safely possible to automatically promote each serializable class to transportable ones. If the class implements its own marshaling protocol using writeObject() methods, it may be difficult to convert those methods into marshaling methods valid for uka.transport. The property of being transportable is not in all cases inherited to subclasses. Since a subclass of a serializable class that was promoted to a transportable class could declare custom marshaling methods, the subclass can no longer be promoted to a transportable class.
" hauma
uka.transport 232 KaRMI should be compilable with jpc for automatic generation of marshaling routines uka.transport 1.09b defect normal hauma new 2005-02-25T08:01:34+01:00 2005-03-12T18:38:55+01:00 "Currently, KaRMI with uka.transport is compiled in three phases. It is first compiled with javac. This requires to replace all declarations of the {{{Transportable}}} interface with {{{java.io.Serializable}}}. The resulting class files are read with the ""transportc"" retrofitting tool that generates code snippets with implementations of the marshaling methods, which are included into the original source code. In a third phase, the enriched source files are recompiled with javac to produce the transportable class files.
The procedure described above doese not work for classes with marshaling annotations as described in ticket:179 and ticket:231, because they are not understood by javac and therefore not included into the resulting class files. Even if this could be improved with Java 5 meta data annotations, a preliminary solution is to directly use {{{jpc}}} to translate the KaRMI classes which should become transportable. This is necessary, because some of the KaRMI classes depend on the annotations.
" hauma
uka.transport 231 Embedded objects uka.transport 1.09b defect normal hauma new 2005-02-25T07:45:31+01:00 2005-02-25T07:45:31+01:00 "When value mode marshaling is replaced with anonymous objects (see ticket:228), a possibility is required build complex anonymous objects that internally consist of multiple helper objects e.g. arrays (which in turn cannot be declared anonymous, because their class is not extendable). To prevent references to those helper objects from being marshaled ""by reference"", they should be declarable as being embedded into its owner object. In the following example, an anonymous class {{{A}}} internaly consists of an array of references to other objects stored in an array {{{A.r}}}. As well as the refernce to {{{A}}} as the reference to the internal helper array {{{A.r}}} should be marshaled in value mode. Only for the containing references {{{A.r[n]}}}, regular marshaling should apply:
{{{
#!java
class A implements Anonymous {
/** @embedded */
Object[] r = new Object[10];
}
}}}
The {{{@embedded}}} anotation marks the refereced Object {{{A.r}}} as being anonymous in the context of {{{A}}}. This annotation is not restricted to variables of anonymous classes. Also helper objects of regular classes can be embedded (declared anonymous in the context of their owner).
By declaring an object embedded, a class guarantees that the embedded reference is the '''only reference''' to the embedded object (an that this reference '''cannot be {{{null}}}'''). With this guarantee, it should be possible for a JIT compliler to inline the embedded object." hauma
uka.transport 228 Anonymous objects should replace value mode marshaling (non-recursive) uka.transport 1.08a defect normal hauma new 2005-02-24T14:55:46+01:00 2011-05-30T21:50:23+02:00 "The {{{uka.transport}}} marshaling does support value mode marshaling. For objects marshaled in value mode, no cycle resolution is performed. This prevent such (temporary) objects from being inserted into the streams object spaces, which is especially important in the context of replicated objects to keep the set of objects watched for modifications small.
All objects marked with {{{uka.lang.Immutable}}} (and all objects transitively referenced from those objects) were transmitted in value mode. This is problematic, because there are classes that should be transmitted in value mode without extending the value mode to referenced objects.
A new marker {{{uka.lang.Anonymous}}} (see [2833], [2834]) was introduced that guarantees (non-recursively) equivalence of objects and copies. {{{uka.transport}}} should respect this annotation and transmit anonymous objects without inserting them into the stream's object spaces.
" hauma
uka.transport 225 Final variables with initializer in transportable classes uka.transport 1.07h defect normal hauma new 2005-02-21T17:15:54+01:00 2005-02-21T17:35:52+01:00 "A final variable with an initializer (like the following class {{{A}}}) is not allowed to be re-initialized in its constructor. Therefore, the following code is wrong:
{{{
#!java
class A {
final int x = 13;
A() {
x = 42;
}
}
}}}
Unfortunately, the transportable transformation generates such code for final variables with initializers, because those variables are (re-)initialized from within the de-marshaling constructor.
=== Related tickets ===
* ticket:174
* ticket:191
* ticket:166
=== Solution ===
The transportable transformation must replace all initializers of final variables with initialization code in the application constructors.
To simply ignore (not marshal) final variables with initializers is incorrect, because the initializer might produce side-effects or it could yield different results for each newly constructed object:
{{{
#!java
class B {
final long initializationTime = System.currentTimeMillis();
}
}}}
" hauma
uka.transport 74 not accept private classes in retro transport uka.transport 1.04b defect normal new 2001-02-13T19:11:00+01:00 2001-02-13T19:11:00+01:00 "Because transportable classes are required to be public, the RetroTransport generator should complain, if the target class is not declared public. Otherwise the problem is only discovered at runtime.
'''todo''' since 1.04b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 248 Code generator for uka.transport should not emit code for interfaces uka.transport 1.07i defect minor hauma closed 2005-08-20T08:44:56+02:00 2006-02-21T17:53:49+01:00 " * Let us say we have a source folder, with some classes and interfaces. We compile these files with javac.
* Then we compile the generated class-files with the UKA Code Generator: gjc.v6.RetroTransport com.x.myclass1.class com.y.myinterface1.class ..
The compiler creates files called myclass1.h myinterface1.h ..
* We take the content of the *.h files and patch the *.java files in the source folder.
* Now we can compile the java-files with javac, and we are ready.
This is all done with ant, and the problem is, that the last compile
will fail, cause the gjc.v6.RetroTransport generates marshal code for
interfaces, and we add this code with implemented methods to our
interfaces.
My question is, why does the gjc.v6.RetroTransport generate code for
interfaces, as this is always wrong?
" Burkhard Kuehlert via Bernhard Haumacher
uka.transport 193 The restoreAfterUnmarshal() method may observe uninitialized objects uka.transport defect normal closed 2005-01-17T15:56:00+01:00 2011-09-08T07:06:33+02:00 "The package {{{uka.transport}}} supports custom restore methods that are called automatically when an object is unmarshaled (see ticket:162). This method is intended e.g. for initializing transient object state. Unfortunately, the execution of such method may access other objects that are not completely initialized (either the restoreAfterUnmarshal() method may not yet be called on a referenced object, or a referenced object may not even have its references to other objects initialized).
=== Evaluation ===
Obviously, in cyclic graphs, where each object has a custom restoreAfterUnmarshal() method, it is impossible to guarantee that all referenced objects are completely initialized (all restoreAfterUnmarshal() methods are called on the referenced objects) before the restoreAfterUnmarshal() method is called on some object.
=== Evaluation ===
Only with [ticket:174 ticket 174 (non-recursive marshaling)] and [ticket:191 ticket 191 (non-recursive deep cloning)], it might occur that the restoreAfterUnmarshal() method is called on an object that has references to other objects that have still uninitialized references. The only way to circumvent this problem is to add a third pass to the unmarshaling and cloning process that is exclusively responsible for calling the restoreAfterUnmarshal() methods on objects that require it.
=== Solution ===
The restoreAfterUnmarshal() method is now called after unmarshaling or cloning the complete graph on those objects that require it. An object can expect that all objects reachable by ""forward"" references (in marshaling order) are already completely initialized, when the restoreAfterUnmarshal() method is called.
=== Test ===
{{{
uka.test.transport.TestRestore
}}}
'''fixed''' since 1.09b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 192 Final references not supported by non-recursive deep clone uka.transport defect normal closed 2005-01-17T15:56:00+01:00 2011-05-30T21:50:22+02:00 "Final references are simply ignored during the deep clone process.
=== Evaluation ===
Currently deep clone is accomplished through a swallow (built-in) clone followed by an update of all references in the cloned object with clones of themselves. With this approach, correct handling of final references is impossible, since the final reference in the swallow cloned object may no longer be updated.
=== Solution ===
The transformation now introduces a specialized deep clone constructor that replaces the built-in clone() method. This constructor recursively clones final references.
'''fixed''' since 1.09b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 191 Non-recursive deep cloning uka.transport enhancement normal closed 2005-01-17T15:56:00+01:00 2005-01-17T15:56:00+01:00 "Like marshaling (see ticket:174), the process of deeply cloning object graphs should also be non-recursive.
=== Evaluation ===
Like in non-recursive marshaling, final references need special handling when deeply cloning objects (see ticket:192).
'''implemented''' since 1.09b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 175 Stack overflow when marshaling large highly-linked graphs uka.transport defect normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "Recursive marshaling (see ticket:174 for non-recursive marshaling) produces stack overflow exceptions when marshaling large, highly linked data structures. (In a highly linked data structure, nearly every object is reachable from any other object through a chain of references). The problem occurs, because at the time, a reference to a so far unknown object is encountered, this object is recursively marshaled in place with all its referenced objects. Programmatically, this involves a recursive call to the marshaling method. When marshaling a large, highly linked data structure, the recursion is as deep as there are objects in the data structure. This can exceed each constant stack size that is requested at virtual machine startup.
=== Evaluation ===
This is also an issue with regular JDK object serialization. The problem is discussed on the web, but there is no solution other than increasing the stack size of the virtual machine. This does not help for arbitrary large data structures and wastes resources, because the virtual machine stack size applies for all threads.
=== Evaluation ===
Completely non-recursive marshaling cannot be achieved, because final fields require eager initialization (see the evaluation of ticket:174).
=== Solution ===
With an implementation for ticket:174, recursion is restricted to the subgraph of final fields. Even if even the size of such final subgraph could exceed the maximum stack size of the virtual machine, this is much less probable. Additionally, minimal recursive marshaling does provide a viable workaround, if a stack overflow condition should occurr during marshaling. The final subgraph can be easily broken into smaller non-connected subgraphs by removing some final modifiers. This removes the stack overflow condition.
'''fixed''' since 1.08b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 174 Non-recursive marshaling uka.transport enhancement normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "Regular marshaling traverses the target object graph recursively in depth-first order: An object is passed for marshaling to a marshaler. This marshaler inspects the object, marshals primitive data and calls its marshaling method on all objects that are referenced from the initial object. With recursive marshaling, the marshaling of an object is finished, only if all other objects that it references are marshaled completely. Recursive marshaling is problematic, see ticket:175. To avoid these problems, the recursion depth during marshaling should be kept as small as possible.
=== Solution ===
Marshaling is split into three phases: marshaling the reference to an object, marshaling its state (with all included references), and finally marshaling the state of all objects that are (transitively) referenced from the initial object. The wire representation of an object reference consists either of the object type, if the reference is encountered the first time, or of the object identifier that was assigned to the object while its reference was marshaled the first time. Marshaling an object reference that is encountered the first time as the object type, allows at the unmarshaling side to construct an uninitialized object of matching type and use its reference. The initialization of the newly constructed object is completed, when the state for that object is marshaled/unmarshaled later on. This happens after the marshaling/unmarshaling of the initial object is already finished.
=== Problem ===
Only the type of an object may not be sufficient to construct an uninitialized copy at the unmarshaling side. The simplest example are arrays that require additionally the array size to allocate the object. In general, data for all final fields is required to allocate a minimally initialized object of a certain type. Therefore, marshaling an object reference must provide additionally to the type information all data that is necessary to minimally initialize the object at the unmarshaling side.
=== Solution ===
Marshaling of a single object is split into to phases: marshaling the object reference together with all data required to create a corresponding minimally initialized instance, and marshaling all other fields of the object. For more information see the documentation of the uka.transport.Transportable interface.
=== Evaluation ===
The implementation of this feature fixes problems ticket:166, and ticket:175.
=== Evaluation ===
The same problem exists when deeply cloning large highly connected graphs. Cloning should also be done non-recursively, see ticket:191.
'''implemented''' since 1.08b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 170 Value objects referencing non-immutable objects uka.transport defect normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "If a replica references value objects that themselves reference non-immutable objects (such as arrays), these non-immutable objects are added to the object space of the patchable object. This breaks the assumption that creating a patch enters all referenced objects into the patchable object's object space. See PatchAdapterImpl.createBackupCopies().
=== Problem ===
Additional value objects referenced from the non-immutable object described above are not entered into the object space of the stream during marshaling. But such references are encountered when creating backup copies for objects entered during marshaling.
=== Solution ===
A value mode has been introduced to MarshalStream and UnmarshalStream of uka.transport. Marshaling in value mode prevents all objects referenced from an immutable object to be entered into the streams object space. The only exception to this rule are objects that are referenced from default mode immutable objects, if the default mode immutable object is referenced form another non-immutable default mode object that is marshaled in non-value mode. This can be avoided by avoiding default mode marshaling.
'''fixed''' since 1.08a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 162 Call custom restore method after unmarshaling or cloning an object uka.transport enhancement normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "A transportable class may provide a private method named ""restoreAfterUnmarshal()"" that takes no arguments and declares IOException and ClassNotFoundException to be thrown. This method is automatically called during the unmarshaling and deep cloning process of an object of this class. restoreAfterUnmarshal() is called after all state of the corresponding object has been unmarshaled up to the actual class in the class hierarchy. This method can be used for example to restore transient state that is not marshaled along with the object.
=== Problem ===
It is critical that both exceptions (IOException and ClassNotFoundException) are declared for restoreAfterUnmarshal(), because this method is also called after a deep clone of the object. Because the corresponding deep clone method does not throw any of these exceptions, catch clauses have to be generated for them. But it is illegal to declare a catch clause, if the exception might not be thrown wihin the body of the try statement.
=== Problem ===
User code in the custom restoreAfterUnmarshal() method may experience references to uninitialized objects (see ticket:193).
'''implemented''' since 1.08a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 161 Non-contiguous object identifiers uka.transport enhancement normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "By allowing application provided identifiers for marshaled object references, the receiving side can no longer guess the identifier that should be used for the next unmarshaled object. To deal with this problem, the chosen identifiers must be included in the wire protocol.
=== See also ===
ticket:160
'''implemented''' since 1.08a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 160 Pluggable object space for marshal streams uka.transport enhancement normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "The hard-coded creation of identifiers for objects being marshaled should be factored out of Marshal/UnmarshalStream and put into a separate interface called ObjectSpace. This allows the exposure of the wire representation of object references. By plugging a custom object space into a marshal stream, the application can decide which objects of an object graph actually should be marshaled and which objects are already known at the receiving end. With this feature, one can reduce the amount of objects being marshaled and unmarshaled by reusing some of the objects that were marshaled in a previous writeObject() operation.
=== Problem ===
The MarshalStream and UnmarshalStream communicate object references using a common object to identifier mapping. Normally this mapping is built on the sending side while traversing the object graph and reconstructed implicitly at the receiving side whenever a new object is unmarshaled. When using a MarshalStream for marshaling an object patch, in the context of patchable objects (ticket:156), the differencing algorithm and the marshaling must cooperate: If the differencing algorithm finds a reference to an object that was already marshaled in a previous patch, it must create a patch record for this object. If the differencing algorithm finds a reference to a new object, it must marshal the complete object identity.
'''implemented''' since 1.08a.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 159 Extension mechanism for marshaling JDK classes with uka.transport is broken uka.transport defect normal closed 2004-03-25T11:13:14+01:00 2004-03-25T11:13:14+01:00 "The uka.transport protocol of Marshal/UnmarshalStream is extendable with MarshalAdapter classes. With a MarshalAdapter, one can provide a marshaling/unmarshaling routine for a base JDK class that does not implement the transportable interface. Unfortunately, the existing marshal adapters did not register the object at the steams object table during unmarshaling. This caused the wrong objects being read from an UnmarshalStream, if an object was marshaled twice in extension-mode, because the reference to the already unmarshaled object was not found.
=== Evaluation ===
Even worse, there is no API that would allow a MarshalAdapter to register an object during the unmarshaling process. When marshaling an object in extension-mode, the MarshalStream does register the object before invoking the marshal() method of the corresponding MarshalAdapter.
=== Workaround ===
The MarshalAdapter classes now register the object directly at the UnmarshalStream's object table. This is possible, because all MarshalAdapter classes live in the same package as UnmarshalStream.
=== Solution ===
Change the API for extending uka.transport with custom marshal adapters. Split functionality required in a MarshalAdapter's unmarshal() method into a createObject() and a unmarshalReferences() method like in the Transportable interface. This allows assigning an identifier to unmarshaled objects without exposing the Marshal/UnmarshalStream's object identifiers.
'''fixed''' since 1.07g.
'''fixed''' since 1.08a.
" Anders Lindström (anli02 at kth dot se)
uka.transport 127 Stack overflow while closing stream uka.transport defect normal closed 2002-05-31T11:37:00+02:00 2002-05-31T11:37:00+02:00 "While closing a MarshalStream or an UnmarshalStream that was used to marshal a default serializable object an endless recursion occurred. This happened, because during closing the stream, the adapter stream for default serialization was closed recursively. This seems not to be necessary at all.
'''fixed''' since 1.06b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 112 efficient huge primitive arrays uka.transport enhancement normal closed 2001-12-05T12:07:23+01:00 2001-12-05T12:07:23+01:00 "Huge arrays of primitive types can be handled by some transport technologies more efficiently by directly marshaling the array contents in native code. Implement support for handling of huge arrays of primitive type in uka.transport.
=== Evaluation ===
Efficient marshaling of arrays of primitive type is implemented in the ParaStation technology.
'''implemented''' since 1.05d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 111 Deep clone and sub-classing uka.transport defect normal closed 2001-12-05T12:01:54+01:00 2001-12-05T12:01:54+01:00 "The generated deepCloneReferences() method in a sub-class of a transportable class invokes the original deepClone() method of the super-class instead of its deepCloneReferences() method. This causes an infinite recursion and a stack overflow.
'''fixed''' since 1.05c.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 98 array classes uka.transport defect normal closed 2001-09-14T19:01:00+02:00 2001-09-14T19:01:00+02:00 "Sending arrays of objects was not possible because the remote side could not load the array class. While Class.forName() can resolve names like [[Ljava.lang.Object; ClassLoader.loadClass() can't.
=== Solution ===
Use Class.forName() to load the class in the unmarshaling process. Because uka.transport runs as application class this should be no problem.
=== See also ===
ticket:55
'''fixed''' since 1.05b.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 91 Fast deep object clone uka.transport enhancement normal closed 2001-07-16T15:22:27+02:00 2001-07-16T15:22:27+02:00 "In local invocations, the parameters and result values have to be cloned. This deep cloning was implemented by marshaling the object to a stream and reading it back. This is extremely inefficient. In the Transportable mechanism there is now a deep object clone mechanism included. Besides the functionality of marshaling and demarshaling a transportable object now also offers the ability to directly clone the object and all its references.
=== Code ===
{{{
uka.transport.Transportable
}}}
'''implemented''' since 1.05.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 82 base type 'short' missing uka.transport defect normal closed 2001-07-16T15:22:27+02:00 2001-07-16T15:22:27+02:00 "The marshaling package uka.transport does not support classes with member variables of type short.
'''fixed''' since 1.05.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 71 Retrofitter needs JP and KaRMI properties uka.transport defect normal closed 2001-05-07T13:41:12+02:00 2001-05-07T13:41:12+02:00 " * gjc.v6.RetroTransport did extend gjc.v6.JPCompiler instead of gjc.v6.Main.
* the serializable type read from the properties files.
* the RemoteNames class was not aware of being only partially initialized.
'''fixed''' since 1.04d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 62 Retrofit crashes uka.transport defect normal closed 2001-04-03T11:25:00+02:00 2001-04-03T11:25:00+02:00 "NullpointerException in the initialization of RemoteNames from RetroTransport. The properties are not read from the configuration file.
=== Solution ===
RetroTransport must be a subclass of JPC. JPC reads the properties in the processArgs() method.
'''fixed''' since 1.04c.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 14 Object replacement problem uka.transport defect normal closed 2000-11-20T22:44:25+01:00 2000-11-20T22:44:25+01:00 "The object replacement process did ignore the change of the type after an object replacement occurred. Funny results.
'''fixed''' since 1.03d.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 12 Serialization do not transmit ObjectId.utid uka.transport defect normal closed 2000-11-15T13:50:36+01:00 2000-11-15T13:50:36+01:00 "New serialization routines did not marshal the utid member of ObjectId.
=== See also ===
ticket:3
'''fixed''' since 1.00.
" Bernhard Haumacher (haui at haumacher dot de)
uka.transport 3 Signature of transportable objects uka.transport defect normal closed 2000-11-15T13:50:36+01:00 2000-11-15T13:50:36+01:00 "Signature changed for objects that are aware of fast marshaling. The new marshaling (uka.transport) now uses a specialized marshal() method and a constructor, which initializes the object directly from the stream. The package changed to uka.transport to make the classpath patching unnecessary.
=== Files ===
{{{
// objects: the marshaling must be updated.
//
sources/uka/karmi/local/CopySubstitute.djava
sources/uka/karmi/ps/PSUTID.djava
sources/uka/karmi/socket/SocketUTID.djava
sources/uka/karmi/example/ExampleUTID.djava
sources/java/rmi/ObjectId.djava
sources/java/rmi/UTID.djava
sources/java/rmi/server/RemoteStub.djava
// object with special marshaling even if standard implementation
// is used:
sources/java/rmi/SingleRemoteClientRef.djava
// marshal stream that extends the marshal streams
//
sources/uka/karmi/local/CopyMarshalInputStream.djava
sources/uka/karmi/local/CopyMarshalOutputStream.djava
sources/uka/karmi/ps/MarshalInputStream.djava
sources/uka/karmi/ps/MarshalOutputStream.djava
sources/uka/karmi/socket/MarshalInputStream.djava
sources/uka/karmi/socket/MarshalOutputStream.djava
// Generation of objects that conform to the fast marshaling
//
sources/uka/karmi/rmic/Main.djava
// Classes that use fast marshaling features without being
// transportable itself
sources/uka/karmi/ps/PSTechnology.djava
// the build skript
bin/buildKaRMI
}}}
=== Solution ===
Abbreviations defined in include.h for ObjectOutputStream, ObjectInputStream and Serializable. Changed the the stream classes to use these abbreviations.
The transportable objects need further updates. A new macro packages sources/include/marshal.h is used to generate general marshaling and unmarshaling methods in context of inheritance and abstract classes.
The stub-/skeleton generator is outdated because it's now directly integrated in GJ for ease of use. Therefore the transformation in sources/uka/karmi/rmic/Main.djava was not updated.
'''fixed''' since 1.00.
" Bernhard Haumacher (haui at haumacher dot de)