Tuesday, 2015-12-15

*** jcrossley3 is now known as jcrossley3-away05:14
*** deadghost <deadghost!~deadghost@> has joined #immutant05:31
*** xeqi <xeqi!uid81119@gateway/web/irccloud.com/x-bjexyarhdclbfgob> has quit IRC (Quit: Connection closed for inactivity)07:28
*** deadghost <deadghost!~deadghost@> has quit IRC (Ping timeout: 272 seconds)07:53
*** deadghost <deadghost!~deadghost@> has joined #immutant10:27
*** qwerty_nor <qwerty_nor!~Thunderbi@> has joined #immutant10:29
*** deadghost <deadghost!~deadghost@> has quit IRC (Ping timeout: 240 seconds)10:31
*** deadghost <deadghost!~deadghost@> has joined #immutant10:43
*** mgoldmann|away is now known as mgoldmann11:03
*** deadghost <deadghost!~deadghost@> has quit IRC (Read error: Connection reset by peer)11:11
*** astalotte <astalotte!~sylazento@n112119195016.netvigator.com> has joined #immutant11:36
*** qwerty_nor <qwerty_nor!~Thunderbi@> has quit IRC (Ping timeout: 240 seconds)12:15
*** qwerty_nor <qwerty_nor!~Thunderbi@> has joined #immutant12:16
*** qwerty_nor <qwerty_nor!~Thunderbi@> has quit IRC (Remote host closed the connection)12:22
*** qwerty_nor <qwerty_nor!~Thunderbi@> has joined #immutant12:23
*** qwerty_nor <qwerty_nor!~Thunderbi@> has quit IRC (Remote host closed the connection)12:26
*** qwerty_nor <qwerty_nor!~Thunderbi@> has joined #immutant12:27
*** lance|afk is now known as lanceball13:18
*** deadghost <deadghost!~deadghost@> has joined #immutant13:39
*** bbrowning_away is now known as bbrowning13:59
*** jcrossley3-away is now known as jcrossley314:04
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has joined #immutant14:20
*** jcrossle_ <jcrossle_!~user@71-90-202-1.dhcp.stls.mo.charter.com> has joined #immutant14:32
*** jcrossley3 <jcrossley3!~user@71-90-202-1.dhcp.stls.mo.charter.com> has quit IRC (Ping timeout: 240 seconds)14:36
*** jcrossle_ is now known as jcrossley314:40
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 256 seconds)14:42
*** astalotte <astalotte!~sylazento@n112119195016.netvigator.com> has quit IRC (Quit: Leaving...)14:43
*** bobmcw <bobmcw!~bobmcw@redhat/jboss/bobmcw> has quit IRC ()15:20
*** bobmcw <bobmcw!~bobmcw@va-67-233-86-120.dhcp.embarqhsd.net> has joined #immutant15:27
*** bobmcw <bobmcw!~bobmcw@va-67-233-86-120.dhcp.embarqhsd.net> has quit IRC (Changing host)15:27
*** bobmcw <bobmcw!~bobmcw@redhat/jboss/bobmcw> has joined #immutant15:27
*** deadghost <deadghost!~deadghost@> has quit IRC (Ping timeout: 272 seconds)16:36
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has joined #immutant17:00
*** projectodd-ci <projectodd-ci!~PircBotx@ec2-54-81-247-237.compute-1.amazonaws.com> has quit IRC (Ping timeout: 250 seconds)17:16
*** projectodd-ci <projectodd-ci!~PircBotx@ec2-54-145-107-102.compute-1.amazonaws.com> has joined #immutant17:30
*** implicit-lozenge <implicit-lozenge!32fe4151@gateway/web/freenode/ip.> has joined #immutant17:46
*** bbrowning is now known as bbrowning_away17:49
*** jcrossle_ <jcrossle_!~user@71-90-202-1.dhcp.stls.mo.charter.com> has joined #immutant17:58
*** jcrossley3 <jcrossley3!~user@71-90-202-1.dhcp.stls.mo.charter.com> has quit IRC (Ping timeout: 255 seconds)18:00
*** jcrossle_ is now known as jcrossley318:07
*** lanceball is now known as lance|afk18:20
*** kungi <kungi!kungi@hell.kungi.org> has left #immutant ("WeeChat 1.0")18:34
*** jcrossley3 is now known as jcrossley3-away18:39
*** bbrowning_away is now known as bbrowning18:50
*** jbott <jbott!supybot@nat/redhat/x-tdjlnbpbuiojizrf> has joined #immutant19:16
*** danielglauser <danielglauser!~danielgla@> has joined #immutant19:17
*** richardh <richardh!d06904fc@gateway/web/freenode/ip.> has joined #immutant19:21
richardhHello. Total Immutant noob here. (And JBoss and Java noob for that matter -- especially enterprise-level)19:22
richardhTrying to get two apps to talk to each other over a queue inside Wildfly.19:23
richardhHaving a lot of trouble figuring out how to get Wildfly to authenticate the client.19:23
richardhI've read more Java enterprise-related acronyms I've never seen before today than I have in my life.19:24
tcrawleyrichardh: howdy!19:25
tcrawleyare both apps inside the same wildfly instance?19:25
richardhQuick question, just so I can get started: How to disable security entirely?19:25
richardh@tcrawley Yes, both apps are inside one Wildfly instance. They start up fine.19:25
richardhI found the following on some HornetQ docs: "To disable security completely simply set the security-enabled property to false in the hornetq-configuration.xml file"19:26
richardhBut I don't have that file anywhere19:26
tcrawleyin that case, security shouldn't matter at all - both apps would talk to HQ internally, which should bypass all that19:26
richardhAlso, I got the queue running fine, with the two apps talking to each other, outside Wildfly. So i got that going for me.19:27
tcrawleywhat does your publish code look like?19:27
richardh(def port (wildfly/messaging-remoting-port))19:28
richardh(def ctx-map {:host "localhost", :port port})19:28
tcrawleyah, when inside the container, you don't need to use a remote context at all19:29
richardhthat's interesting19:29
richardhbut you do when you're standalone, right?19:29
tcrawleyyou mean outside of WF? yes, if you want to talk to another app, because it will be in another process19:30
tcrawleybut inside WF, they are in the same process, and talking to the same HQ instance19:30
richardhok. Got it. The remote context corresponds to the HQ instance.19:31
richardhI will go try this now.19:31
tcrawleymy pleasure! and if you do need to connect to a remote WF, I can dig up the security stuff for you19:31
tcrawleyjust met me know19:31
richardhok, thanks. I'll keep you posted.19:32
*** lance|afk is now known as lanceball19:35
richardh@tcrawley now I remember the error I got before when trying to do this without passing a context:19:36
richardhDuplicateServiceException Service jboss.messaging.default.jms.queue./queue/q is already registered  org.jboss.msc.service.ServiceRegistrationImpl.setInstance (ServiceRegistrationImpl.java:158)19:36
richardhHow do I get a reference to it without Immutant trying to create it?19:36
tcrawleyrichardh: hmm. I've seen that recently, and I'm trying to remember what causes it. can you gist the full output?19:38
richardhjust a sec19:40
tcrawleyrichardh: are you specifying that queue in the standalone.xml? if so, there is a bug in the docs that may cause what you are seeing19:44
richardhNot sure if that will be helpful. The full output doesn't look related.19:44
richardhYes, I am specifying the queue in standalone.xml.19:45
richardhIs there a way to create them dynamically?19:45
richardhA bug in the docs?19:45
tcrawleyyes, the docs were wrong wrt specifying them in standalone.xml: https://github.com/immutant/immutant/commit/bf4a72e9619:46
jbossbotgit [immutant] bf4a72e.. Toby Crawley Fix JNDI examples in messaging doc [IMMUTANT-596]...19:46
jbossbotjira [IMMUTANT-596] Messaging docs are incorrect wrt specifying destinations in standalone.xml [Resolved (Done) Documentation, Major, Unassigned] https://issues.jboss.org/browse/IMMUTANT-59619:46
tcrawleycan you gist the section of your standalone.xml where you define that queue?19:46
tcrawleyyou can create them dynamically by just not having them in standalone.xml, but it's possible to get in a deadlock situation if multiple apps that depend on the queue are deployed at the same time19:49
richardhJust read the doc fix. Yup, that would be the issue. Let me try it with that naming convention.19:49
tcrawleygood deal19:49
tcrawleythat doc fix will be in 2.1.2, whenever we release it19:49
richardhYeah, I gathered creating them dynamically was a no-no19:49
tcrawleyI really wish it wasn't, but there are some things within WildFly that we can't work around easily that make it difficult19:50
richardhAlthough, we figured out for dev (i.e. outside Wildfly) that it will be fine as long as each app references all the queues immediately upon startup19:51
richardhand all the apps reference all the same queues. That way, the first one will fire up the HQ instance and be the message broker for all the others19:51
richardhand it doesn't matter which one the first one is, because each one will either create all the queues19:52
richardhor just get references to them. the app doesn't have to know which of these things happened.19:52
richardhDoes this make sense? and would such a strategy work inside Wildfly?19:53
richardhOf course, this isn't really "dynamic" in any way -- all the apps have to know the names of the queues in advance, and have to get references to all of them19:53
tcrawleyright, as long as whatever comes up first knows about all the queues, you should be fine. you can't create apps remotely, so whichever app is running the HQ instance has to know about them all (outside of the container)19:53
tcrawleyanother approach is to have one well-known queue name, and each app first does a request/respond call on that queue, telling the responder the name of a queue to create19:54
richardhYou're just talking about outside wildfly right now, right?19:54
tcrawleyif each app does that before talking to the queue, it will work19:54
tcrawleyyes, this is all outside19:55
richardhthe deadlock issue inside Wildfly is separate from this, isn't it?19:55
tcrawleyinside, something similar would work - you define the well-known queue in standalone.xml, and all the apps do that same dance to create queues dynamically. that won't lead to the deadlock, but will cause problems if you redeploy the "master" app (the one actually creating the queues)19:56
tcrawleybecause it now owns all the queues, and they will go away when it is redeployed, breaking all the other apps19:57
richardhSounds safer just to have a list of known queues19:57
tcrawleyyes indeed19:57
richardhIf you need a whole bunch of them, they can be managed in a pool or something19:57
richardh@tcrawley thanks for your help. I'll go now and try that out with the correct entry names.20:01
*** jcrossley3-away is now known as jcrossley320:01
tcrawleymy pleasure! let us know if you need anything else20:01
*** projectodd-ci <projectodd-ci!~PircBotx@ec2-54-145-107-102.compute-1.amazonaws.com> has quit IRC (Remote host closed the connection)20:30
*** projectodd-ci <projectodd-ci!~PircBotx@ec2-54-145-107-102.compute-1.amazonaws.com> has joined #immutant20:32
*** richardh <richardh!d06904fc@gateway/web/freenode/ip.> has quit IRC (Ping timeout: 252 seconds)20:33
*** projectodd-ci <projectodd-ci!~PircBotx@ec2-54-145-107-102.compute-1.amazonaws.com> has quit IRC (Client Quit)20:36
*** projectodd-ci <projectodd-ci!~PircBotx@ec2-54-145-107-102.compute-1.amazonaws.com> has joined #immutant20:36
*** soupman <soupman!32fe4151@gateway/web/freenode/ip.> has joined #immutant21:07
*** soupman <soupman!32fe4151@gateway/web/freenode/ip.> has quit IRC (Quit: Page closed)21:25
*** tcrawley is now known as tcrawley-away22:13
*** mgoldmann is now known as mgoldmann|away22:19
*** bbrowning is now known as bbrowning_away22:21
*** bobmcw <bobmcw!~bobmcw@redhat/jboss/bobmcw> has quit IRC (Remote host closed the connection)22:28
*** qwerty_nor <qwerty_nor!~Thunderbi@> has quit IRC (Ping timeout: 250 seconds)22:33
*** lanceball is now known as lance|afk22:49
*** bobmcw <bobmcw!~bobmcw@va-67-233-86-120.dhcp.embarqhsd.net> has joined #immutant23:28
*** bobmcw <bobmcw!~bobmcw@va-67-233-86-120.dhcp.embarqhsd.net> has quit IRC (Changing host)23:28
*** bobmcw <bobmcw!~bobmcw@redhat/jboss/bobmcw> has joined #immutant23:28
*** bobmcw <bobmcw!~bobmcw@redhat/jboss/bobmcw> has quit IRC (Ping timeout: 246 seconds)23:35
*** lnostdal_ <lnostdal_!~lnostdal@> has quit IRC (Ping timeout: 272 seconds)23:36
*** lnostdal_ <lnostdal_!~lnostdal@bl7-221-246.dsl.telepac.pt> has joined #immutant23:37
*** danielglauser <danielglauser!~danielgla@> has quit IRC (Remote host closed the connection)23:40
*** jcrossley3 is now known as jcrossley3-away23:45
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 240 seconds)23:59

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!