[ https://issues.jboss.org/browse/AS7-1932?page=com.atlassian.jira.plugin.s... ] Jason Greene updated AS7-1932: ------------------------------ Priority: Blocker (was: Major) -- 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

[ 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

[ https://issues.jboss.org/browse/AS7-1932?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on AS7-1932: ----------------------------------- Status update - A major part of this implementation was completed and merged upstream yesterday https://github.com/jbossas/jboss-as/pull/707. There are few things related to connection option configurations that we have been discussing over IRC and how better to handle them, but at this moment the major task of allowing a outbound connection to be created from the remoting subsystem configurations, has been accomplished. -- 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

[ https://issues.jboss.org/browse/AS7-1932?page=com.atlassian.jira.plugin.s... ] Brian Stansberry resolved AS7-1932. ----------------------------------- Resolution: Done Resolving based on previous comments and the merge of https://github.com/jbossas/jboss-as/pull/72. -- 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