See http://hudson.zones.apache.org/hudson/job/Solr-trunk/425/changes
hi ,
The current replication strategy in solr involves shell scripts . The
following are the drawbacks
* It does not work with windows
* Replication works as a separate piece not integrated with solr.
* Cannot control replication from solr admin/JMX
* Each operation requires manual telnet to the h
Hi Paul!
Noble Paul നോബിള് नोब्ळ् wrote:
The current replication strategy in solr involves shell scripts . The
following are the drawbacks
* It does not work with windows
Solr's replication code uses hard links to avoid copying of the
potentially big index files. Windows supports (better: t
I agree with the goals - having a replication module that was more
integrated with Solr and worked in Windows would be nice.
The details are still a bit fuzzy though... I'm not sure if SolrJ &
BinaryResponseWriter should be used as the overhead when transferring
gigabytes of files would probably b
Whenever I see a project with some home-grown LogManager that provides
loggers, I am always mildly disgusted no matter how simple it is (no
disrespect to you, that is my opinion). I believe use of SLF4J will meet
common goals. Solr should log to SLFJ4J (slf4j-api.jar) and then
out-of-the-box shi
My main point is philosophical - adding another dependency just for
logging seems so wrong.
Pragmatically - I give up I won't block an overhaul to Solr's
logging I'll just quietly cringe.
Erik
On Apr 29, 2008, at 10:25 AM, David Smiley @MITRE.org wrote:
Whenever I see a
I do sympathize; it does seem wrong, but it's the norm in Java because Sun
screwed up Jdk14 logging. It's not a reflection of the design decisions of
Solr (i.e. your judgement) so please don't feel too bad accepting SLF4J.
~ David
Erik Hatcher wrote:
>
> My main point is philosophical - addin
Hello:
I didn't want to offend anyone in this mailing list by posting this message,
but I simple can't publish new messages since last post. Is there any kind
of filtering/moderation?
LRUCache-related post which never reach solr-dev list:
http://www.nabble.com/Server-Hungs-with-Lucene-2.3.1-td1
I didn't want to offend anyone...
Thanks
Funtick wrote:
>
> Hello:
>
>
> I didn't want to offend anyone in this mailing list by posting this
> message, but I simple can't publish new messages since last post. Is there
> any kind of filtering/moderation?
>
> LRUCache-related post which never
Fuad,
You didn't offend anyone.
You are, however, posting to the wrong list. Please post to solr-user, not
solr-dev.
I saw your messages, but don't see enough information to figure out your
problem with Solr.
I think you are using several email accounts, maybe that's why you are having
troubl
[
https://issues.apache.org/jira/browse/SOLR-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-334:
--
Attachment: angle2curly.patch
Attaching patch to change from to {!foo}
Seeing no other opinions, I'll co
Solrj/BinaryResponseWriter should be used for calls to get metadata on
the index. The actual index transfer must be done over simple http. I
may propose a Simple BinaryRawResponseWriter for that.
Sending a huge file in a single response is definitely a bad idea. It
should be send in chunks of say
We can probably do away with hard-links if a core swap (rename) can be made
to work without downtime.
On Tue, Apr 29, 2008 at 11:32 PM, Noble Paul നോബിള് नोब्ळ् <
[EMAIL PROTECTED]> wrote:
> Solrj/BinaryResponseWriter should be used for calls to get metadata on
> the index. The actual index tran
: We can probably do away with hard-links if a core swap (rename) can be made
: to work without downtime.
One thing to keep in mind if you rely on core swapping as an integral part
of replication is that you won't be able to take advantage of
"newSearcher" events or autowarming of caches (becau
Thomas: I see the advantages of the current solution .We still can
have an alternative solution. . Solr keeps everything pluggable and
let us allow the user to pick hhis poison.
Performance is not an issue in all cases. There are users who have
indexes which are not too large .They would be looking
>
> I guess the challenge would not be in executing those commands, but to
> match the performance of rsync.
>
I am not sure rsync brings all that much compared to simple timestamps on files
(and maybe some smarter crc on fixed sized blocks?) now when we have "write
once" indexing... I think N
Thanks Otis;
> > Object get(Object key) {
> > synchronized (map) {
> > ... .incrementAndGet()
> > ...
> > }
Existing code does not slow down performance in simplest cases. However, it
slows down with read-only Faceted queries because each such query hits cache
thousands t
I agree, slf4j is a better solution; I was just trying to mitigate the
functional need (hooking log4j) & the strong (op)positions against changing
the logging API, thus the mildly disgusting solr-549 strawman. :-)
David Smiley @MITRE.org wrote:
>
> Whenever I see a project with some home-grow
[
https://issues.apache.org/jira/browse/SOLR-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593116#action_12593116
]
Yonik Seeley commented on SOLR-334:
---
curly brace patch committed.
> pluggable query parser
[
https://issues.apache.org/jira/browse/SOLR-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Whitman updated SOLR-553:
---
Attachment: highlighttest.xml
Attaching a base test case document xml to post to the trunk solr example
: > JULI can be configured per-webapp also by adding a logging.properties to the
: > classpath (add it to WEB-INF/classes). So you can configure Handlers
: JULI is a Tomcat thing
:
(http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/juli/package-summary.html
: ), right? In other words, it d
: FWIW, Hoss, I don't think your main argument for JUL stands anymore (I finally
: got caught up on the archives). Namely, Solr is used in embedded situations
: much more now and it should no longer be assumed that it is in a standalone
: servlet completely isolated from the rest of the world. I
: a fan; but it's really not that important any way). Then, if someone (like
: me :-) would like to configure logging with log4j then I am easily empowered
: to do so by removing that jar and adding slf4j-log4j.jar. What I like about
This is the part of all the third party logging abstraction ar
hossman wrote:
>
> ...
> There may be servlet containers that don't do a particularly good job of
> dealing with JUL (aka: JDK logging) but that is their deficiency, not
> Solr's.
>
That is a convincing argument, admittedly. But by using SLF4J, Solr won't
alienate users using such contain
hossman wrote:
>
> : a fan; but it's really not that important any way). Then, if someone
> (like
> : me :-) would like to configure logging with log4j then I am easily
> empowered
> : to do so by removing that jar and adding slf4j-log4j.jar. What I like
> about
>
> This is the part of all th
: That is a convincing argument, admittedly. But by using SLF4J, Solr won't
: alienate users using such containers (like me, using JBoss 3.x), ANY
: container should be fine based on the way SLF4J works.
Unless that container already uses SLF4J (ahem: jetty) and the version
used by the containe
: 2. If you're saying (from another message I responded to) that it's the
: container's job to handle the JUL configuration in a flexible manner, then
: wouldn't it be reasonable in this scenario to tell the container to direct
: JUL to whatever it is I want (log4j in this scenario)?
: 3. You ment
On Apr 29, 2008, at 6:14 PM, Chris Hostetter wrote:
: > JULI can be configured per-webapp also by adding a
logging.properties to the
: > classpath (add it to WEB-INF/classes). So you can configure
Handlers
: JULI is a Tomcat thing
:
(http://tomcat.apache.org/tomcat-6.0-doc/api/org/apach
But that's just it, hardly anything does use JUL. I can't for the
life of me think of a single project that does OTHER than Solr.
And Jetty is what WE ship, not just me using it. By definition, the
container that we ship for our examples doesn't do logging right. How
would we expect any
On Apr 29, 2008, at 8:45 PM, Grant Ingersoll wrote:
Just because something is a standard doesn't mean it is good.
Just because someone containers haven't done what they need to do to
integrate in a standard logging API into their configurability
doesn't make it bad.
Erik
On Apr 29, 2008, at 8:00 PM, David Smiley @MITRE.org wrote:
2. If you're saying (from another message I responded to) that it's
the
container's job to handle the JUL configuration in a flexible
manner, then
wouldn't it be reasonable in this scenario to tell the container to
direct
JUL to w
Hmm. This is probably fixable doing either of these two (both are easy):
1. update the SLF4J in Jetty
2. at deploy time either remove slf4j from the war, or configure Jetty not
to use it (JBoss has that latter feature which is quite nice)
This is also a scenario that could play out with JUL, it'
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-303:
--
Attachment: shards_qt.patch
Attaching shards_qt.patch, which uses "shards.qt" as "qt" for sub-requests to
using an alternate logging framework does't make JUL logging go away
--
it's still there, it's the 3000lb gorilla in the corner. it may be
sleeping, but that doesn't mean some code somewhere isn't going to
wake it
up at some point -- you might as well acknowledge it and deal with it.
brin
I guess I'll shut up for now; we seem to have gone at it for awhile
and I'm
not sure what more there is to say on either party.
If history is any indication, the issue will lay fallow for 3-4 months
then flare up the next time someone bangs their head on JUL.
I agree with Hoss and Erik
I don't know about you, but an issue that continues to flale up now and then
(with a long passionate thread as we are having now) strikes me as "strong
opposition".
If Solr had always used SLF4J (or even JCL), do you imagine there would be
any opposition that compared in any way to the opposition
[
https://issues.apache.org/jira/browse/SOLR-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593221#action_12593221
]
Otis Gospodnetic commented on SOLR-521:
---
I think using enablePI=true would be a fine de
On Tue, Apr 29, 2008 at 11:42 PM, Chris Hostetter
<[EMAIL PROTECTED]> wrote:
>
> : We can probably do away with hard-links if a core swap (rename) can be made
> : to work without downtime.
>
> One thing to keep in mind if you rely on core swapping as an integral part
> of replication is that yo
38 matches
Mail list logo
