How to inspect the problem.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

How to inspect the problem.

Igor Czechowski
HI

Today, one of the users has deployed artifact over scp. I was able to
find the artifact with UI. However, when I selected download, Nexus
responded with item not found. I have verified the artifact is in the
correct directory and should be accessible. Unfortunately, logs
weren't of help  since there was no problem logged. This instance
version is beta-2 and was running for month or so.
Second instance beta-3 which share storage with beta-2 was able to
serve the artifact without problems.

I've bounced beta-2 instance and it has started to serve the artifact,
which previously was reported as not found.

How can I inspect such problems in the future without shutting down
the repository ?
Is it possible to dynamically change log4j properties to DEBUG without
a restart ?
What are the best log4j properties to catch the problematic point ?

Thanks for any help
  Igor

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to inspect the problem.

Tamas Cservenak
Igor,

the beta-2 instance was probably picked that artifact into NFC (not found cache) already. By bouncing beta-2, you cleared the NFC, hence it started to serve it. NFC is not persisted by default.

In cases like this, the ClearCache action should be used, that clears the NFC too (from the given path and below).

But, please keep in mind that we encourage you to always update to the latest release of Nexus, especially in this alpha/beta phase. Beta2 was long ago... :)

Changing log level on-the-fly is currently not possible :(
And it depends. DEBUG contains all (it would tell you about NFC too...), but is way chatty, to be used in production...

In this case, you could try to listen for "org.sonatype.nexus.proxy.repository.Repository:maven2" logger in DEBUG level.

~t~


On Thu, 2008-06-12 at 16:04 +0200, Igor Czechowski wrote:
HI

Today, one of the users has deployed artifact over scp. I was able to
find the artifact with UI. However, when I selected download, Nexus
responded with item not found. I have verified the artifact is in the
correct directory and should be accessible. Unfortunately, logs
weren't of help  since there was no problem logged. This instance
version is beta-2 and was running for month or so.
Second instance beta-3 which share storage with beta-2 was able to
serve the artifact without problems.

I've bounced beta-2 instance and it has started to serve the artifact,
which previously was reported as not found.

How can I inspect such problems in the future without shutting down
the repository ?
Is it possible to dynamically change log4j properties to DEBUG without
a restart ?
What are the best log4j properties to catch the problematic point ?

Thanks for any help
  Igor

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: How to inspect the problem.

justinedelson
Tamas-
Have you thought about exposing the Log4j instance via JMX? That would enable the runtime switching of log levels.
 
Justin


From: Tamas Cservenak [mailto:[hidden email]]
Sent: Thu 6/12/2008 8:28 PM
To: [hidden email]
Subject: Re: [nexus-user] How to inspect the problem.

Igor,

the beta-2 instance was probably picked that artifact into NFC (not found cache) already. By bouncing beta-2, you cleared the NFC, hence it started to serve it. NFC is not persisted by default.

In cases like this, the ClearCache action should be used, that clears the NFC too (from the given path and below).

But, please keep in mind that we encourage you to always update to the latest release of Nexus, especially in this alpha/beta phase. Beta2 was long ago... :)

Changing log level on-the-fly is currently not possible :(
And it depends. DEBUG contains all (it would tell you about NFC too...), but is way chatty, to be used in production...

In this case, you could try to listen for "org.sonatype.nexus.proxy.repository.Repository:maven2" logger in DEBUG level.

~t~


On Thu, 2008-06-12 at 16:04 +0200, Igor Czechowski wrote:
HI

Today, one of the users has deployed artifact over scp. I was able to
find the artifact with UI. However, when I selected download, Nexus
responded with item not found. I have verified the artifact is in the
correct directory and should be accessible. Unfortunately, logs
weren't of help  since there was no problem logged. This instance
version is beta-2 and was running for month or so.
Second instance beta-3 which share storage with beta-2 was able to
serve the artifact without problems.

I've bounced beta-2 instance and it has started to serve the artifact,
which previously was reported as not found.

How can I inspect such problems in the future without shutting down
the repository ?
Is it possible to dynamically change log4j properties to DEBUG without
a restart ?
What are the best log4j properties to catch the problematic point ?

Thanks for any help
  Igor

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: How to inspect the problem.

Franklin, Martin (SD)

Or just use PropertyConfigurator. configureAndWatch

 

http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PropertyConfigurator.html#configureAndWatch(java.lang.String)

 

This will spawn a thread to watch the log4j.properties file and autoreload it when/if the file is edited.

 

Martin

 

From: Edelson, Justin [mailto:[hidden email]]
Sent: Thursday, June 12, 2008 6:53 PM
To: [hidden email]
Subject: RE: [nexus-user] How to inspect the problem.

 

Tamas-

Have you thought about exposing the Log4j instance via JMX? That would enable the runtime switching of log levels.

 

Justin

 


From: Tamas Cservenak [mailto:[hidden email]]
Sent: Thu 6/12/2008 8:28 PM
To: [hidden email]
Subject: Re: [nexus-user] How to inspect the problem.

Igor,

the beta-2 instance was probably picked that artifact into NFC (not found cache) already. By bouncing beta-2, you cleared the NFC, hence it started to serve it. NFC is not persisted by default.

In cases like this, the ClearCache action should be used, that clears the NFC too (from the given path and below).

But, please keep in mind that we encourage you to always update to the latest release of Nexus, especially in this alpha/beta phase. Beta2 was long ago... :)

Changing log level on-the-fly is currently not possible :(
And it depends. DEBUG contains all (it would tell you about NFC too...), but is way chatty, to be used in production...

In this case, you could try to listen for "org.sonatype.nexus.proxy.repository.Repository:maven2" logger in DEBUG level.

~t~


On Thu, 2008-06-12 at 16:04 +0200, Igor Czechowski wrote:

HI
 
Today, one of the users has deployed artifact over scp. I was able to
find the artifact with UI. However, when I selected download, Nexus
responded with item not found. I have verified the artifact is in the
correct directory and should be accessible. Unfortunately, logs
weren't of help  since there was no problem logged. This instance
version is beta-2 and was running for month or so.
Second instance beta-3 which share storage with beta-2 was able to
serve the artifact without problems.
 
I've bounced beta-2 instance and it has started to serve the artifact,
which previously was reported as not found.
 
How can I inspect such problems in the future without shutting down
the repository ?
Is it possible to dynamically change log4j properties to DEBUG without
a restart ?
What are the best log4j properties to catch the problematic point ?
 
Thanks for any help
  Igor
 
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
 
Reply | Threaded
Open this post in threaded view
|

RE: How to inspect the problem.

Brian E. Fox

Thanks for the pointers, I’d like to make the log config changeable from the UI…this should make it possible. We still need to get all the logs pulled together into a single logger…REST is still using j-u-l.

 

From: Franklin, Martin (SD) [mailto:[hidden email]]
Sent: Thursday, June 12, 2008 10:34 PM
To: [hidden email]
Subject: RE: [nexus-user] How to inspect the problem.

 

Or just use PropertyConfigurator. configureAndWatch

 

http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PropertyConfigurator.html#configureAndWatch(java.lang.String)

 

This will spawn a thread to watch the log4j.properties file and autoreload it when/if the file is edited.

 

Martin

 

From: Edelson, Justin [mailto:[hidden email]]
Sent: Thursday, June 12, 2008 6:53 PM
To: [hidden email]
Subject: RE: [nexus-user] How to inspect the problem.

 

Tamas-

Have you thought about exposing the Log4j instance via JMX? That would enable the runtime switching of log levels.

 

Justin

 


From: Tamas Cservenak [mailto:[hidden email]]
Sent: Thu 6/12/2008 8:28 PM
To: [hidden email]
Subject: Re: [nexus-user] How to inspect the problem.

Igor,

the beta-2 instance was probably picked that artifact into NFC (not found cache) already. By bouncing beta-2, you cleared the NFC, hence it started to serve it. NFC is not persisted by default.

In cases like this, the ClearCache action should be used, that clears the NFC too (from the given path and below).

But, please keep in mind that we encourage you to always update to the latest release of Nexus, especially in this alpha/beta phase. Beta2 was long ago... :)

Changing log level on-the-fly is currently not possible :(
And it depends. DEBUG contains all (it would tell you about NFC too...), but is way chatty, to be used in production...

In this case, you could try to listen for "org.sonatype.nexus.proxy.repository.Repository:maven2" logger in DEBUG level.

~t~


On Thu, 2008-06-12 at 16:04 +0200, Igor Czechowski wrote:

HI
 
Today, one of the users has deployed artifact over scp. I was able to
find the artifact with UI. However, when I selected download, Nexus
responded with item not found. I have verified the artifact is in the
correct directory and should be accessible. Unfortunately, logs
weren't of help  since there was no problem logged. This instance
version is beta-2 and was running for month or so.
Second instance beta-3 which share storage with beta-2 was able to
serve the artifact without problems.
 
I've bounced beta-2 instance and it has started to serve the artifact,
which previously was reported as not found.
 
How can I inspect such problems in the future without shutting down
the repository ?
Is it possible to dynamically change log4j properties to DEBUG without
a restart ?
What are the best log4j properties to catch the problematic point ?
 
Thanks for any help
  Igor
 
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]