from:"Krönert Florian"

RE: Log slow queries to SQL Database using Log4j2 (JDBC)

2020-05-26 Thread Krönert Florian

Hi Walter,

thanks for your response.
That sounds like a feasible approach, although I would like to keep the stack 
as small as possible.

But the direction that you pointed out seems promising, the JDBC issues with 
log4j2 don't seem to lead anywhere.

Kind Regards,
Florian

-Original Message-
From: Walter Underwood 
Sent: Dienstag, 26. Mai 2020 02:06
To: solr-user@lucene.apache.org
Subject: Re: Log slow queries to SQL Database using Log4j2 (JDBC)

I would back up and do this a different way, with off-the-shelf parts.

Send the logs to syslog or your favorite log aggregator. From there, configure 
something that puts them into an ELK stack (Elasticsearch, Logstash, Kibana). A 
commercial version of this is logz.io <http://logz.io/>.

Traditional relational databases are not designed for time-series data like 
logs.

Also, do you want your search service to be slow when the SQL database gets 
slow? That is guaranteed to happen. Writing to logs should be very, very low 
overhead. Do all of the processing after Solr writes the log line.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On May 25, 2020, at 3:53 AM, Krönert Florian  
> wrote:
>
> Hi everyone,
>
> For our Solr instance I have the requirement that all queries should be 
> logged, so that we can later on analyze, which search texts were queried most 
> often.
> Were using solr 8.3.1 using the official docker image, hosted on Azure.
> My approach for implementing this, was now to configure a Slow Request rule 
> of 0ms, so that in fact every request is logged to the slow requests file.
> This part works without any issues.
>
> However now I need to process these logs.
> It would be convenient, if I had those logs already inside a SQL database.
> I saw that log4j2 is able to log to a JDBC database, so for me it seemed the 
> easiest way to just add a new appender for JDBC, which also logs the slow 
> requests.
> Unfortunately I can’t seem to get the JDBC driver loaded properly. I have the 
> correct jar and the correct driver namespace. I’m sure because I use the same 
> setup for the dataimport handler and it works flawlessly.
>
> My log4j2.xml looks like this (removed non-relevant appenders):
>
> 
>   
> 
>connectionString="${jvmrunargs:dataimporter.datasource.url}"
> driverClassName="com.microsoft.sqlserver.jdbc.SQLServerDriver"
> username="${jvmrunargs:dataimporter.datasource.user}"
> password="${jvmrunargs:dataimporter.datasource.password}"
>   />
>   
>   
>   
>   
>   
>   
> 
>   
>   
>  level="info" additivity="false">
>   
> 
>   
> 
>
> I have loaded the JDBC driver per core in solrconfig.xml and also “globally” 
> inside solr.xml by adding its containing folder as libDir.
>
> Unforunately log4j2 still can’t find the JDBC driver, I always receive these 
> issues inside the sysout log:
>
>
> 2020-05-25T10:49:08.616562330Z DEBUG StatusLogger Acquiring JDBC
> connection from jdbc:sqlserver://--redacted--
>  2020-05-25T10:49:08.618023875Z DEBUG
> StatusLogger Loading driver class
> com.microsoft.sqlserver.jdbc.SQLServerDriver
>
> 2020-05-25T10:49:08.623000529Z DEBUG StatusLogger Cannot reestablish
> JDBC connection to FactoryData
> [connectionSource=jdbc:sqlserver://--redacted--
> , tableName=dbo.solr_requestlog,
> columnConfigs=[{ name=date, layout=null, literal=null, timestamp=true
> }, { name=id, layout=%u{RANDOM}, literal=null, timestamp=false }, {
> name=logLevel, layout=%level, literal=null, timestamp=false }, {
> name=logger, layout=%logger, literal=null, timestamp=false }, {
> name=message, layout=%message, literal=null, timestamp=false }, {
> name=exception, layout=%ex{full}, literal=null, timestamp=false }],
> columnMappings=[], immediateFail=false, retry=true,
> reconnectIntervalMillis=5000, truncateStrings=true]: The
> DriverManagerConnectionSource could not load the JDBC driver
> com.microsoft.sqlserver.jdbc.SQLServerDriver:
> java.lang.ClassNotFoundException:
> com.microsoft.sqlserver.jdbc.SQLServerDriver
>
> 2020-05-25T10:49:08.627598771Z  java.sql.SQLException: The
> DriverManagerConnectionSource could not load the JDBC driver
> com.microsoft.sqlserver.jdbc.SQLServerDriver:
> java.lang.ClassNotFoundException:
> com.microsoft.sqlserver.jdbc.SQLServerDriver
>
> 2020-05-25T10:49:08.628239791Z  at 
> org.apache.logging.log4j.core.appender.db.jdbc.AbstractDriverManagerConnectionSource.loadDriver(AbstractDriverManagerConnectionSource.java:203)
>
> 2020-05-25T10:49:08.628442097Z  at 
> org.apache.logging.log4j.core.appender.

Log slow queries to SQL Database using Log4j2 (JDBC)

2020-05-25 Thread Krönert Florian

Hi everyone,



For our Solr instance I have the requirement that all queries should be logged, 
so that we can later on analyze, which search texts were queried most often.

Were using solr 8.3.1 using the official docker image, hosted on Azure.

My approach for implementing this, was now to configure a Slow Request rule of 
0ms, so that in fact every request is logged to the slow requests file.

This part works without any issues.



However now I need to process these logs.

It would be convenient, if I had those logs already inside a SQL database.

I saw that log4j2 is able to log to a JDBC database, so for me it seemed the 
easiest way to just add a new appender for JDBC, which also logs the slow 
requests.

Unfortunately I can't seem to get the JDBC driver loaded properly. I have the 
correct jar and the correct driver namespace. I'm sure because I use the same 
setup for the dataimport handler and it works flawlessly.



My log4j2.xml looks like this (removed non-relevant appenders):





  



  

  

  

  

  

  

  



  

  



  



  





I have loaded the JDBC driver per core in solrconfig.xml and also "globally" 
inside solr.xml by adding its containing folder as libDir.

Unforunately log4j2 still can't find the JDBC driver, I always receive these 
issues inside the sysout log:



2020-05-25T10:49:08.616562330Z DEBUG StatusLogger Acquiring JDBC connection 
from jdbc:sqlserver://--redacted--

2020-05-25T10:49:08.618023875Z DEBUG StatusLogger Loading driver class 
com.microsoft.sqlserver.jdbc.SQLServerDriver

2020-05-25T10:49:08.623000529Z DEBUG StatusLogger Cannot reestablish JDBC 
connection to FactoryData [connectionSource=jdbc:sqlserver://--redacted--, 
tableName=dbo.solr_requestlog, columnConfigs=[{ name=date, layout=null, 
literal=null, timestamp=true }, { name=id, layout=%u{RANDOM}, literal=null, 
timestamp=false }, { name=logLevel, layout=%level, literal=null, 
timestamp=false }, { name=logger, layout=%logger, literal=null, timestamp=false 
}, { name=message, layout=%message, literal=null, timestamp=false }, { 
name=exception, layout=%ex{full}, literal=null, timestamp=false }], 
columnMappings=[], immediateFail=false, retry=true, 
reconnectIntervalMillis=5000, truncateStrings=true]: The 
DriverManagerConnectionSource could not load the JDBC driver 
com.microsoft.sqlserver.jdbc.SQLServerDriver: java.lang.ClassNotFoundException: 
com.microsoft.sqlserver.jdbc.SQLServerDriver

2020-05-25T10:49:08.627598771Z  java.sql.SQLException: The 
DriverManagerConnectionSource could not load the JDBC driver 
com.microsoft.sqlserver.jdbc.SQLServerDriver: java.lang.ClassNotFoundException: 
com.microsoft.sqlserver.jdbc.SQLServerDriver

2020-05-25T10:49:08.628239791Z  at 
org.apache.logging.log4j.core.appender.db.jdbc.AbstractDriverManagerConnectionSource.loadDriver(AbstractDriverManagerConnectionSource.java:203)

2020-05-25T10:49:08.628442097Z  at 
org.apache.logging.log4j.core.appender.db.jdbc.AbstractDriverManagerConnectionSource.loadDriver(AbstractDriverManagerConnectionSource.java:185)

2020-05-25T10:49:08.628637603Z  at 
org.apache.logging.log4j.core.appender.db.jdbc.AbstractDriverManagerConnectionSource.getConnection(AbstractDriverManagerConnectionSource.java:147)

2020-05-25T10:49:08.628921112Z  at 
org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager.connectAndPrepare(JdbcDatabaseManager.java:567)

2020-05-25T10:49:08.629127918Z  at 
org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager.access$800(JdbcDatabaseManager.java:62)

2020-05-25T10:49:08.629311024Z  at 
org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager$Reconnector.reconnect(JdbcDatabaseManager.java:174)

2020-05-25T10:49:08.629620834Z  at 
org.apache.logging.log4j.core.appender.db.jdbc.JdbcDatabaseManager$Reconnector.run(JdbcDatabaseManager.java:185)

2020-05-25T10:49:08.629944544Z Caused by: java.lang.ClassNotFoundException: 
com.microsoft.sqlserver.jdbc.SQLServerDriver

2020-05-25T10:49:08.630181051Z  at 
java.base/java.net.URLClassLoader.findClass(Unknown Source)

2020-05-25T10:49:08.630374057Z  at 
java.base/java.lang.ClassLoader.loadClass(Unknown Source)

2020-05-25T10:49:08.630666266Z  at 
java.base/java.lang.ClassLoader.loadClass(Unknown Source)

2020-05-25T10:49:08.630893073Z  at 
java.base/java.lang.Class.forName0(Native Method)

2020-05-25T10:49:08.631085879Z  at 
java.base/java.lang.Class.forName(Unknown Source)

2020-05-25T10:49:08.631652596Z  at 
org.apache.logging.log4j.core.appender.db.jdbc.AbstractDriverManagerConnectionSource.loadDriver(AbstractDriverManagerConnectionSource.java:201)

2020-05-25T10:49:08.631852802Z  ... 6 more



Is anyone of you able to point me to the right direction on how I need to load 
the JDBC driver for log4j2 to grab it up properly?



Thanks a lot in advance.



Kind Regards,

Florian

Log4J Logging to Http

2020-06-17 Thread Krönert Florian

Hello everyone,

We want to log our queries to a HTTP endpoint and tried configuring our log4j 
settings accordingly.
We are using Solr inside Docker with the official Solr image (version 
solr:8.3.1).

As soon as we add a http appender, we receive errors on startup and solr fails 
to start completely:

2020-06-17T07:06:54.976390509Z DEBUG StatusLogger 
JsonLayout$Builder(propertiesAsList="null", objectMessageAsJsonObject="null", 
={}, eventEol="null", compact="null", complete="null", locationInfo="null", 
properties="true", includeStacktrace="null", stacktraceAsString="null", 
includeNullDelimiter="null", ={}, charset="null", footerSerializer=null, 
headerSerializer=null, Configuration(/var/solr/log4j2.xml), footer="null", 
header="null")
2020-06-17T07:06:55.121825039Z 2020-06-17 
07:06:55.104:WARN:oejw.WebAppContext:main: Failed startup of context 
o.e.j.w.WebAppContext@611df6e3{/solr,file:///opt/solr-8.3.1/server/solr-webapp/webapp/,UNAVAILABLE}{/opt/solr-8.3.1/server/solr-webapp/webapp}
2020-06-17T07:06:55.121856339Z java.lang.NoClassDefFoundError: Failed to 
initialize Apache Solr: Could not find necessary SLF4j logging jars. If using 
Jetty, the SLF4j logging jars need to go in the jetty lib/ext directory. For 
other containers, the corresponding directory should be used. For more 
information, see: http://wiki.apache.org/solr/SolrLogging

It seems that only when using the http appender these jars are needed, without 
this appender everything works.
Can you point me in the right direction, where I need to place the needed jars? 
Seems to be a little special since I only access the /var/solr mount directly, 
the rest is running in docker.

Kind Regards,

Florian Krönert
Senior Software Developer

[cid:image001.gif@01D6448A.53F24410]
ORBIS AG | Planckstraße 10 | D-88677 Markdorf
Phone: +49 7544 50398 21 | Mobile: +49 162 3065972 | E-Mail: 
florian.kroen...@orbis.de
www.orbis.de

[cid:image002.png@01D6448A.53F24410] 
   [cid:image003.jpg@01D6448A.53F24410]

Registered Seat: Saarbrücken
Commercial Register Court: Amtsgericht Saarbrücken, HRB 12022
Board of Management: Thomas Gard (Chairman), Michael Jung, Stefan Mailänder, 
Frank Schmelzer
Chairman of the Supervisory Board: Ulrich Holzer
[cid:image004.png@01D6448A.53F24410]   
[cid:image005.png@01D6448A.53F24410] 

[cid:image006.png@01D6448A.53F24410]    
 [cid:image007.png@01D6448A.53F24410] 
[cid:image008.png@01D6448A.53F24410] 

[cid:image009.png@01D6448A.53F24410]

[cid:image010.png@01D6448A.53F24410]


[cid:EBanner_MS_Workshops_650x130px_6d91b97b-fc83-4ac1-9fd1-36a1a2fc2cc1.png]

RE: Log4J Logging to Http

2020-06-23 Thread Krönert Florian

Hi Radu,

thanks for your response.
Your different approach is very valuable to me, so thanks for suggesting it.

I'll take a look at the different tools you suggested. I hope there is some 
small and efficient solution for doing this, since throwing a whole Logstash, 
ElasticSearch and Kibana stack on top of it seems quite overwhelming.

Kind Regards,

Florian Krönert
Senior Software Developer


ORBIS AG | Planckstraße 10 | D-88677 Markdorf
Phone: +49 7544 50398 21 | Mobile: +49 162 3065972 | E-Mail: 
florian.kroen...@orbis.de
www.orbis.de



Registered Seat: Saarbrücken
Commercial Register Court: Amtsgericht Saarbrücken, HRB 12022
Board of Management: Thomas Gard (Chairman), Michael Jung, Stefan Mailänder, 
Frank Schmelzer
Chairman of the Supervisory Board: Ulrich Holzer






-Original Message-
From: Radu Gheorghe 
Sent: Donnerstag, 18. Juni 2020 08:24
To: solr-user@lucene.apache.org
Subject: Re: Log4J Logging to Http

Hi Florian,

I don’t know the answer to your specific question, but I would like to suggest 
a different approach. Excuse me in advance, I usually hate suggesting different 
approaches.

The reason why I suggest a different approach is because logging via HTTP can 
be blocking a thread e.g. until a timeout. I wrote a bit more here: 
https://sematext.com/blog/logging-libraries-vs-log-shippers/

In your particular case, I would let Solr log normally (to stdout) and have 
something pick the logs up from the Docker socket. I’m used to Logagent (see 
https://sematext.com/docs/logagent/installation-docker/) which can parse Solr 
logs out of the box (see 
https://github.com/sematext/logagent-js/blob/master/patterns.yml#L140). But 
there are other options, like Fluentd or Logstash.

Best regards,
Radu

> On 17 Jun 2020, at 10:33, Krönert Florian  wrote:
>
> Hello everyone,
>
> We want to log our queries to a HTTP endpoint and tried configuring our log4j 
> settings accordingly.
> We are using Solr inside Docker with the official Solr image (version 
> solr:8.3.1).
>
> As soon as we add a http appender, we receive errors on startup and solr 
> fails to start completely:
>
> 2020-06-17T07:06:54.976390509Z DEBUG StatusLogger
> JsonLayout$Builder(propertiesAsList="null",
> objectMessageAsJsonObject="null", ={}, eventEol="null",
> compact="null", complete="null", locationInfo="null",
> properties="true", includeStacktrace="null",
> stacktraceAsString="null", includeNullDelimiter="null", ={},
> charset="null", footerSerializer=null, headerSerializer=null,
> Configuration(/var/solr/log4j2.xml), footer="null", header="null")
> 2020-06-17T07:06:55.121825039Z 2020-06-17
> 07:06:55.104:WARN:oejw.WebAppContext:main: Failed startup of context
> o.e.j.w.WebAppContext@611df6e3{/solr,file:///opt/solr-8.3.1/server/sol
> r-webapp/webapp/,UNAVAILABLE}{/opt/solr-8.3.1/server/solr-webapp/webap
> p} 2020-06-17T07:06:55.121856339Z java.lang.NoClassDefFoundError:
> Failed to initialize Apache Solr: Could not find necessary SLF4j
> logging jars. If using Jetty, the SLF4j logging jars need to go in the
> jetty lib/ext directory. For other containers, the corresponding
> directory should be used. For more information, see:
> http://wiki.apache.org/solr/SolrLogging
>
> It seems that only when using the http appender these jars are needed, 
> without this appender everything works.
> Can you point me in the right direction, where I need to place the needed 
> jars? Seems to be a little special since I only access the /var/solr mount 
> directly, the rest is running in docker.
>
> Kind Regards,
>
> Florian Krönert
> Senior Software Developer
>
>
>
> ORBIS AG | Planckstraße 10 | D-88677 Markdorf
> Phone: +49 7544 50398 21 | Mobile: +49 162 3065972 | E-Mail:
> florian.kroen...@orbis.de www.orbis.de
>
>
>
>
> Registered Seat: Saarbrücken
> Commercial Register Court: Amtsgericht Saarbrücken, HRB 12022 Board of
> Management: Thomas Gard (Chairman), Michael Jung, Stefan Mailänder, Frank 
> Schmelzer
> Chairman of the Supervisory Board: Ulrich Holzer
>
>
>
>
>
>

RE: Log4J Logging to Http

2020-06-23 Thread Krönert Florian

Hi Shawn,

thanks for your response, I'll take a look, it seems the slf4j jars are missing 
in there.
The filesystem is not really something that I am going to tweak inside that 
Docker container, so I might take a look at different approaches as well.

Kind Regards,

Florian Krönert
Senior Software Developer


ORBIS AG | Planckstraße 10 | D-88677 Markdorf
Phone: +49 7544 50398 21 | Mobile: +49 162 3065972 | E-Mail: 
florian.kroen...@orbis.de
www.orbis.de



Registered Seat: Saarbrücken
Commercial Register Court: Amtsgericht Saarbrücken, HRB 12022
Board of Management: Thomas Gard (Chairman), Michael Jung, Stefan Mailänder, 
Frank Schmelzer
Chairman of the Supervisory Board: Ulrich Holzer






-Original Message-
From: Shawn Heisey 
Sent: Donnerstag, 18. Juni 2020 04:22
To: solr-user@lucene.apache.org
Subject: Re: Log4J Logging to Http

On 6/17/2020 1:33 AM, Krönert Florian wrote:
> 2020-06-17T07:06:55.121856339Z java.lang.NoClassDefFoundError: Failed
> to initialize Apache Solr: Could not find necessary SLF4j logging
> jars. If using Jetty, the SLF4j logging jars need to go in the jetty
> lib/ext directory. For other containers, the corresponding directory
> should be used. For more information, see:
> http://wiki.apache.org/solr/SolrLogging
>
> It seems that only when using the http appender these jars are needed,
> without this appender everything works.

There must be some aspect of your log4j2.xml configuration that requires a jar 
that is not included with Solr.

> Can you point me in the right direction, where I need to place the
> needed jars? Seems to be a little special since I only access the
> /var/solr mount directly, the rest is running in docker.

If there are extra jars needed for your logging config, they should go in the 
server/lib/ext directory, which should already exist and contain several jars 
related to logging.

Thanks,
Shawn

Handling Locales in Solr

2021-02-24 Thread Krönert Florian

Hi everyone,

First up thanks for this group, I appreciate it very much for exchanging 
opinions on how to use Solr.

We built a Solr instance for one of our customers which is used for searching 
data on his website.
We need to search different data (kb articles, products and external links) in 
different locales.

For our logic it seemed best to separate solr Cores by topic and locale, so we 
have cores like this:
kbarticle_de-de
kbarticle_en-us
...
products_de-de
products_en-us
...
links_de-de
links_en-us

First we had only 3 locales, but it grew pretty fast to 16 locales, so that 
we're having 48 solr cores by now already.
There would have been different approaches for realizing this of course, so 
we're wondering whether we are using Solr not in the optimal way?

We found out that when a search on a locale that was not used for some time is 
started, it takes >10 seconds in many cases to execute the search.

We then find logs like this, where it seems as if Solr needs to start a 
searcher first, which takes time:
2021-02-20 04:33:42.634 INFO  (Thread-20674) [   ] o.a.s.s.SolrIndexSearcher 
Opening [Searcher@775f8595[kbarticles_en-gb] main]
2021-02-20 04:33:42.643 INFO  (searcherExecutor-26-thread-1) [   ] 
o.a.s.c.QuerySenderListener QuerySenderListener sending requests to 
Searcher@775f8595[kbarticles_en-gb]
...

Is that an issue? It would be good to know whether our localization approach 
causes issues with Solr and whether we should restructure our core design.
Any help would be very much appreciated.

Kind Regards,

Florian Krönert
Senior Software Developer

[cid:image001.gif@01D70AA4.14778350]
ORBIS AG | Planckstraße 10 | D-88677 Markdorf
Phone: +49 7544 50398 21 | Mobile: +49 162 3065972 | E-Mail: 
florian.kroen...@orbis.de
www.orbis.de

[cid:image002.png@01D70AA4.14778350] 
   [cid:image003.jpg@01D70AA4.14778350]

Registered Seat: Saarbrücken
Commercial Register Court: Amtsgericht Saarbrücken, HRB 12022
Board of Management: Thomas Gard (Chairman), Michael Jung, Stefan Mailänder, 
Frank Schmelzer
Chairman of the Supervisory Board: Ulrich Holzer
[cid:image004.png@01D70AA4.14778350]   
[cid:image005.png@01D70AA4.14778350] 

[cid:image006.png@01D70AA4.14778350]    
 [cid:image007.png@01D70AA4.14778350] 
[cid:image008.png@01D70AA4.14778350] 

[cid:image009.png@01D70AA4.14778350]

[cid:image010.png@01D70AA4.14778350]


[cid:MicrosoftPowerPlatform_7054080f-b0bf-4e97-b9ab-55dae1373165.png]

[cid:Microsoftallgemein_e6028b0b-75cc-43da-9046-9fec28faad6d.png]

RE: Handling Locales in Solr

2021-02-25 Thread Krönert Florian

Hi Markus,

thank you a lot for your response, that helps us very much.

We will try out the approach of separating the cores by topic only.

Kind Regards,
Florian 

-Original Message-
From: Markus Jelsma  
Sent: Mittwoch, 24. Februar 2021 12:27
To: solr-user@lucene.apache.org
Subject: Re: Handling Locales in Solr

Hello,

We put all our customers in the same core/collection because of this, it is not 
practical to manage hundreds of cores, including their small overhead.
Although it can be advantageous when it comes to relevance tuning, no skewed 
statistics because of other customers.

In your case, an unused core is probably slow because it is not in cached 
memory anymore, and/or it has to load from a slow drive.

With regards to the locales, i would probably separate the cores by topic only, 
and have different languages share the same collection/core.

Regards,
Markus



Op wo 24 feb. 2021 om 12:09 schreef Krönert Florian <
florian.kroen...@orbis.de>:

> Hi everyone,
>
>
>
> First up thanks for this group, I appreciate it very much for 
> exchanging opinions on how to use Solr.
>
>
>
> We built a Solr instance for one of our customers which is used for 
> searching data on his website.
>
> We need to search different data (kb articles, products and external
> links) in different locales.
>
>
>
> For our logic it seemed best to separate solr Cores by topic and 
> locale, so we have cores like this:
>
> kbarticle_de-de
>
> kbarticle_en-us
>
> …
>
> products_de-de
>
> products_en-us
>
> …
>
> links_de-de
>
> links_en-us
>
>
>
> First we had only 3 locales, but it grew pretty fast to 16 locales, so 
> that we’re having 48 solr cores by now already.
>
> There would have been different approaches for realizing this of 
> course, so we’re wondering whether we are using Solr not in the optimal way?
>
>
>
> We found out that when a search on a locale that was not used for some 
> time is started, it takes >10 seconds in many cases to execute the search.
>
>
>
> We then find logs like this, where it seems as if Solr needs to start 
> a searcher first, which takes time:
>
> 2021-02-20 04:33:42.634 INFO  (Thread-20674) [   ]
> o.a.s.s.SolrIndexSearcher Opening [Searcher@775f8595[kbarticles_en-gb]
> main]
>
> 2021-02-20 04:33:42.643 INFO  (searcherExecutor-26-thread-1) [   ]
> o.a.s.c.QuerySenderListener QuerySenderListener sending requests to 
> Searcher@775f8595[kbarticles_en-gb]
>
> …
>
>
>
> Is that an issue? It would be good to know whether our localization 
> approach causes issues with Solr and whether we should restructure our 
> core design.
>
> Any help would be very much appreciated.
>
>
>
> Kind Regards,
>
>
>
> *Florian Krönert*
> Senior Software Developer
>
> <https://www.orbis.de/de.html>
>
> *ORBIS AG | *Planckstraße 10 | D-88677 Markdorf
>
> Phone: +49 7544 50398 21 | Mobile: +49 162 3065972 | E-Mail:
> florian.kroen...@orbis.de
> www.orbis.de
>
>
> <https://www.orbis.de/de/sap-by-orbis.html>
>
> Registered Seat: Saarbrücken
> Commercial Register Court: Amtsgericht Saarbrücken, HRB 12022 Board of 
> Management: Thomas Gard (Chairman), Michael Jung, Stefan Mailänder, 
> Frank Schmelzer Chairman of the Supervisory Board: Ulrich Holzer
>
> <https://www.facebook.com/ORBIS.AG>
> <https://www.linkedin.com/company/orbis-ag/>
> <https://www.xing.com/companies/orbisag><https://twitter.com/ORBIS_AG>
> 
> <https://www.youtube.com/channel/UC5Fx5UsUy4FkzB0dfCWXwYw/featured>
>
>
>
>
> <https://www.orbis.de/de/aktuelles/news/aktuelle-presse/news-detail/ar
> ticle/inner-circle-award-orbis-zaehlt-erneut-zu-den-weltbesten-partner
> n-fuer-microsoft-business-application.html>
>
>
>
>
> <https://www.orbis.de/de/microsoft-by-orbis/beratungskompetenz/power-p
> latform.html?wmc=Banner-Microsoft-Power-Platform>
>
>
> <https://www.orbis.de/de/microsoft-by-orbis.html?wmc=Banner-Microsoft-
> by-ORBIS>
>

RE: Log slow queries to SQL Database using Log4j2 (JDBC)

Log slow queries to SQL Database using Log4j2 (JDBC)

Log4J Logging to Http

RE: Log4J Logging to Http

RE: Log4J Logging to Http

Handling Locales in Solr

RE: Handling Locales in Solr

7 matches

Site Navigation

Mail list logo

Footer information