[jboss-jira] [JBoss JIRA] (AS7-1932) Remoting outbound connection service

Mon Nov 14 11:45:41 EST 2011

    [ https://issues.jboss.org/browse/AS7-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642611#comment-12642611 ] 

jaikiran pai commented on AS7-1932:
-----------------------------------

For reference, this is what we are planning to do:

{quote}
(09:47:48  IST) Jaikiran: dmlloyd: hey got a few minutes for discussing the AS7-1934 requirements
(09:47:50  IST) Jaikiran: ?
(09:47:50  IST) jbossbot: jira [AS7-1934] EJB client context configuration and management ops [Open (Unresolved) Sub-task, Blocker, jaikiran pai] https://issues.jboss.org/browse/AS7-1934
(09:48:32  IST) kpiwko_afk is now known as kpiwko
(09:49:13  IST) dmlloyd: sure
(09:49:47  IST) Jaikiran: a part of it ties into AS7-1932
(09:49:49  IST) jbossbot: jira [AS7-1932] Remoting outbound connection service [Open (Unresolved) Sub-task, Blocker, Unassigned] https://issues.jboss.org/browse/AS7-1932
(09:50:03  IST) dmlloyd: yeah there's two pieces
(09:50:19  IST) dmlloyd: basically we first need a way to configure outbound connections in the remoting subsystem configuration
(09:50:53  IST) dmlloyd: they need to be named, and have some base set of configuration parameters to facilitate authentication (think data sources) as well as configuring the socket itself
(09:51:14  IST) dmlloyd: the connections would be established in the context of a source endpoint so they would reside within the endpoint configuration
(09:51:41  IST) dmlloyd: then our EJB client configuration in the EJB subsystem would declare client contexts and have a listing of connections to associate with them
(09:52:36  IST) dmlloyd: an important note though - the connection service lifecycle cannot be tied to the connection lifecycle
(09:52:38  IST) Jaikiran: so ultimately the deployment descriptor would just be a named ref to that connections
(09:52:45  IST) dmlloyd: right
(09:53:02  IST) Jaikiran: isn't it the other way round?
(09:53:16  IST) dmlloyd: it's both ways around
(09:53:23  IST) Jaikiran: i mean the connection is destroyed on service destroy?
(09:53:25  IST) dmlloyd: a service lifecycle cannot be controlled by external factors
(09:53:41  IST) dmlloyd: so it can't wait for the connection to be up before starting for example
(09:53:47  IST) dmlloyd: and killing the connection cannot bring down the service
(09:54:07  IST) Jaikiran: oh ok i see what you mean
(09:54:25  IST) Jaikiran: so typically, the named ref dependency doesn't guarantee a connection that is UP
(09:54:39  IST) dmlloyd: right
(09:54:55  IST) dmlloyd: we need a way to get a connection from the ref if it's up - probably best to return an IoFuture<Connection> always
(09:55:05  IST) dmlloyd: the connection is either up or in the process of being created/restored
(09:55:21  IST) dmlloyd: and anything which uses it has to be able to go back for a new connection in the event of a failure
(09:55:38  IST) dmlloyd: this will take some thinking when it comes to EJBReceiver since we don't want the EJBReceiver disappearing
(09:55:47  IST) dmlloyd: also, we should have a way to designate a client context as the "default" which is applied to deployments if none is specified for that deployment
(09:55:55  IST) dmlloyd: (once we're at that part)
(09:56:08  IST) lfryc [~lfryc at cst-prg-121-2.cust.vodafone.cz] entered the room.
(09:56:35  IST) Jaikiran: although we don't "configure" the default context we do have the necessary setup ready to allow that default to be made available to the deployments currently
(09:56:47  IST) stliu left the room (quit: Quit: Leaving).
(09:57:11  IST) Jaikiran: btw, i was looking at the remoting subsystem xsd and it appears that the source endpoint is just 1?
(09:57:24  IST) Jaikiran: i mean all connections would thus be in the scope of the endpoint?
(09:58:00  IST) dmlloyd: yeah I'm not sure how it's set up, but one endpoint per VM is a reasonable policy
(09:58:23  IST) Jaikiran: ok
(09:58:41  IST) Jaikiran: in terms of specifying the destination for those connections
(09:58:56  IST) Jaikiran: i believe we can rely on the outbound-socket-binding support that we added recently
(09:59:04  IST) Jaikiran: which allows for specifying a host and a port
(09:59:16  IST) Jaikiran: is there more that needs to be considered?
(09:59:17  IST) dmlloyd: yes and no - remoting accepts a URI for the destination
(09:59:34  IST) dmlloyd: which includes protocol as well, and basically supports anything a URI supports
(09:59:57  IST) dmlloyd: for example, "local:" is a valid destination
(10:00:05  IST) Jaikiran: so the outbound-client-socket would just be one type of the destination then
(10:00:12  IST) dmlloyd: at some point "http:" may be as well
(10:00:46  IST) dmlloyd: yeah we'd need some way of referencing it
(10:01:25  IST) dmlloyd: e.g. "theproto://#{host}:#{port}/blah?foo"
(10:01:31  IST) dmlloyd: which is really ugly :)
(10:01:36  IST) dmlloyd: but I can't think of anything better
(10:01:43  IST) dmlloyd: maybe bstansberry has a thought
(10:01:44  IST) Jaikiran: i was thinking a bit like:
(10:02:53  IST) Jaikiran: <choice>
(10:02:53  IST) Jaikiran:  <uri type = "string"/> 
(10:02:53  IST) Jaikiran:  <outbound-socket-binding-ref name="blah" uri-scheme="remote"/>
(10:02:53  IST) Jaikiran:  </choice>
(10:02:53  IST) Jaikiran:  
(10:02:58  IST) Jaikiran: or something along those lines
(10:03:21  IST) dmlloyd: that could work
(10:03:33  IST) dmlloyd: you could possibly be more specific:
(10:03:39  IST) sguilhen1 left the room.
(10:03:51  IST) sguilhen1 [~sguilhen at 189.78.3.181] entered the room.
(10:04:10  IST) bstansberry: re: "theproto://#{host}:#{port}/blah?foo"
(10:04:19  IST) sguilhen1 is now known as sguilhen
(10:04:24  IST) dmlloyd: <connect-uri value="xxx"/> or <connect-remote binding="source" target="remote"/> 
(10:04:28  IST) dmlloyd: or <connect-local/>
(10:04:32  IST) sguilhen left the room (quit: Changing host).
(10:04:32  IST) sguilhen [~sguilhen at redhat/jboss/sguilhen] entered the room.
(10:04:33  IST) bstansberry: there's a JIRA for creating system properties from socket-binding stuff
(10:04:44  IST) bstansberry: so those could be used in such a syntax
(10:04:50  IST) dmlloyd: okay, that's an option too then
(10:04:51  IST) bstansberry: ugly!!!!
(10:04:54  IST) dmlloyd: :D
(10:04:57  IST) Jaikiran: :)
(10:05:04  IST) tdiesler [~tdiesler at redhat/jboss/tdiesler] entered the room.
(10:05:05  IST) mode (+v tdiesler) by ChanServ
(10:05:13  IST) bstansberry: I think we'd need to make system-property services though
(10:05:25  IST) bstansberry: so the dependency crap could be done correctly
(10:05:30  IST) bstansberry: UGLY!!!!
(10:06:18  IST) bstansberry: dmlloyd: your examples above sound much better ;)
{quote}

> Remoting outbound connection service
> ------------------------------------
>
>                 Key: AS7-1932
>                 URL: https://issues.jboss.org/browse/AS7-1932
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Remoting
>            Reporter: David Lloyd
>            Assignee: jaikiran pai
>            Priority: Blocker
>             Fix For: 7.1.0.Beta1
>
>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira