[Logo] JCVSForum - Community Support For JCVS Users and Developers
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Messages posted by: jcvslist
Forum Index » Profile for jcvslist » Messages posted by jcvslist
Author Message
<pre>
> During a checkout of a (very) large project I get:
>
> Exception occurred during event dispatching:
> java.lang.OutOfMemoryError

(Just a wild guess.
I got this error often when trying to reuse StringBuffers and
setting their size to zero.)

Try increasing the heap size for jCVS in the java call (parameter -mx on
Unix)

Cheers,
Jochen

</pre>
<pre>On Tue, Sep 15 1998, Neal A. Dillman wrote:
> During a checkout of a (very) large project I get:
>
> Exception occurred during event dispatching:
> java.lang.OutOfMemoryError
> at java.io.BufferedReader.<init>(Compiled Code)
> at java.io.BufferedReader.<init>(Compiled Code)
> at com.ice.cvsc.CVSProject.copyFileAscii(Compiled Code)
> at com.ice.cvsc.CVSProject.copyFile(Compiled Code)
> [ ... ]
> at java.awt.EventDispatchThread.run(Compiled Code)
>
> Does anyone have a suggestion? The platform is hp-ux.

Well, at some point it would be useful to know if the memory being
consumed is necessary, or if we can free up some things.

That point aside, you need to look into the -mx and -ms options
used to start java. -mx is the max memory, -ms is the starting.
You might try something along the lines of:

java -ms16m -mx64m -classpath ....

Which would up the maximum available memory to 64MB and start
the program out with 16MB.

tim.
Tim Endres, ICE Engineering, Inc.
mailto: time@ice.com http://www.ice.com
"Usenet - A slow moving self parody." -- Peter Honeyman

</pre>
<pre>Neal A. Dillman wrote:
>
> During a checkout of a (very) large project I get:
>
> Exception occurred during event dispatching:
> java.lang.OutOfMemoryError
> at java.io.BufferedReader.<init>(Compiled Code)
>...
> at java.awt.EventDispatchThread.run(Compiled Code)
>
> Does anyone have a suggestion? The platform is hp-ux.
>

I also get the same problem on NT4 SP3 w/Sun java 1.1.6 FWIW.

--
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
- Neal A. Dillman * neald@rose.hp.com -
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
- My opinions are. -
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

</pre>
<pre>During a checkout of a (very) large project I get:

Exception occurred during event dispatching:
java.lang.OutOfMemoryError
at java.io.BufferedReader.<init>(Compiled Code)
at java.io.BufferedReader.<init>(Compiled Code)
at com.ice.cvsc.CVSProject.copyFileAscii(Compiled Code)
at com.ice.cvsc.CVSProject.copyFile(Compiled Code)
at com.ice.cvsc.CVSProject.updateLocalFile(Compiled Code)
at com.ice.cvsc.CVSProject.processResponseItem(Compiled Code)
at com.ice.cvsc.CVSProject.handleResponseItem(Compiled Code)
at com.ice.cvsc.CVSClient.processResponseItem(Compiled Code)
at com.ice.cvsc.CVSClient.readAndParseResponse(Compiled Code)
at com.ice.cvsc.CVSClient.processCVSRequest(Compiled Code)
at com.ice.cvsc.CVSProject.performCVSRequest(Compiled Code)
at com.ice.jcvs.CVSProjectFrame.commonCVSCommand(Compiled Code)
at com.ice.jcvs.CVSProjectFrame.performCheckOut(Compiled Code)
at com.ice.jcvs.CVSCheckoutDialog.actionPerformed(Compiled Code)
at java.awt.Button.processActionEvent(Compiled Code)
at java.awt.Button.processEvent(Compiled Code)
at java.awt.Component.dispatchEventImpl(Compiled Code)
at java.awt.Component.dispatchEvent(Compiled Code)
at java.awt.EventDispatchThread.run(Compiled Code)

Does anyone have a suggestion? The platform is hp-ux.

-Neal-

--
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
- Neal A. Dillman * neald@rose.hp.com -
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
- My opinions are. -
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

</pre>
<pre>On Mon, Aug 23 1999, Erskine, Chris wrote:
Erskin> I seem to have a problem working in an CVS environment with jCVS. Using
Erskin> jCVS, I have checked out the module. I then go and make changes to a
file
Erskin> and then do a project update and commit. When I do this, I lose the
changes
Erskin> that I have done to the file and it reverts back to the version which is
in
Erskin> the repository. What am I doing wrong?

Sounds like, for a reason that I do not know, that the update is reverting the
file.
You should try doing a commit with the prior update. Maybe you have a sticky tag
that
is causing the update to do what it is. If you could send a trace of the
protocol, I
could make more sense of it.

What happens if you select the file by itself and do "Selection -> Commit"?

Tim Endres - time@ice.com
ICE Engineering, Inc. - http://www.ice.com/
"USENET - a slow moving self parody." - Peter Honeyman

</pre>
<pre>I seem to have a problem working in an CVS environment with jCVS. Using
jCVS, I have checked out the module. I then go and make changes to a file
and then do a project update and commit. When I do this, I lose the changes
that I have done to the file and it reverts back to the version which is in
the repository. What am I doing wrong?

Chris Erskine
CSSC
chris.erskine@eds.com
719-533-2069


</pre>
<pre>On Fri, Sep 11 1998, Simon Macdonald wrote:
> Thanks for taking the time to work on a neat program like jCVS. I think it
> will be very benificial to my work. Unfortunately, I'm having some startup
> problems. I can use cvs commands on UNIX fine and I can use the test
> connection dialog box in jCVS to make sure the server is running but when I
> try to do an import I get a weird error.
>
> cvs [server aborted]: gunzip exited 256
>
> Short response, no status response from server.

Your gzip is not happy with the data stream. Not sure why.

This is the result of a new feature in jCVS 4.7 that includes the ability
to GZIP the files when transferred to save bandwidth. You can disable this
via the "Allow Compression" checkbox menu item in the File menu in the
Project window. Or you can disable it permanently by placing:
jCVS.global.allowGzipFileMode=true
in your "jcvsrc" file.

tim.
Tim Endres, ICE Engineering, Inc.
mailto: time@ice.com http://www.ice.com
"Usenet - A slow moving self parody." -- Peter Honeyman

</pre>
<pre>On Fri, Sep 11 1998, Tomas Fasth wrote:
> As a curious matter, something seem less than optimal when a null pointer
> exception occurs. And I who thought null pointer bugs became obsolete in
> Java code. Is there possibly a former C programmer luring behind the
> curtains?

Java has the concept of a null object and specifically defines 'null'.
Thus, NullPointerException is an inevitability.

Oh, sure, I could just write perfect code, but where,
then, would be the excitement? 8^)

I have fixed the code.

tim.
Tim Endres, ICE Engineering, Inc.
mailto: time@ice.com http://www.ice.com
"Usenet - A slow moving self parody." -- Peter Honeyman

</pre>
<pre>Sorry for blaming jCVS, guys.
I just ran the command line version of cvs which also failed.
The message is: Fatal error, aborting. 501: no such user
Which of course was reported in the cvslog.txt file as well (I just found
this excellent file .
Oh well, nothing to do but dwelving into my server config then... Strange,
client-server checkouts works okay on my linux box. What to do now? I'm
trying to run jCVS on M$NT4 by the way. Not my favorite platform if you
ask...
As a curious matter, something seem less than optimal when a null pointer
exception occurs. And I who thought null pointer bugs became obsolete in
Java code. Is there possibly a former C programmer luring behind the
curtains?

Tomas


</pre>
<pre>Hi.
I just downloaded and installed jCVS 4.7.3.
While trying to communicate with the cvs server (performing a checkout) I
repeatedly get the following exception report as console output:

Exception occurred during event dispatching:
java.lang.NullPointerException
at com.ice.cvsc.CVSClient.processCVSRequest(CVSClient.java:1240)
at com.ice.cvsc.CVSProject.performCVSRequest(CVSProject.java:1183)
at
com.ice.jcvs.CVSProjectFrame.commonCVSCommand(CVSProjectFrame.java:1345)
at
com.ice.jcvs.CVSProjectFrame.performCheckOut(CVSProjectFrame.java:956)
at
com.ice.jcvs.CVSCheckoutDialog.actionPerformed(CVSCheckoutDialog.java:354)
at java.awt.Button.processActionEvent(Button.java:257)
at java.awt.Button.processEvent(Button.java:230)
at java.awt.Component.dispatchEventImpl(Compiled Code)
at java.awt.EventDispatchThread.run(Compiled Code)

Testing the connection gives similar results (with CVSCheckoutDialog
replaced with CVSTestConnectionDIalog).

What am I doing wrong?
Any hints on how to get past this obstacle?

Oh, almost forgot to mention. I have tried both jre-1.1.6 and jre-1.2b4.

Thanks,
Tomas


</pre>
<pre>On Fri, Sep 11 1998, Neal A. Dillman wrote:
> That's possible. The same problem color scheme is used:
> *) in the checkout dialog (export, import, etc)
> *) in the output viewer
>
> It's not a problem:
> *) in the login dialog
> *) anywhere in the project window (including the menus!)

Ooooohhhh... That is inconsistent.
I will try to look into that a bit.

> > This is usually the result of timezone issues in the JDK. Check the
> > properties (<HOME>/jcvsrc.txt is where you override them, defaults.txt
> > in the source code will show you what's there. You might have to set
> > the timezone string to something other than "GMT". Maybe "GMT+00".
>
> I figured the same, and had already tried PST8PDT and GMT+08 before
> sending the mail. Your response gave me a hint though. It turns out
> that GMT works.. as well as PST. PDT or anything with a number in it
> seems to fail. Do you know of any way to ask Java what timezones are
> available?

Ok, you got it. This timestamp/timezone thing changed (and incompatibly)
between 1.1.4 and 1.1.5, if I remember correctly. A real pain, it has been.

tim.
Tim Endres, ICE Engineering, Inc.
mailto: time@ice.com http://www.ice.com
"Usenet - A slow moving self parody." -- Peter Honeyman

</pre>
<pre>On Wed, Sep 9 1998, Neal A. Dillman wrote:
> 1) The color for the menus on the main window (as well as other places)
> is white on white when unselected. This makes it difficult (impossible
> actually) to read. The menus are somewhat readable when they are
> selected. I did not see an option in the code to change this.

Interesting. Sounds like AWT's responsibility, the peering being less
than ideal?

> 2) When I try to do a checkout I get:
> Exception occurred during event dispatching:
> java.lang.NullPointerException
> at java.util.GregorianCalendar.computeFields(Compiled Code)
> at java.util.Calendar.setTimeInMillis(Calendar.java)
> at java.util.Calendar.setTime(Calendar.java)
> at java.text.SimpleDateFormat.format(Compiled Code)
> at java.text.DateFormat.format(DateFormat.java)

This is usually the result of timezone issues in the JDK. Check the
properties (<HOME>/jcvsrc.txt is where you override them, defaults.txt
in the source code will show you what's there. You might have to set
the timezone string to something other than "GMT". Maybe "GMT+00".

</pre>
<pre>Hi,

I have used jCVS [at home] on OS/2 a few times, and have been quite
impressed. I am hoping to use it at work as well. I have run into two
problems:

1) The color for the menus on the main window (as well as other places)
is white on white when unselected. This makes it difficult (impossible
actually) to read. The menus are somewhat readable when they are
selected. I did not see an option in the code to change this.

2) When I try to do a checkout I get:
Exception occurred during event dispatching:
java.lang.NullPointerException
at java.util.GregorianCalendar.computeFields(Compiled Code)
at java.util.Calendar.setTimeInMillis(Calendar.java)
at java.util.Calendar.setTime(Calendar.java)
at java.text.SimpleDateFormat.format(Compiled Code)
at java.text.DateFormat.format(DateFormat.java)
at
com.ice.cvsc.CVSTimestampFormat.formatTimeZone(CVSTimestampFormat.java:109)
at
com.ice.cvsc.CVSTimestampFormat.format(CVSTimestampFormat.java:94)
at com.ice.cvsc.CVSEntry.setTimestamp(CVSEntry.java:363)
at com.ice.cvsc.CVSProject.processResponseItem(Compiled Code)
at com.ice.cvsc.CVSProject.handleResponseItem(Compiled Code)
at com.ice.cvsc.CVSClient.processResponseItem(Compiled Code)
at com.ice.cvsc.CVSClient.readAndParseResponse(Compiled Code)
at com.ice.cvsc.CVSClient.processCVSRequest(Compiled Code)
at com.ice.cvsc.CVSProject.performCVSRequest(Compiled Code)
at com.ice.jcvs.CVSProjectFrame.commonCVSCommand(Compiled Code)
at com.ice.jcvs.CVSProjectFrame.performCheckOut(Compiled Code)
at com.ice.jcvs.CVSCheckoutDialog.actionPerformed(Compiled Code)
at java.awt.Button.processActionEvent(Compiled Code)
at java.awt.Button.processEvent(Compiled Code)
at java.awt.Component.dispatchEventImpl(Compiled Code)
at java.awt.Component.dispatchEvent(Compiled Code)
at java.awt.EventDispatchThread.run(Compiled Code)

My platform is:
HP-UX Java C.01.15.05 08/06/98
HP-UX B.10.20 A 9000/712

I am using pserver (not rsh/remsh).

Has anyone go jcvs working properly on HP-UX?


-Neal-

--
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
- Neal A. Dillman * neald@rose.hp.com -
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
- My opinions are. -
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

</pre>
<pre>Tim Endres wrote:
> Can you expound on why it would be onerous?
>
> There are two ways to extend jCVS's I/O stream, which seem to accomodate
> most needs. The first is to replace the I/O internally with a Java package,
> or to use an exec() of a process that handles the I/O via stdio. The latter
> method is what some folks use for SSH connectivity.

The second method is what I referred to as "through external systems" in
the prior mail. This is less desirable, as I am attempting the make the
repository completely black box -- ie: user's home directories are set
to /dev/null, and their shells are set to /bin/false. The thoery there
being that if users can't log in it is a bit tougher for them to
[unintentionally] rm -rf the repository.

Replacing the internal IO would likely be onerous because I would need
to write a package that has clean access to gssapi's existing
credentials. That would mean having java read the credential cache,
request the cvs ticket, etc. Then again, this may have already been
written by someone.



Regards,
Neal

--
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
- Neal A. Dillman * neald@rose.hp.com -
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
- My opinions are. -
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

</pre>
<pre>On Fri, Sep 11 1998, Neal A. Dillman wrote:
> In our environment, I am hoping to move to gserver. Unfortunately I
> have been (as yet) unsuccessful in getting the server ported to run with
> HP's DCE. Even then, I would probebly want to add GSS-API support to
> jcvs (which is probably possible, but an onerus [SP?] task).

Can you expound on why it would be onerous?

There are two ways to extend jCVS's I/O stream, which seem to accomodate
most needs. The first is to replace the I/O internally with a Java package,
or to use an exec() of a process that handles the I/O via stdio. The latter
method is what some folks use for SSH connectivity.

tim.
Tim Endres, ICE Engineering, Inc.
mailto: time@ice.com http://www.ice.com
"Usenet - A slow moving self parody." -- Peter Honeyman

</pre>
 
Forum Index » Profile for jcvslist » Messages posted by jcvslist
Go to:   
Powered by JForum 2.1.9 © JForum Team