You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2007/03/09 09:16:24 UTC
[jira] Created: (JCR-781) RMI: Allow custom socket factories
RMI: Allow custom socket factories
----------------------------------
Key: JCR-781
URL: https://issues.apache.org/jira/browse/JCR-781
Project: Jackrabbit
Issue Type: New Feature
Components: rmi
Reporter: Jukka Zitting
Assigned To: Jukka Zitting
Priority: Minor
The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-781) RMI: Allow custom socket factories
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489244 ]
Ate Douma commented on JCR-781:
-------------------------------
Damn, I described the differences incorrectly, it should be:
Implicit socket factories:
return exportObject(obj, new UnicastServerRef(port));
Explicit custom socket factories:
return exportObject(obj, new UnicastServerRef2(port, csf, ssf))
> RMI: Allow custom socket factories
> ----------------------------------
>
> Key: JCR-781
> URL: https://issues.apache.org/jira/browse/JCR-781
> Project: Jackrabbit
> Issue Type: New Feature
> Components: rmi
> Reporter: Jukka Zitting
> Assigned To: Jukka Zitting
> Priority: Minor
> Fix For: 1.3
>
>
> The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-781) RMI: Allow custom socket factories
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting resolved JCR-781.
-------------------------------
Resolution: Fixed
Fix Version/s: 1.3
Initial support for custom socket factories implemented in revision 526707.
The RemoteAdapterFactory interface now contains methods getPort(), getClientSocketFactory(), and getServerSocketFactory() that are used when initializing the UnicastRemoteObject base class. The default implementation in ServerAdapterFactory has javabean setters for customizing the values, and defaults to the anonymous port and the default RMI socket factories.
> RMI: Allow custom socket factories
> ----------------------------------
>
> Key: JCR-781
> URL: https://issues.apache.org/jira/browse/JCR-781
> Project: Jackrabbit
> Issue Type: New Feature
> Components: rmi
> Reporter: Jukka Zitting
> Assigned To: Jukka Zitting
> Priority: Minor
> Fix For: 1.3
>
>
> The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-781) RMI: Allow custom socket factories
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-781:
------------------------------
Fix Version/s: (was: 1.3)
I reverted the custom socket factory support in revision 529906 based on concerns explained above.
Let's look for an alternative solution to be included in a later Jackrabbit release.
> RMI: Allow custom socket factories
> ----------------------------------
>
> Key: JCR-781
> URL: https://issues.apache.org/jira/browse/JCR-781
> Project: Jackrabbit
> Issue Type: New Feature
> Components: rmi
> Reporter: Jukka Zitting
> Assigned To: Jukka Zitting
> Priority: Minor
>
> The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-781) RMI: Allow custom socket factories
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489217 ]
Ate Douma commented on JCR-781:
-------------------------------
Jukka,
As result of this change the JCR-RMI server is no longer working for us.
We now get the following exception when trying to retrieve the repository from a client:
java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: sun.rmi.transport.proxy.RMIMasterSocketFactory
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at java.rmi.Naming.lookup(Naming.java:84)
at org.apache.jackrabbit.rmi.client.ClientRepositoryFactory.getRepository(ClientRepositoryFactory.java:86)
The UnicastRemoteObject (parent class of ServerObject) uses the UnicastServerRef2 when initialized with a RMIClientSocketFactory and RMIServerSocketFactory, instead of using the UnicastServerRef as before your change.
Somehow, this now results in breaking down the RMI transport when using the RMISocketFactory.getDefaultSocketFactory() for the RMIClientSocketFactory and RMIServerSocketFactory.
How did you test this new configuration, e.g. which SocketFactories did you use?
We've tested this out with both Java 1.4.2 and Java 1.5 on both Windows and Linux, using the default RMI socket factories, all with the same result :(
Right now, we are forced to fall back to the "old" solution from before your changes to get things running again.
Could you please provide some guidance how we might solve this so we can again move forward to the latest version?
Regards,
Ate
> RMI: Allow custom socket factories
> ----------------------------------
>
> Key: JCR-781
> URL: https://issues.apache.org/jira/browse/JCR-781
> Project: Jackrabbit
> Issue Type: New Feature
> Components: rmi
> Reporter: Jukka Zitting
> Assigned To: Jukka Zitting
> Priority: Minor
> Fix For: 1.3
>
>
> The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-781) RMI: Allow custom socket factories
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489242 ]
Ate Douma commented on JCR-781:
-------------------------------
To make a little more clear what seems to be the problem:
The new "default" behavior of new ServerAdapterFactory().getRemoteRepository(repo) without explicitely configuring a custom RMIClientSocketFactory and RMIServerSocketFactory leads to different (and for us failing) behavior compared to the earlier implicit setup where you couldn't specify custom socket factories.
And the difference comes from how the UnicastRemoteObject parent of org.apache.jackrabbit.rmi.server.ServerObject creates the Remote object.
Implicit custom socket factories:
return exportObject(obj, new UnicastServerRef(port));
Explicit custom socket factories:
return exportObject(obj, new UnicastServerRef2(port, csf, ssf))
Ate
> RMI: Allow custom socket factories
> ----------------------------------
>
> Key: JCR-781
> URL: https://issues.apache.org/jira/browse/JCR-781
> Project: Jackrabbit
> Issue Type: New Feature
> Components: rmi
> Reporter: Jukka Zitting
> Assigned To: Jukka Zitting
> Priority: Minor
> Fix For: 1.3
>
>
> The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCRRMI-4) RMI: Allow custom socket factories
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCRRMI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCRRMI-4:
-------------------------------
Description: The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory.
> RMI: Allow custom socket factories
> ----------------------------------
>
> Key: JCRRMI-4
> URL: https://issues.apache.org/jira/browse/JCRRMI-4
> Project: Jackrabbit JCR-RMI
> Issue Type: New Feature
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Priority: Minor
>
> The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-781) RMI: Allow custom socket factories
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489403 ]
Ate Douma commented on JCR-781:
-------------------------------
Thanks for the quick response.
We can use the latest from the trunk again :)
Regards,
Ate
> RMI: Allow custom socket factories
> ----------------------------------
>
> Key: JCR-781
> URL: https://issues.apache.org/jira/browse/JCR-781
> Project: Jackrabbit
> Issue Type: New Feature
> Components: rmi
> Reporter: Jukka Zitting
> Assigned To: Jukka Zitting
> Priority: Minor
> Fix For: 1.3
>
>
> The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Moved: (JCRRMI-4) RMI: Allow custom socket factories
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCRRMI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting moved JCR-781 to JCRRMI-4:
----------------------------------------
Component/s: (was: jackrabbit-jcr-rmi)
Description: (was: The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory.)
Workflow: no-reopen-closed, patch-avail (was: jira)
Key: JCRRMI-4 (was: JCR-781)
Project: Jackrabbit JCR-RMI (was: Jackrabbit)
> RMI: Allow custom socket factories
> ----------------------------------
>
> Key: JCRRMI-4
> URL: https://issues.apache.org/jira/browse/JCRRMI-4
> Project: Jackrabbit JCR-RMI
> Issue Type: New Feature
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Priority: Minor
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (JCR-781) RMI: Allow custom socket factories
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting reopened JCR-781:
-------------------------------
Hmm, you're right. The problem doesn't seem to be the server ref object, but rather the default socket factory instance in the JVM not being serializable. I originally added code to explicitly use the default socket factory in case one hasn't been specified to avoid potential NullPointerExceptions from the UnicastRemoteObject implementation.
I removed the explicit checks in revision 529491, which seems to do the trick for at least the Sun RMI classes, but I'm not too happy about the potential NPE threat, so I might just revert back to original behaviour and revisit this issue for Jackrabbit 1.4.
The main problem with the current implementation is that there is no easy way to select the superclass constructor used by ServerObject to initialize the UnicastRemoteObject parent. A better solution would probably be to not use UnicastRemoteObject as the parent. Instead we should perhaps make ServerObject extend the Remote interface, and use explicit exportObject() calls when doing the RMI bindings.
> RMI: Allow custom socket factories
> ----------------------------------
>
> Key: JCR-781
> URL: https://issues.apache.org/jira/browse/JCR-781
> Project: Jackrabbit
> Issue Type: New Feature
> Components: rmi
> Reporter: Jukka Zitting
> Assigned To: Jukka Zitting
> Priority: Minor
> Fix For: 1.3
>
>
> The current JCR-RMI server classes always use the default RMI socket factory. Provide a mechanism for specifying a custom socket factory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.