[jira] Commented: (SOLR-256) Stats via JMX
[
https://issues.apache.org/jira/browse/SOLR-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617771#action_12617771
]
Shalin Shekhar Mangar commented on SOLR-256:
Hoss, thanks for the comments.
* Specifying port=0 to ServiceUrl does not work, it blindly tries to connect to
localhost on port 0 and fails with a java.rmi.ConnectException. We can try to
do something like this:
{code}
ServerSocket server = new ServerSocket(0);
int port = server.getLocalPort();
server.close();
// Use the port
{code}
However it will not be reliable on every environment. I can put this into a
loop and retry a fixed number of times before failing. That should be good
enough.
* Agreed
* Copy/paste error :)
* That's a very good idea.
* Not sure if it really matters but that's very easy to do.
I shall give a patch shortly.
Stats via JMX
-
Key: SOLR-256
URL: https://issues.apache.org/jira/browse/SOLR-256
Project: Solr
Issue Type: New Feature
Components: search, update
Reporter: Sharad Agarwal
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 1.3
Attachments: jmx.patch, jmx.patch, jmx.patch, jmx.patch, jmx.patch,
SOLR-256.patch, SOLR-256.patch, SOLR-256.patch, SOLR-256.patch,
SOLR-256.patch, SOLR-256.patch, SOLR-256.patch, SOLR-256.patch, SOLR-256.patch
This patch adds JMX capability to get statistics from all the SolrInfoMBean.
The implementation is done such a way to minimize code changes.
In SolrInfoRegistry, I have overloaded Map's put and remove methods to
register and unregister SolrInfoMBean in MBeanServer.
Later on, I am planning to use register and unregister methods in
SolrInfoRegistry and removing getRegistry() method (Hiding the map instance
to other classes)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-256) Stats via JMX
[
https://issues.apache.org/jira/browse/SOLR-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617632#action_12617632
]
Hoss Man commented on SOLR-256:
---
Shalin:
I'm really sorry, I'm way behind schedule on my patch review responsibilities.
skimming the patch, I see no red flags.
Some minor misc nitpicks...
* I'd prefer if we removed the hard coded port number in TestJmxMonitoredMap
(hard coded stuff like that has caused us nothing but problems in the past).
If i'm understanding the JMXServiceURL javadocs correctly, let's hardcode
port=0 for the url constructed by the test ... then add a getJMXServiceURL() to
JmxMonitoredMap that the test can then call and pass to to the
JMXConnectorFactory ... that should give us either a random port that isn't in
use by anyone else, right?
* it seems like it would be a little cleaner if SolrIndexSearcher.register()
registered itself before it registered it's subcomponents .. not sure that it
really matters, but it certain reads a little weird.
* SolrIndexSearcher.register() is logging 'Registering new searcher: +
System.currentTimeMillis()' for every cache it registers ... that seems like a
cut/paste mistake.
* is there any reason not to have the searcher's add/remove themselves using
their true name on register()/close() *and* have register() call
put(searcher, this) like you have it now? ... that way you'd get the benefits
you mentioned before (continuous monitoring of the current searcher) but you
could also get information about how many live searchers there currently are,
and what their stats look like (so you could, for example, notice when there is
a really old Searcher hanging around for some inexplicable reason, probably a
bug.)
* couldn't we completely eliminate any overhead of JMX for people who haven't
enabled it by adding an isEnabled() method to JmxMonitoredMap that returns
true if server!=null and then make the SolrCore changes look like...
{code}
//Initialize Registry w/JMX if enabled
JmxMonitoredMapString,SolrInfoMBean tmp = new
JmxMonitoredMapString,SolrInfoMBean(name, config.jmxConfig);
infoRegistry = (tmp.isEnabled() ? tmp : new
HashMapString,SolrInfoMBean() );
{code}
Stats via JMX
-
Key: SOLR-256
URL: https://issues.apache.org/jira/browse/SOLR-256
Project: Solr
Issue Type: New Feature
Components: search, update
Reporter: Sharad Agarwal
Assignee: Hoss Man
Priority: Minor
Fix For: 1.3
Attachments: jmx.patch, jmx.patch, jmx.patch, jmx.patch, jmx.patch,
SOLR-256.patch, SOLR-256.patch, SOLR-256.patch, SOLR-256.patch,
SOLR-256.patch, SOLR-256.patch, SOLR-256.patch, SOLR-256.patch, SOLR-256.patch
This patch adds JMX capability to get statistics from all the SolrInfoMBean.
The implementation is done such a way to minimize code changes.
In SolrInfoRegistry, I have overloaded Map's put and remove methods to
register and unregister SolrInfoMBean in MBeanServer.
Later on, I am planning to use register and unregister methods in
SolrInfoRegistry and removing getRegistry() method (Hiding the map instance
to other classes)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-256) Stats via JMX
[
https://issues.apache.org/jira/browse/SOLR-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607189#action_12607189
]
Shalin Shekhar Mangar commented on SOLR-256:
I'm taking a look again at this feature. Hope to have a patch ready soon.
A few issues I found was that apart from SolrCore.registerRequestHandler, the
SolrIndexSearcher is also dynamic and needs to be handled. I also found other
issues like SolrIndexSearcher puts the cache objects into the InfoRegistry map
but that they are never removed from the map. The SolrCore#closeSearcher calls:
{code}infoRegistry.remove(currentSearcher);{code} but the SolrIndexSearcher
adds/removes itself using its name. I think we should use currentSearcher
itself as the key instead of name because the name changes after commits and
that would make it very difficult to setup monitoring for SolrIndexSearcher
using JMX.
To handle dynamic registration and unregistration, I think we should use the
approach that Sharad used in his original patch which was to create a class
which extends Map and overrides the put and remove methods. That will make sure
that SolrInfoMBeans are automatically registered and unregistered and will keep
the JMX related code in one place.
Stats via JMX
-
Key: SOLR-256
URL: https://issues.apache.org/jira/browse/SOLR-256
Project: Solr
Issue Type: New Feature
Components: search, update
Reporter: Sharad Agarwal
Assignee: Hoss Man
Priority: Minor
Fix For: 1.3
Attachments: jmx.patch, jmx.patch, jmx.patch, jmx.patch, jmx.patch,
SOLR-256.patch, SOLR-256.patch, SOLR-256.patch, SOLR-256.patch, SOLR-256.patch
This patch adds JMX capability to get statistics from all the SolrInfoMBean.
The implementation is done such a way to minimize code changes.
In SolrInfoRegistry, I have overloaded Map's put and remove methods to
register and unregister SolrInfoMBean in MBeanServer.
Later on, I am planning to use register and unregister methods in
SolrInfoRegistry and removing getRegistry() method (Hiding the map instance
to other classes)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-256) Stats via JMX
[ https://issues.apache.org/jira/browse/SOLR-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528851 ] Hoss Man commented on SOLR-256: --- proposed solrconfig.xml syntax... jmx / ...wraps the solr registry stuff in MBeans, adds them to the first MBeanSearver it finds (if any) but will not create one. jmx agentId=foo / ...wraps the solr registry stuff in MBeans, adds them to the first MBeanServer it finds matching that agentId, error if MBeanServer can't be found. jmx serviceurl=service:jmx:rmi:///jndi/rmi://localhost:/solr / ...wraps the solr registry stuff in MBeans, foracbly spins up a new MBeanServer exposed for remote monitoring at the specific service url, if the JMXConnectorServer can't be started (probably because the serviceurl is bad) then error. (we can punt on the issue of security -- if users want Solr to manage their JMX remote debuging then it's wide open; if you want password files or ssl, then configure that with the JVM system properties for remote debugging and just tell solr jmx /) Stats via JMX - Key: SOLR-256 URL: https://issues.apache.org/jira/browse/SOLR-256 Project: Solr Issue Type: New Feature Components: search, update Reporter: Sharad Agarwal Priority: Minor Attachments: jmx.patch, jmx.patch, jmx.patch, jmx.patch, jmx.patch This patch adds JMX capability to get statistics from all the SolrInfoMBean. The implementation is done such a way to minimize code changes. In SolrInfoRegistry, I have overloaded Map's put and remove methods to register and unregister SolrInfoMBean in MBeanServer. Later on, I am planning to use register and unregister methods in SolrInfoRegistry and removing getRegistry() method (Hiding the map instance to other classes) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-256) Stats via JMX
[ https://issues.apache.org/jira/browse/SOLR-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514884 ] Hoss Man commented on SOLR-256: --- Hmmm... some quick poking around makes it seem that tomcat always uses MBeanServers to manage things -- regardless of whether you explicitly turn on JMX monitoring or not (there seems to be an assumption that of course you want to monitor you server -- i can't really argue with that) i don't really know enough about JMX to know if there really is any sort of overhead here -- i suppose it wouldn't hurt to only use the MOnitoredMap if an explicit option is set (but we shouldn't startup our own MBeanServer like hte orriginal patch -- just use the main one) but i'm also fine committing the patch as is. any tomcat/jmx experts want to chime in here? Stats via JMX - Key: SOLR-256 URL: https://issues.apache.org/jira/browse/SOLR-256 Project: Solr Issue Type: New Feature Components: search, update Reporter: Sharad Agarwal Priority: Minor Attachments: jmx.patch, jmx.patch, jmx.patch, jmx.patch, jmx.patch This patch adds JMX capability to get statistics from all the SolrInfoMBean. The implementation is done such a way to minimize code changes. In SolrInfoRegistry, I have overloaded Map's put and remove methods to register and unregister SolrInfoMBean in MBeanServer. Later on, I am planning to use register and unregister methods in SolrInfoRegistry and removing getRegistry() method (Hiding the map instance to other classes) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-256) Stats via JMX
[ https://issues.apache.org/jira/browse/SOLR-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1250 ] Sharad Agarwal commented on SOLR-256: - Hoss, thanks for having given a look at the patch. Via -Dcom.sun.management.jmxremote jvm local platform monitoring gets enabled; and you get to see all jvm statistics. This patch actually starts its own mbean registry (called MBeanServer). mbeanServer = MBeanServerFactory.createMBeanServer(); java.lang.String serviceUrl = service:jmx:rmi:///jndi/rmi:// + InetAddress.getLocalHost().getHostAddress().toString() + : + jmxPort + /solr; JMXConnectorServer cs = JMXConnectorServerFactory .newJMXConnectorServer(new JMXServiceURL(serviceUrl), null, mbeanServer); cs.start(); Instead of starting its own, other alternative (as you have pointed out) could be to use platform registry itself. In that case: MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); Register all solr mbean into platform mbeanserver itself. In this case all info would be available together. Remote monitoring and access control could be set up using appropriate com.sun.management.jmxremote.port, com.sun.management.jmxremote.password.file, com.sun.management.jmxremote.ssl options. I found http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html#properties pretty handy. I agree with you that having solr stats along with jvm stats makes more sense as it will require just one registry to manage.(setting up ports and access control). I can work on the patch to have that in place. Stats via JMX - Key: SOLR-256 URL: https://issues.apache.org/jira/browse/SOLR-256 Project: Solr Issue Type: New Feature Components: search, update Reporter: Sharad Agarwal Priority: Minor Attachments: jmx.patch, jmx.patch, jmx.patch This patch adds JMX capability to get statistics from all the SolrInfoMBean. The implementation is done such a way to minimize code changes. In SolrInfoRegistry, I have overloaded Map's put and remove methods to register and unregister SolrInfoMBean in MBeanServer. Later on, I am planning to use register and unregister methods in SolrInfoRegistry and removing getRegistry() method (Hiding the map instance to other classes) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-256) Stats via JMX
[ https://issues.apache.org/jira/browse/SOLR-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508053 ] Sharad Agarwal commented on SOLR-256: - ArrayList list = MBeanServerFactory.findMBeanServer(null); gives all registered mbeanserver. It could be used to figure out programitically whether jmx is enabled or not. Stats via JMX - Key: SOLR-256 URL: https://issues.apache.org/jira/browse/SOLR-256 Project: Solr Issue Type: New Feature Components: search, update Reporter: Sharad Agarwal Priority: Minor Attachments: jmx.patch, jmx.patch, jmx.patch This patch adds JMX capability to get statistics from all the SolrInfoMBean. The implementation is done such a way to minimize code changes. In SolrInfoRegistry, I have overloaded Map's put and remove methods to register and unregister SolrInfoMBean in MBeanServer. Later on, I am planning to use register and unregister methods in SolrInfoRegistry and removing getRegistry() method (Hiding the map instance to other classes) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-256) Stats via JMX
[ https://issues.apache.org/jira/browse/SOLR-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507660 ] Hoss Man commented on SOLR-256: --- Sharad: JMX is one of those things i don't really understand very well, but i tried out the patch and played around with jconsole and it's really cool. one thing i'm not clear on (forgive my jmx ignorance) when trying to figure out how jconsole worked, i found some info saying that to enable JMX in a java app, you use -Dcom.sun.management.jmxremote option on the java command line ... doing that even without this patch allowed jconsole to autodetect that the start.jar process on my local machine supported JMX and gave me some interesting stats on things like memory and thread usage info from the jetty instance (including MBeans for the java.util.Logger's SOlr creates). With the patch, it doesn't seem to matter wether i use that commandline option or not i can only get access to the new solr specific stats if i tell jconsole to explicitly connect to the service:jmx:... url that shows up in the log. but in this case it can't get access to the other interesting stats from before (memory, thread, etc...) ... it seems like i can make two seperates sessions (forgive me if my terminology is wrong) to get this info, but not in the same session Is there a way to register the SOlr MBeans with the JVMs main JMX instance so all of hte info is available together? also: if we're going to have options for specifying the port for remove JMX connections, shoudl we also have options for the user/pass to connect with? Stats via JMX - Key: SOLR-256 URL: https://issues.apache.org/jira/browse/SOLR-256 Project: Solr Issue Type: New Feature Components: search, update Reporter: Sharad Agarwal Priority: Minor Attachments: jmx.patch, jmx.patch, jmx.patch This patch adds JMX capability to get statistics from all the SolrInfoMBean. The implementation is done such a way to minimize code changes. In SolrInfoRegistry, I have overloaded Map's put and remove methods to register and unregister SolrInfoMBean in MBeanServer. Later on, I am planning to use register and unregister methods in SolrInfoRegistry and removing getRegistry() method (Hiding the map instance to other classes) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
