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

[ https://issues.jboss.org/browse/AS7-1932?page=com.atlassian.jira.plugin.s... ] 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(a)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"/> <!-- Allows the entire uri to be specified --> (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(a)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"/> <!-- remote: is implied by the element --> (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@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@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} -- 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