I have a Icecast2 (2.4.1) setup working, users connect to /live and listens to my rotation. Now I want to have another "mount point" so I can go live and back to rotation.
I haven't found a guide or help I could understand so far.
What you are looking for are "fallbacks".
The documentation describes them.
Basically you would have a transition like this:
/live.ogg
↓ (↑)
/rotation.ogg
If /live.ogg disconnects, all listeners are transferred to /rotation.ogg. New listeners connecting to /live.ogg are directly served the /rotation.ogg stream.
If fallback-override is set, then the arrow in brackets becomes relevant:
If /live.ogg reconnects, all listeners are transferred back from /rotation.ogg to /live.ogg.
Otherwise all listeners remain on /rotation.ogg and only new listeners are served /live.ogg.
In terms of config it would look something like this (only relevant parts are included):
<mount>
<mount-name>/live.ogg</mount-name>
<fallback-mount>/rotation.ogg</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
<mount>
<mount-name>/rotation.ogg</mount-name>
</mount>
Related
We have a situation where a Liberty application accesses a custom resource adapter through a JNDI lookup to a connection factory, defined in the server.xml. The combination of the connectionFactory, resourceAdapter, and enterpriseApplication nodes in the server.xml appears to make it impossible to bundle the rar inside the ear and push an ear as a single entity without major app refactoring, which is a non-starter.
I see two options for getting around this right now:
Push the rar/ear combo as a bundled server package, or
Modify the Liberty buildpack to pull in the rar at push time, generating the expected nodes in the server.xml
Am I missing a third option?
Thanks, Tom
The third option would be to embed the RAR in your app, but I didn't understand your comment about why that would require extensive app refactoring. In theory, the app shouldn't change, just the config...
See the IBM Knowledge Center topic http://www-01.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.wlp.doc/ae/twlp_jca_config_resadapters.html?lang=en for details on configuring a connection factory for use with an embedded resource adapter.
For the standalone resource adapter, I assume you had something like this in server.xml:
<connectionFactory jndiName="eis/NAME" type="javax.resource.cci.ConnectionFactory">
<properties.rarName dataStoreName="name" hostName="otherName"/>
</connectionFactory>
<resourceAdapter id="rarName" location="rarName.rar"/>
when you embed the rar in the ear, as you noted, that resourceAdapter node goes away and instead you would use something like this:
<application location="C:/applications/app1.ear"/>
<connectionFactory jndiName="eis/NAME” type='javax.resource.cci.ConnectionFactory’>
<properties.app1.rarName dataStoreName="name" hostName="otherName"/>
</connectionFactory>
Note that for an embedded resource adapter, the properties element must now also include the application name (in this case “app1”) in the name of the element.
As indicated in the Knowledge Center topic, if you wanted to override the default name of the resource adapter, you could instead do:
<application location="C:/applications/app1.ear”>
<resourceAdapter id=“rarName" alias="MyEmbeddedRA"/>
</application>
<connectionFactory jndiName="eis/NAME" type="javax.resource.cci.ConnectionFactory">
<properties.app1.MyEmbeddedRA dataStoreName="name" hostName="otherName"/>
</connectionFactory>
I am using Jetty-9 in embedded mode and need only one web application. Consequently I would like the root URL to go to the homepage of that application, i.e. something like
http://localhost:4444/
should end up in a servlet. I start out with:
ServletContextHandler scContext =
new ServletContextHandler(ServletContextHandler.SESSIONS);
scContext.setContextPath("/");
None of the following worked, neither
scContext.addServlet(ListsServlet.class, "/");
nor
scContext.setWelcomeFiles(new String[]{"/lists})
where /lists is mapped to the ListsServlet servlet. All I get is a 403 (Forbidden).
I do not use the DefaultServlet, which seems to handle welcome files. But since the ServletContextHandler has setWelcomeFiles I expected it to contain the logic to use them.
Any ideas?
For the 403 Forbidden error, you have some security setup that is not allowing you to access the handlers/servlets.
Eliminate that security (for now), verify that the rest is working, then add security a bit later to lock down specifics.
If you want to see some the suggestions below at work, consider looking at the code example in the answer from another stackoverflow: How to correctly support html5 <video> sources with jetty.
Welcome files are appended to the incoming request path if there is nothing present at that location. For example requesting a directory and then a welcome-file of 'index.html' is appended to the request path.
While this would work ...
scContext.setWelcomeFiles(new String[]{"lists"})
// Add Default Servlet (must be named "default")
ServletHolder holderDefault = new ServletHolder("default",DefaultServlet.class);
holderDefault.setInitParameter("resourceBase",baseDir.getAbsolutePath());
holderDefault.setInitParameter("dirAllowed","true");
holderDefault.setInitParameter("welcomeServlets","true");
holderDefault.setInitParameter("redirectWelcome","true");
scContext.addServlet(holderDefault,"/");
It's likely not what you are aiming for, as you said the root path only.
The above would also make changes to requests like /foo/ to /foo/lists
Instead, it might make more sense to use a Rewrite rule + handler instead of the welcome-files approach.
RewriteHandler rewrite = new RewriteHandler();
rewrite.setHandler(scContext);
RewritePatternRule rootRule = new RewritePatternRule();
rootRule.setPattern("/");
rootRule.setReplacement("/list");
rootRule.setTerminating(true);
rewrite.addRule(rootRule);
server.setHandler(rewrite);
This RewritePatternRule simply changes any request path / to /list and then forwards that request to the wrapped ssContext (if you want to see the /list on the browser, change it to a RedirectPatternRule instead.
I would like to ask how can I start another flow using quartz.
Starting each flow seperately (one is trigered with IMAP and second with Quartz) works ok, but I would like to have both of them in same file if possible, or at least in same project. I don't know what is good practice for this so I let you decide.
So, Flow1 starts with IMAP and do its job with mail (original) and then goes on to other subflows.
Flow2 starts with quartz and do its job (the one I would like to add)
Both flows have same variables and have similar job but don't have to be sinchronized of course.
Now, how can I achieve this?
I tried this:
<flow name="Flow1" doc:name="Flow1">
<imaps:inbound-endpoint doc:name="IMAP"
host="imap.gmail.com" port="993" responseTimeout="10000"
........
</flow>
<flow name="Flow2" doc:name="Flow2">
<quartz:outbound-endpoint jobName="FlowStarter" repeatInterval="10000" responseTimeout="10000" doc:name="Quartz">
<quartz:event-generator-job groupName="QuartzGenGroup" jobGroupName="QuartzGenGroup">
<quartz:payload>wwqda</quartz:payload>
</quartz:event-generator-job>
</quartz:outbound-endpoint>
<logger message="Quartz started at #[server.dateTime.toCalendar().toString()] #[payload]" level="INFO" doc:name="Logger"/>
</flow>
When I started this, Flow2 never gave any output.
I am using Mule Studio 3.5.0
Thank you!
In the Flow 2 use quartz:inbound-endpoint instead of quartz:outbound-endpoint. Outbound endpoint does not trigger workflow itself. It requires an additional incoming event.
Look at http://2rdscreenretargeting.blogspot.ru/2012/12/how-to-schedule-jobs-using-mule-studio.html for details on Quartz usage in Mule.
I'd like to tie into the directions functionality on Glass, in a similar method to the Mirror API Get Directions menu. Is there a way of launching directions via a URI within a GDK application?
Use the following intent to go to Saint-Malo, France the most beautiful city in the world :
Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setData(Uri.parse("google.navigation:q=48.649469,-2.02579"));
startActivity(intent);
The log below was captured when launching built in navigation via "get directions"
11-20 22:26:58.087: I/NavigationActivity(14325): onCreate Intent { act=android.intent.action.VIEW dat=google.navigation:q=San+Diego&mode=mru flg=0x10000000 cmp=com.google.glass.maps/.NavigationActivity (has extras) }
It seems to show that you might be able to start activity class as "com.google.glass.maps.NavigationActivity" with Intent of "android.intent.action.VIEW " and data set to "google.navigation:q=San+Diego".
I've not actually try it, but it will be a good bet.
Update: after trying using 'adb am' command and it works, so this definitely should work from code prospective:
adb shell am start -n com.google.glass.maps/.NavigationActivity -a android.intent.action.VIEW -d google.navigation:q=92108
I'm using Lamina to implement a basic pubsub pattern.
When a client subscribes to a topic I create a new channel for it (if it doesn't already exist) and then siphon it to the client's channel. However, I can't figure out how to reverse this to let the client unsubscribe. I've been searching the docs and googling but can't find anything.
How do I undo what siphon does?
You can fork the upstream channel above the siphon and then ground the downstream channel, or if your graph permits can you just close the channel you no longer want siphoning form the upstream channel.
ps: i'll try to add an example later ...
Typically you'd make a bridge channel that you can close, so the linkage is:
topic-channel -> bridge-channel -> client-channel
In 0.5.0, this is easy because siphon is variadic:
(defn cancellable-siphon [src dst]
(let [bridge (channel)]
(siphon src bridge dst)
#(close bridge)))