1

Immutant allows applications to respond to web requests via Ring handlers. Each application can dynamically register any number of handlers, each with a unique context path. This allows you to have multiple Ring webapps that share the same deployment lifecycle.

So it says I can have multiple Ring apps on one immutant but can I/should I have two separate websites running on one immutant: site1.com and site2.com?

This context path is considered the top-level context path - you have the option to bind a handler to a sub-context path that will be nested within the top-level path. The full context is stripped from the url's path before the request is processed, and the context and remaining path info are made available as part of the request map via the :context and :path-info keys, respectively.

It sounds like I can have an app running on site1.com/context1 and site1.com/context2 but not so much two separate domains.

The reason I'm asking is because immutant takes up a lot of my server resources so much so I'm not sure if I can run two immutants. The correct question might be how do I improve performance on my immutant? (I'm not any good with servers/deployment.)

Source: http://immutant.org/documentation/0.1.0/web.html

deadghost
  • 5,017
  • 3
  • 34
  • 46
  • The doc you linked to is very old. The current release is 1.1.3: http://immutant.org/documentation/1.1.3/web.html – jcrossley3 Jul 13 '14 at 03:07

2 Answers2

1

The answer is complicated by the fact that there are currently two major Immutant version branches: 1.x and 2.x. 1.x requires far more resources than 2.x, but 2.x hasn't been officially released yet (though incremental releases are available).

Both versions support mounting Ring apps at various combinations of virtual host, e.g. site1.com, and context path, e.g. /context1. In Immutant 1.x, the :virtual-host setting is in your deployment descriptor, as is the :context-path for the entire project. This is somewhat confusing, since you can also specify a :context-path when starting your Ring handler. The one passed to immutant.web/start is resolved relative to the one set in the deployment descriptor, which is why it's referred to as a "sub context path" in the docs.

In 2.x, things are simpler, because there is no deployment descriptor. Everything is passed as an option to immutant.web/run.

jcrossley3
  • 11,576
  • 4
  • 31
  • 32
  • Cleared things right up. I enjoyed your talk on immutant REPL based development which greatly helped me get started. I'm still feeling things around and will need to spend some intimate time with the manual. – deadghost Jul 13 '14 at 04:47
  • Glad you liked the talk! If you run into other problems, drop in #immutant on freenode irc for the fastest response. Good luck! – jcrossley3 Jul 13 '14 at 04:50
0

Can you post a small example with what you have so far?

It seems like you could achieve it with the :host option to run: https://projectodd.ci.cloudbees.com/job/immutant2-incremental/lastSuccessfulBuild/artifact/target/apidocs/immutant.web.html

Konrad Garus
  • 53,145
  • 43
  • 157
  • 230
  • The :host option determines the interface on which the web socket is bound, but that option isn't available in Immutant 1.x, which I think is the version the OP is using. In 1.x, you would pass the -b option to the start up script. But I think the OP is asking about "name-based virtual hosts" anyway, so neither :host nor -b is applicable here. – jcrossley3 Jul 13 '14 at 03:29