[11:51:28 CST(-0600)] <jwennmacher> EricDalquist: I wanted to get your input on something before I make the change.
[11:51:34 CST(-0600)] <EricDalquist> ok
[11:52:13 CST(-0600)] <jwennmacher> I've completed the changes for UP-3654 bundling CalendarPortlet, along with db schema creation and data import into uPortal.
[11:52:51 CST(-0600)] <EricDalquist> awesome
[11:52:54 CST(-0600)] <EricDalquist> this is using the new plugin?
[11:53:45 CST(-0600)] <jwennmacher> The new maven lifecycles are independent of the default lifecyles (I tried to require them to spawn a dependency upon package but it wouldn't work) to insure a change to a property file is reflected in the db-init or data-import execution. We can work around this by simply adding the lifecycle goal; e.g. mvn package db-init
[11:53:48 CST(-0600)] <jwennmacher> yes
[11:54:13 CST(-0600)] <EricDalquist> sounds good
[11:55:09 CST(-0600)] <jwennmacher> I ran some quick tests. If both db-init and data-import include package as a predecessor goal, the execution time is around 4 min 33 sec to do ant initdb. If I remove the package dependencies the execution time is around 62 seconds.
[11:55:26 CST(-0600)] <EricDalquist> yeah
[11:55:34 CST(-0600)] <EricDalquist> that is probably fine
[11:55:44 CST(-0600)] <jwennmacher> Though it is a nuisance, I think we should have dbinit invoke package (twice) just for proper dependency resolution.
[11:56:00 CST(-0600)] <EricDalquist> ok
[11:57:07 CST(-0600)] <jwennmacher> OK just wanted to verify you didn't see it as a nuisance. I don't like the idea of someone pulling down a quickstart version and waiting forever to do the build if there is marginal value in adding big chunks of time.
[11:57:30 CST(-0600)] <EricDalquist> yeah, at least for now I think it is ok
[11:57:38 CST(-0600)] <EricDalquist> this will likely take a few iterations to really get tuned
[11:57:49 CST(-0600)] <EricDalquist> I'll see if I can take a look soonish at the changes
[11:57:58 CST(-0600)] <EricDalquist> this week is mostly meetings sadly 
[11:58:27 CST(-0600)] <jwennmacher> OK. For now I'm also not forcing maven.test.skip=true. It doesn't really make much difference. There's only one portlet doing tests (and the file is missing so it's throwing an error 
).
[11:58:58 CST(-0600)] <EricDalquist> ok
[11:59:19 CST(-0600)] <jwennmacher> Cool. Sad to hear about the meetings
[11:59:43 CST(-0600)] <jwennmacher> one other question. I was just starting to look at this but you may know off the top of your head.
[12:01:07 CST(-0600)] <jwennmacher> When you run the db-related ant commands the resulting vm attempts to use jgroups and execution generates error messages that are confusing unless you know what's going on. I was thinking during db operations the execution should not attempt to launch jgroups. Is there an easy way to disable that?
[12:01:29 CST(-0600)] <EricDalquist> but it should
[12:01:34 CST(-0600)] <EricDalquist> well
[12:01:35 CST(-0600)] <EricDalquist> kinda
[12:01:37 CST(-0600)] <jwennmacher> why?
[12:01:47 CST(-0600)] <EricDalquist> what if I'm doing a CLI import of data in prod
[12:01:57 CST(-0600)] <EricDalquist> I really would like my imported data to show up immediately
[12:02:02 CST(-0600)] <EricDalquist> and not when the caches expire
[12:02:33 CST(-0600)] <jwennmacher> so what is the jgroups doing? I haven't looked into what it is caching.
[12:02:47 CST(-0600)] <EricDalquist> it is the cache invalidation messaging system
[12:02:55 CST(-0600)] <EricDalquist> so we use ehcache for caching
[12:03:18 CST(-0600)] <EricDalquist> and if you look in there about 70% of the caches are configured to do invalidation based replication via jgroups
[12:03:46 CST(-0600)] <EricDalquist> so if serverA does a "PortletDefinitionCache".put(32, portletDef) - which is kind of what hibernate does for us
[12:04:08 CST(-0600)] <EricDalquist> a message gets sent out via jgroups to all of the servers saying "remove key 32 from PortletDefinitionCache"
[12:04:48 CST(-0600)] <EricDalquist> what we should look at is hiding/improving the error message on the CLI if the jgroups_ping table is missing
[12:04:58 CST(-0600)] <EricDalquist> that table is how servers/instances find each other
[12:05:17 CST(-0600)] <EricDalquist> when a uportal instance starts it writes its network address info into that table
[12:05:42 CST(-0600)] <EricDalquist> allowing for the jgroups peer discovery mechanism to work without deployers having to futz with network topology BS
[12:40:11 CST(-0600)] <jwennmacher> Sorry I'm back. That makes sense.
[12:41:29 CST(-0600)] <EricDalquist> no problem
[12:41:36 CST(-0600)] <jwennmacher> In my case I'm not sure the issue is the UP_JGROUPS_PING table in the CLI data-import execution. I see java.lang.SecurityException: Authentication failed in the jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:156) causing connecting to channel "null" failed. I don't see the CLI's member address in the table (though it may have been removed during shutdown). Is mine likely due to having both uPortal
[12:42:14 CST(-0600)] <EricDalquist> huh
[12:43:53 CST(-0600)] <dearbin> hi
[12:44:58 CST(-0600)] <jwennmacher> EricDalquist: http://pastebin.com/ydXmcH57
[12:45:30 CST(-0600)] <jwennmacher> May be due to line 19 - that just popped out at me
[12:45:31 CST(-0600)] <EricDalquist> do you have another portal instance running against the same db?
[12:45:36 CST(-0600)] <jwennmacher> yes
[12:45:42 CST(-0600)] <jwennmacher> dev machine
[12:45:51 CST(-0600)] <EricDalquist> are they running the same codebase?
[12:45:55 CST(-0600)] <jwennmacher> yes
[12:46:07 CST(-0600)] <EricDalquist> weird
[12:46:15 CST(-0600)] <jwennmacher> so try it with uPortal stopped?
[12:46:18 CST(-0600)] <EricDalquist> yeah
[12:46:22 CST(-0600)] <EricDalquist> just curious what happens