Re: Building isapi_redirect on Win 2003

2005-10-07 Thread Mladen Turk

Lyndon Tiu wrote:

Hello,

I read the instructions on how to build isapi_redirect.dll on:

http://jakarta.apache.org/tomcat/connectors-doc-archive/jk2/jk/iishowto.html

But I am getting these errors:

C:\tmp\jakarta-tomcat-connectors-1.2.14.1-src\jk\native\iismsdev isapi.dsp 
/make all
Configuration: isapi - Win32 Release
Compiling...
jk_isapi_plugin.c
C:\tmp\jakarta-tomcat-connectors-1.2.14.1-src\jk\native\iis\jk_isapi_plugin.c(658)
 : error C2065: 'S
F_NOTIFY_AUTH_COMPLETE' : undeclared identifier


You will need the Platform SDK at least from March 2003.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] 5.5.12 Stability

2005-10-05 Thread Mladen Turk

Yoav Shapira wrote:

Tomcat 5.5.12 is:
[X] Stable - no major issues,
[ ] Beta - at least one major issue: what is it?
[ ] Alpha - multiple things or a real showstopper: please provide details..



Works like magic, really :)
Tested with tomcat-native on
WIN32, WIN64, Solaris 2.8 and SLES9/64

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[VOTE] JK 1.2.15

2005-09-29 Thread Mladen Turk

Hi,

JK 1.2.15 has been tagged last week.
Please see the:
http://jakarta.apache.org/tomcat/connectors-doc/changelog.html
for a full list of changes.


Sources can be found at:
http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.15/


Please vote:

[ ] Stable -- good build
[ ] Alpha -- something serious is wrong: what is it?

Regards,
Mladen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: What is correct for workers.properties.minimal

2005-09-28 Thread Mladen Turk

David Thielen wrote:

Hi;

First, what use is the load balancing if I have just one server running one
instance of Tomcat? Does it load balance within that one instance?

Second, what is jkstatus for?



Jkstatus is used for displaying and managing load balancers and load
balancer members.
Since it can manage only the workers that are members of load balancer
that simple configuration has been made as an example.

If there is a single worker as member of load balancer the performance
will be the same, because in that case the entire lb election phases
are simply skipped. Of course you have the option to manage your
worker at runtime.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



CVS-SVN Schedule

2005-09-28 Thread Mladen Turk

Hi,

Any update on the schedule?
I have couple of fixes, commits, etc, but
IIUC the transition should happen last weekend,
so I've postpone all that, but it seems that CVS is
still operational.

Can somebody make a firm statement on the timings?
1. Until when (Date:Hour:Minute) commits could be done
2. Wen the CVS will be locked for commit (same format)


Regards,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



JK 1.2.15 Release plan?

2005-09-26 Thread Mladen Turk

Hi,

JK 1.2.15 has been tagged, and I've created the source
distribution downloadable from the:
http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.15/

Since this version contains numerous bug fixes over the releases 1.2.14,
what are your thoughts on that version, since it will be the last one
released from the CVS.

I would like to make a vote and release, because of the bugs this
version is fixing, and since we would from now on use SVN the next
release could take quite some time before becoming available.

So, should I pursue for a [VOTE} on that tag or will we wait for
a couple of months? I hope we'll not go for the latest option.

Regards,
Mladen.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JK 1.2.15 Release plan?

2005-09-26 Thread Mladen Turk

Yoav Shapira wrote:

Hi,
I'd wait a couple of days and then have a vote.  During those days we should
actively encourage users to download and test it.  Make release announcements,
etc. ;)



Right. I was deliberately choose the 'WTF' approach to the release
subject, because each time I try something like that the wrowe comes
in reminding me of the 'procedural misbehaving' :)

So, excuse me if I broke again some f*ing rule.

Anyhow, I would like that we vote this (1.2.15) version as stable,
because it's a bug-fix release over the 1.2.14 stable.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing JK 1.2.15

2005-09-23 Thread Mladen Turk

There has been couple of major bug fixes
against 1.2.14, see:
http://jakarta.apache.org/tomcat/connectors-doc/changelog.html

They have been fixed in the CVS, and since
couple of them actually makes 1.2.14 unusable on
some platforms like Solaris 2.8 and Irix we need a release.

I plan to tag the 1.2.15 by the end of this week, and pursue
for a vote next week for this bug-fixing release.

Any objections?



Since there were no objections I plan to tag the 1.2.15 later this
evening at 19:00 GMT.

This will eventually be the last release from CVS, cause IIUC the
transition will be made this weekend.


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing JK 1.2.15

2005-09-23 Thread Mladen Turk

Peter Rossbach wrote:

Hey Mladen,

can we also integrate the better domain loadbalancer support at 
jk_lb_worker.c?
I think that we don't change the lb_value inside sticky mode at every 
request.


Yes we do. They will be updated only for domain workers.
This is needed to load balance between the workers that are
members of the same domain. In other case the total_factor will
be zero and lb_value will not be changed.


Regards,
Mladen.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing JK 1.2.15

2005-09-23 Thread Mladen Turk

Rainer Jung wrote:

Hi Peter, Mladen and all others,

I would like to follow Mladens suggestion from earlier this month to
create a list of precise use cases for the load balancing, failover and
administrative downtime scenarios.


Right.
The SVN transition is in progress, so it might be as well a good chance
to create a 1.3 branch we are talking about for more then a year.

Cleaning unused and dead code is one thing, and the other is making
those use-cases for load balancer.

I've tagged the 1.2.15 as the last one from the CVS, so if it will
be voted as stable, fine, if not, we'll pursue for 1.2.16 from 1.2
branch. All new stuff and eventual config changes should go to the
1.3. branch.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Final phase of SVN migration - the plan

2005-09-20 Thread Mladen Turk

Mark Thomas wrote:

All,

The plan for the last phase is slightly different since these 
repositories are in pretty much constant use.


I know there is a plan to do a JK release this week. If there is a 
timing clash, JK takes priority. Just shout and I'll delay giving infra 
the go-ahead to do the final migration.




Please don't get limited with that fact.
We can easily release from SVN, because when moved to SVN I'll
have to change jkrelease.sh script to reflect the changes, so it
might be as well a good opportunity for implementing that, cause
consecutive release will be coming from SVN repository.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Releasing JK 1.2.15

2005-09-19 Thread Mladen Turk

Hi,

There has been couple of major bug fixes
against 1.2.14, see:
http://jakarta.apache.org/tomcat/connectors-doc/changelog.html

They have been fixed in the CVS, and since
couple of them actually makes 1.2.14 unusable on
some platforms like Solaris 2.8 and Irix we need a release.

I plan to tag the 1.2.15 by the end of this week, and pursue
for a vote next week for this bug-fixing release.

Any objections?

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Bug or Feature inside mod_jk loadbalancer algo?

2005-09-16 Thread Mladen Turk

Peter Rossbach wrote:

Hey,

I have a strange loadbalancer behaviour at a customer site with Apache 
2/mod_jk 1.2.14, JVM 1.5, Tomcat 5.5.9 (cluster), (Suse 9.1)




Hi guys,

Peter you are correct about this...
I found by myself too, that balancer is misbehaving in some cases.
One of them is 'domain' model, where multiple workers should behave
like one on the global scale, but still maintain internal load.

The other is for worker-like mpm's when cachesize is lower then
the ThreadsPerChild. I've been able to fix that (sort of), but I'm
not happy with the fix.

What would I suggest is that we gather all the 'use cases' and
write down what the predicted results should be.

I'll create a separate .txt file (that will later be part of
loadbalancer howto) upon which we can enter the configuration
and expected behavior.

How that sounds?

I'm moving this discussion to the tomcat-dev@, so that we have the
trace of it. OK?

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Small refactoring in Http11Processor

2005-09-16 Thread Mladen Turk

Mark Thomas wrote:

Costin Manolache wrote:
Is there any plan to do a bit of cleanup ? Maybe move some of the dead 
code in connectors (mod_webap, jk2, etc ) to a new repo ? And maybe 
add a new 'sandbox' repository ?


I'll start a new thread to gather 
candidates to move to the archive area.




There are lots of things inside connectors that needs to be archived.
For example: /ajp, /jk/native2, /jk/webapp.

Also, not sure what the '/scandoc' is used for.

Further more, inside jk/native the docs, domino, nt_service and isapi
folders are obsolete.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs changelog.xml

2005-09-14 Thread Mladen Turk

Tim Whittington wrote:

I'm pretty sure this patch is broken looking at it now.
 
The HTTP_ variants used in the extension aren't initialized properly.

I'm currently on the road, but I'll be able to fix this up next week.



You are correct about that.
I was presuming the patch is correct (may bad), but it
lacks the HTTP_ prefixes. I'll correct that today or tomorrow
if you don't provide a patch.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs changelog.xml

2005-09-14 Thread Mladen Turk

Tim Whittington wrote:

I'm pretty sure this patch is broken looking at it now.
 
The HTTP_ variants used in the extension aren't initialized properly.

I'm currently on the road, but I'll be able to fix this up next week.



I've just commit the fix for the previous fix :)
Can you confirm if it's working for you?

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Small refactoring in Http11Processor

2005-09-09 Thread Mladen Turk

Costin Manolache wrote:

Hi,

Also, I would like to add another directory under j-t-c, with a build 
file and few classes for a 'mini' experiment - i.e. using the connector 
standalone, as a minimal http server, and also a target to build a 
minimal servlet container as a single self-contained jar. We don't have 
a sandbox, and j-t-c seems closest to that :-)




Hi Costin,
Nice to have you back :)

Anyhow, seems that the SVN transition is in progress.
If the time is acceptable, perhaps you can postpone that, and simply
create a branch in SVN.
I'm not sure when the code will be moved to SVN,
perhaps Mark will know.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



On Vacation

2005-08-19 Thread Mladen Turk

To whom it may concern :)

I'll be on vacation starting tomorrow for two weeks.

If somebody really needs to contact me I can be
reached at: +385.91.885.1068

Regards,
Mladen.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tomcat metrics

2005-08-12 Thread Mladen Turk

Yoav Shapira wrote:

Howdy,
This is just information for the curious or bored ;)


Right. Good for any school project ;)


result is only an approximation: 136K or so ;)



And webdav used 92K? Weird.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk logging buffer

2005-08-12 Thread Mladen Turk

Jean-frederic Clere wrote:

Radek Wierzbicki wrote:


Hello,



better :
if (l-level  JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG || 
level==JK_LOG_ERROR)

No?



Flush should not be executed for INFO level. It slows the things
down by the factor of 2. I agree for ERROR and EMERG.
DEBUG and TRACE uses fflush so the order of messages can be traced,
but that is also dubious because the messages could come from
different threads, so the best would be to use the fflush only
with ERROR and EMERGE levels.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: patch: mod_jk load balance algorithm that accounts for current worker load

2005-08-06 Thread Mladen Turk

Chris Lamprecht wrote:

mod_jk developers:

We have been using mod_jk for some time, (1.2.8, 1.2.10, and now
1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22
kernel).  We have 6 tomcats as balanced workers, and we're using
lb.method=[R]equest.



Great! Can you open an bugzilla entry for Native:JK and attach
the patch. Please file that as enhancement.

Regards,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Tomcat Native binaries repository

2005-08-03 Thread Mladen Turk

Hi,

As you might know due to the US export laws we are unable
to deliver the binaries that include encryption software
on any of our servers. Many Apache projects are suffering
from that restriction, so we are not the only one :)

Since TomcatNative uses OpenSSL for SLL protocol, delivering
binaries would break such policy and probably make problems.

Thanks to the courtesy of HEAnet, http://www.heanet.ie
(Ireland's National Education and Research Network), and
especially Colm MacCárthaigh, we have established an
alternate download site:
http://ftp.heanet.ie/pub/tomcat/


We have generic SSH username, and committers interested
in building binaries can send me their SSH key, so I can
send it to Colm.

Once again...
Many thanks to those guys!


Regards,
Mladen.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Alternate tomcat binaries repository

2005-07-26 Thread Mladen Turk

Hi,

I have spoke with Colm MacCárthaigh from HEAnet an he said that
they would be willing to give us the repo and SSL access to
their servers so we can set up a distribution repository
for SSL enabled binaries.

As you might know due to the US export laws we can not
have any encryption software on any of our (ASF) servers.

Of course the binaries would be 'unofficial', but we can
make a link to that site instead some of the exiting ones
that offer the OpenSSL binaries.

Any objections I proceed with that?


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk 1.2.14.1 Released?

2005-07-26 Thread Mladen Turk

Jess Holle wrote:

Was 1.2.14.1 ever officially released?



Well, it was voted as stable, so we only need
announcement.


If not, will it be soon?



Think that Jean-Frederic will make official announcement.
OTOH it might be that the heat wave in Spain
put him in some deep shade :)


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] SOC temporary committer Anders Nyman

2005-07-12 Thread Mladen Turk

William A. Rowe, Jr. wrote:

At 01:25 PM 7/11/2005, you wrote:

If the ASF have some agreement with Google then it should
have created a 'SoC Google sandbox' not trying to force
every project to create a 'Google sandbox'.



So it's unusual, and we aren't handing away keys to the entire
kingdom.  But setting up a sandbox (not your problem, it's the
mentors) and watching the progress (if it scratches your itch)
is not an imposition on the individual project communities.



Well if Tim wants to mentor that project, then fine with me.
I'm sure he will ensure the integrity of the Tomcat source
outside that 'sandbox' repository.

If the project will have access and modify the files outside
that repository, I'll be strongly against that.

I'm sure the Tim will find a solution for a files that needs to
be changed and that are are of the core, by simply mirroring
them to the sandbox repository or something similar.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: JK 1.2.14 core dump oddity

2005-07-12 Thread Mladen Turk

William A. Rowe, Jr. wrote:


Line 1971 of jk/native/apache-2.0/mod_jk.c says...

return OK;  /* NOT r-status, even if it has changed. */
This goes back to version 1.1 of the module; the question is; WHY?



Well, mod_jk presumes that when Tomcat serves the page it is 200.
You can make a custom error pages in Tomcat directly without using
ErrorDocument 404 /xxx


Regards,
Mladen.






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] JK 1.2.14.1

2005-07-11 Thread Mladen Turk


[X] Stable -- good build



Thanks for volunteering for a RM!

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] SOC temporary committer Anders Nyman

2005-07-11 Thread Mladen Turk

Tim Funk wrote:
As part of the Google SOC. Google accepted the tomcat-reverse-proxy 
project to be executed by Anders Nyman ( anders.nyman at gmail  d ot  
com  )



[ ] Sounds good to me
[ ] I'm indifferent
[X] I don't like it. Here's why



IMO the reverse proxy is a good thing to be done, and Tomcat can
benefit from it. I doubt if the balancer is a good place for such
addition.

Also I agree with Yoav. If the code is good, and if it works I see
no reason why not including it in the code.

I have developed, and I am developing the majority of the code
without being connected to the CVS all the time.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [VOTE] SOC temporary committer Anders Nyman

2005-07-11 Thread Mladen Turk

William A. Rowe, Jr. wrote:



It's important for students involved with SoC to learn to use
the tools of our organization;


I don't agree with you. The Tomcat is not place for some
'sandbox' projects.
If the ASF have some agreement with Google then it should
have created a 'SoC Google sandbox' not trying to force
every project to create a 'Google sandbox'.

Again, I have nothing against the effort or goals or 


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: j-t-c/common/build - j-t-c/jk/support ?

2005-07-11 Thread Mladen Turk

William A. Rowe, Jr. wrote:

It turns out the common/build macros are only referenced
within the jk tree (which is all I check out to build modjk).

I'd like to move the apache.m4, get_ver.awk and os_apache.m4
scripts to this new home, preserving history by copying the ,v
files, stripping old tags from the new copies and then cvs rm'ing 
the originals.   Votes/comments/concerns?




+1.

Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/

2005-07-07 Thread Mladen Turk

jean-frederic clere wrote:

Hi,

Just a note:
the current files are a bit old, shouldn't they point via a link to 
the last released version?




No, the current should point to the latest stable version.
You can add dev that will point to the latest version.

Regards,
Mladen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/native/common portable.h

2005-07-06 Thread Mladen Turk

[EMAIL PROTECTED] wrote:

jfclere 2005/07/06 06:52:06

  Modified:jk/native/common portable.h
  Log:
  just for the plaforms that don't have configure...
  
  Revision  ChangesPath

  1.4   +110 -0jakarta-tomcat-connectors/jk/native/common/portable.h



Why did you commit that?
It should be zero, because WIN and Netware will fail to build.
The portable.h is generated with configure, not in the CVS.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/native/common portable.h

2005-07-06 Thread Mladen Turk

jean-frederic clere wrote:

Mladen Turk wrote:


Why did you commit that?



First because it was not up to date, I have not added it...
For something weird plaforms it is nice to have it instead having to get 
it's content.




Hmm, portable.h is generated from portable.h.in on platforms that
have ./configure scripts at the first place.
All other platforms simply don't use it, but the file exists so
that we don't need extra #ifdef's


Right... That is a pitty to break Netware - I will add the file as 
portable.h.sample and restore the old one -




What would be the purpose of that sample? I mean, it is generated,
so each platform has more or less unique one.

If the configure can not generate the platform.h from platform.h.is,
what's the purpose of the configure at the first place?

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing JK 1.2.14

2005-07-06 Thread Mladen Turk

jean-frederic clere wrote:


Done, the branch is ready.
The files are in 
http://people.apache.org/~jfclere/jakarta-tomcat-connectors/



Hmm, it will not do.
The .zip files should have .dsp files (at least) in CR-LF format.
Think you'll need a win platform for making those.
If you don't have one, I can build a .zip files.

Regards,
Mladen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[OT] No software patents in Europe

2005-07-06 Thread Mladen Turk

Hi all,

Sorry for the off-topic post, but IMHO this is a great news for
all of us (free software developers).

After years of struggle, the European Parliament finally rejected the 
software patent directive with 648 of 680 votes: A strong signal against 
patents on software logic, a sign of lost faith in the European Union 
and a clear request for the European Patent Office (EPO) to change its 
policy: the EPO must stop issuing software patents today


More on:
http://www.fsfeurope.org/

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing JK 1.2.14

2005-07-06 Thread Mladen Turk

William A. Rowe, Jr. wrote:

Assuming you have apr checked out, apr/build/lineends.pl --cr will
convert a tree to cr/lf dos format, and info-zip does a lovely
job on Unix of zipping it up.



Right, a smarter unix2dos :)

Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: jni error

2005-07-05 Thread Mladen Turk

jean-frederic clere wrote:

Hi,

I have the following error when compiling:
+++
src/file.c   502: [error]:   CFE1136 struct JNINativeInterface_ has no 
field GetDirectBufferAddress

  char *bytes = (char *)(*e)-GetDirectBufferAddress(e, buf);
  ^
+++
My java version is 1.3.1, why are we requiring a very new one?



Yes, GetDirectBufferAddress is NIO feature of the 1.4

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh

2005-07-01 Thread Mladen Turk

[EMAIL PROTECTED] wrote:

  +# Check for links or w3m
  +W3MOPTS=-dump -cols 80 -t 4 -S -O iso-8859-1 -T text/html
  +LNKOPTS=-dump



Great, but I think that the links/elinks options should be:
--dump --no-references --no-numbering --no-home
That's at least for the elinks, but I suppose the links should
have something similar.

Just using dump will make the output pretty unfriendly ;)
In fact, the reason why I choose w3m was because it can give
a very clean .txt output.


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh

2005-07-01 Thread Mladen Turk

jean-frederic clere wrote:


no: links only wants -dump, but I have not problems to add elinks.



Well, whatever.

Didn't try the links (only elinks) so could not tell.
My SuSE is coming with w3m, so I don't really care ;)

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh

2005-07-01 Thread Mladen Turk

jean-Frederic clear wrote:

Mladen Turk wrote:


[EMAIL PROTECTED] wrote:


no: links only wants -dump, but I have not problems to add elinks.



Also, how about you volunteer for a 1.2.14 RM?
I was doing that for the last year and I'm getting pretty tired ;)

I will build as many binaries as I can.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh

2005-07-01 Thread Mladen Turk

Henri Gomez wrote:

+0, JF act as RM :)



Why?
He is a nice guy. He is even younger then Bob Geldof,
so what the obstacle for some altruism ;)

Cheers,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh

2005-07-01 Thread Mladen Turk

Henri Gomez wrote:

Because JFC is a great guy and someone I meet often.



He he.


And yes he will be a great RM :)
Go JFC, go



Right.
I think he can take some responsibility,
if he mess up, we'll kidnap his hamsters :)

Cheers,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/tools jkrelease.sh

2005-07-01 Thread Mladen Turk

jean-frederic clere wrote:


Well there are still 20 bugs in tomcat5/mod-jk, what do with them?



Not sure. Lot's of obsolete things that need a simple cleanup.

I can only tell the current CVS is the best ever mod_jk we had.
If it builds on all platforms (ant it does AFAICT),
we should go for the release ASAP.

There are just too many things that has been fixed since last stable,
that we should ignore or try to wait much further.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java

2005-06-30 Thread Mladen Turk

Bill Barker wrote:


Actually, on Solaris the big winner is ChannelNioSocket.  It wins the 
performance race easily now.  Too bad that NIO on Windows s*cks.  I 
guess that JFA was right, and non-blocking sockets is the way to go.




He he. We shall see :)



Now that I've looked at it a lot, however, I dislike the Java AJP 
impl, as it's way overengineered in comparison to what it required by 
the current Tomcat.



Hey, I like the overengineering ;-).  Yeah, Costin got a little 
ambitious here before deciding to just use Coyote.  On the other hand, 
when Mladen wants you to implement unix sockets for AJP/APR, ChannelUn 
is going to start to look good ;-).




Well, ChannelUn is obsolete because there is no need to add the
additional JNI wrapper, because we already have one.

Both unix sockets and NT pipes will be supported, by adding a single
param 'localAddress' or something. The platform local socket
AF_UNIX or NTPIPE will be used depending on the platform itself.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java

2005-06-30 Thread Mladen Turk

Jeanfrancois Arcand wrote:


Actually, on Solaris the big winner is ChannelNioSocket.  It wins the 
performance race easily now.  Too bad that NIO on Windows s*cks.  I 
guess that JFA was right, and non-blocking sockets is the way to go.




He he. We shall see :)


:-). Just take a look at the GlassFish module called appserv-http-engine 
 on java.net (http://weblogs.java.net/blog/jfarcand/). I'm sure you will 
like it :-). And I'm sure this community can come with something even 
better




Well I'm sure only of the following:
1. Blocking sockets outperforms NIO
2. NIO scales better

So the ideal would be to have them both at once.
Perhaps one day the Sun will accept some of my ideas and
allow to intermix the blocking and nonblocking IO.
Until then, well, I have 64 bit JVM and a 1GB RAM for couple of bucks,
and APR of course :)


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Releasing JK 1.2.14

2005-06-29 Thread Mladen Turk

Hi all,

Anyone aware of any pending issues for the next release.
Seems that all the bugs has been resolved from the 1.2.13.

If there are no objections, we can make a release by the
end of this week.
How that sounds?


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing JK 1.2.14

2005-06-29 Thread Mladen Turk

Henri Gomez wrote:

could you provide a beta source tarball to make the usual iSeries builds ?



Well, you have the j-t-c/tools/jkrelease.sh
But I've put the current head at:

http://people.apache.org/~mturk/jakarta-tomcat-connectors-current-src.tar.gz

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing JK 1.2.14

2005-06-29 Thread Mladen Turk

jean-frederic clere wrote:

Mladen Turk wrote:

In file included from mod_jk.c:28:
/home/jfclere/usr/local/apache2/include/ap_config.h:21:23: apr_hooks.h: 
No such file or directory


You apache installation sucks :)

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing JK 1.2.14

2005-06-29 Thread Mladen Turk

jean-frederic clere wrote:


apr_hooks.h is in 
/home/jfclere/usr/local/apr-util/include/apr-1/apr_hooks.h, probably 
something more is needed in configure.





Try to run the:
apxs2 -q APU_INCLUDEDIR

Seems that:
apxs2 -q INCLUDEDIR
is giving the /home/jfclere/usr/local/apache2/include
and 'apxs2 -q APR_INCLUDEDIR' is giving the
/home/jfclere/usr/local/apr/include/apr-1

The solution is to eiter copy APU_INCLUDEDIR to the INCLUDEDIR,
or figure out why APU_INCLUDEDIR gives nothing or points to the
wrong location.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing JK 1.2.14

2005-06-29 Thread Mladen Turk

jean-frederic clere wrote:


Try to run the:
apxs2 -q APU_INCLUDEDIR



it tells:
+++
[EMAIL PROTECTED]:~ usr/local/apache2/bin/apxs -q APU_INCLUDEDIR
/home/jfclere/usr/local/apr-util/include/apr-1
+++



That's bad.
It should point to your apr-utils/include.

It's probably the apxs broken, and I doubt you'll
be able to compile *any* module, not just jk.


The solution is to eiter copy APU_INCLUDEDIR to the INCLUDEDIR,


Should I fix it?



Well, the majority of apache distributions either have all httpd,
apr and apr-utils includes in a single directory.
The only difference is RHEL that has that separated, but even
there both apr and apr-utils includes are in the single directory.

Anyhow, it has nothing to do with the mod_jk.
He correctly queries and populates those include dirs if the
apxs reports them correctly.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing JK 1.2.14

2005-06-29 Thread Mladen Turk

jean-frederic clere wrote:


it tells:
+++
[EMAIL PROTECTED]:~ usr/local/apache2/bin/apxs -q APU_INCLUDEDIR
/home/jfclere/usr/local/apr-util/include/apr-1
+++



That's bad.
It should point to your apr-utils/include.


NO:
+++
ls -lt /home/jfclere/usr/local/apr-util/include/
total 4
drwxr-xr-x2 jfclere  users4096 2005-06-29 10:43 apr-1
+++




Sorry, it was typo.

apxs -q APU_INCLUDEDIR
/home/jfclere/usr/local/apr-util/include/apr-1
your apr-util is at:
/home/jfclere/usr/local/apr-util/include

and that's where the includes should be thought.

OTOH it might be the error in the configure.in:

INCTEMP=`$APXS -q APR_INCLUDEDIR` `$APXS -q APU_INCLUDEDIR`
for INC in ${INCTEMP}; do
  APRINCLUDEDIR=${APRINCLUDEDIR} -I${INC}
done

Try to change the:
INCTEMP=`$APXS -q APR_INCLUDEDIR` `$APXS -q APU_INCLUDEDIR`
to:
INCTEMP=`$APXS -q APU_INCLUDEDIR` `$APXS -q APR_INCLUDEDIR`

Seems strange that the
-I/home/jfclere/usr/local/apr-util/include/apr-1 is not listed on the
original dump you've posted.


Regards,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing JK 1.2.14

2005-06-29 Thread Mladen Turk

jean-frederic clere wrote:


Seems strange that the
-I/home/jfclere/usr/local/apr-util/include/apr-1 is not listed on the
original dump you've posted.



I have just retried from cvs it is ok.
From:
http://people.apache.org/~mturk/jakarta-tomcat-connectors-current-src.tar.gz 


it does not work. (the configure is wrong).



Hmm, it might be that ./buildconf.sh I've run is not portable enough.
Anyhow, re-running the ./buildconf.sh shoud work even with my shapshot.

Perhaps, you can see why the generated configure doesn't work?

Regards,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing JK 1.2.14

2005-06-29 Thread Mladen Turk

jean-frederic clere wrote:


I have just retried from cvs it is ok.
From:
http://people.apache.org/~mturk/jakarta-tomcat-connectors-current-src.tar.gz 


it does not work. (the configure is wrong).



I'm using the:

automake 1.8.3
aclocal  1.8.3
autoconf 2.59
libtoolize 1.5.2

That's form the SuSE SLES9/AMD64

Regards,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing JK 1.2.14

2005-06-29 Thread Mladen Turk

Mladen Turk wrote:

But I've put the current head at:

http://people.apache.org/~mturk/jakarta-tomcat-connectors-current-src.tar.gz 




Seems I've uploaded a wrong file :(.
Now it should contain the HEAD (727516 bytes).


Sorry for the confusion.


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jni/native configure.in

2005-06-23 Thread Mladen Turk

[EMAIL PROTECTED] wrote:

jfclere 2005/06/21 03:31:41
  Log:
  -Wall is only for gcc.



That's true. But if your 'cc' doesn't support
the -Wall then make CFLASG with some platform
switch rather then interfering with 99% of others that are using gcc.
The -Wall is very valuable when dealing with compile warnings,
and that was the main reason what the --enable-maintainer-mode
was added at the first place. It makes no sense without.



  -CFLAGS=${CFLAGS} -DDEBUG -Wall
  +CFLAGS=${CFLAGS} -DDEBUG


I would prefer that you add some platform case/esac that will
in ReliantUnix case add what ever you wish to the CFLAGS.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c jk_uri_worker_map.h

2005-06-23 Thread Mladen Turk

Derrick Koes wrote:
I tested yesterday's CVS head for compliance with session ID URL 
rewriting.  This fails.  The jsessionid is lost from the URL.




Well, I tested that with the /servlets-examples/servlet/SessionExample
and the jsessionid's *are* preserved.

Can you post the 'JkLogLevel debug' for the requests that are
in your opinion dropping the jsessionid?

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jni/native configure.in

2005-06-23 Thread Mladen Turk

William A. Rowe, Jr. wrote:

At 02:01 AM 6/23/2005, Mladen Turk wrote:




-CFLAGS=${CFLAGS} -DDEBUG -Wall
+CFLAGS=${CFLAGS} -DDEBUG


I would prefer that you add some platform case/esac that will
in ReliantUnix case add what ever you wish to the CFLAGS.



Conversely, a compiler case/esac would avoid altogether breaking
AIX, HP/UX, Reliant and a dozen other oddballs.  Forcing users to
play cflags is really a symptom of a weak build system.



Something simple like:

 
   if test $GCC = yes; then
 CFLAGS=${CFLAGS} -DDEBUG -Wall
   elif test $AIX_XLC = yes; then
 CFLAGS=${CFLAGS} -DDEBUG -qfullpath -qinitauto=FE -qcheck=all
   elif test $MYCOMPILER = yes; then
 CFLAGS=${CFLAGS} -DDEBUG my what ever flags
   else
 CFLAGS=${CFLAGS} -DDEBUG
   fi

Would do the trick ;)

Regards,
Mladen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Status of ajplib

2005-06-18 Thread Mladen Turk

Alexander Lazic wrote:

Hi,

i have looked at

http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/ajp/ajplib/src/

and there wasn't changes since 9-10 months.



Right. The entire source has been moved to the Apache HTTPD,
and is now part of mod_proxy.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



HEAD build failed

2005-06-18 Thread Mladen Turk

Anyone has any idea why I'm getting the following error when doing:
'ant download'


build-tomcat-dbcp:

-build-tomcat-dbcp:

BUILD FAILED
C:\W\projects\tomcat\jakarta-tomcat-5\build.xml:1895: The following 
error occurred while executing this line:
C:\W\projects\tomcat\jakarta-tomcat-5\build.xml:671: The following error 
occurred while executing this line:
C:\W\projects\tomcat\jakarta-tomcat-5\build.xml:683: The following error 
occurred while executing this line:
C:\W\projects\tomcat\jakarta-tomcat-5\build.xml:718: Cannot replace 
directory 
C:\W\projects\tomcat\repository\tomcat-deps\src\java\org\apache\tomcat\dbcp 
with directory 
C:\W\projects\tomcat\repository\tomcat-deps\src\java\org\apache\commons



Any clues.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: HEAD build failed

2005-06-18 Thread Mladen Turk

Mladen Turk wrote:

Anyone has any idea why I'm getting the following error when doing:
'ant download'


build-tomcat-dbcp:

-build-tomcat-dbcp:

BUILD FAILED



Dissreagard that email ;)
It's an 'ant 1.6.4' problem. What did they do to mess up the move task?


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Status of ajplib

2005-06-18 Thread Mladen Turk

Alexander Lazic wrote:


Right. The entire source has been moved to the Apache HTTPD, and is now
part of mod_proxy.


Oh, is the idea behind a ajblib dead?



Not sure :).
Perhaps it will finish as a console application for testing AJP
protocol (something like ab does for the http).
Beside that I see no other purpose for that peace of code.

Well, I was thinking to use it as foundation for the windows
http.sys. But who knows what the next windows generation
will offer. Since the development would take much more
then  next WIN-xx release, and since it would be a WIN only,
there is no need to use the APR, so again probably useless.


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Tomcat native WIN32 binaries

2005-06-18 Thread Mladen Turk

Hi,

If someone wishes to test the bleeding edge Tomcat Native,
the WIN32 binaries can be found at:

http://people.apache.org/~mturk/native/

I'll try to keep those up to date until we figure out the
binary distribution mode.

Regards,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Domino Tomcat Redirector

2005-06-17 Thread Mladen Turk

Andy Armstrong wrote:
I'm the current maintainer of the Domino Tomcat redirector but I  
haven't had time to do any work on it for the last year or so and I  
can't see that situation improving any time soon. I've made a couple  of 
attempts to contact someone at IBM who might be interested in  providing 
some (minimal) support without any success.


Accordingly I'd like to pass the reigns to someone else so if  anyone's 
interested could they contact me please.




Well, IMO even IBM has give his hands out of the Domino.
If someone wish to roll a dice, we have 1.2.6 that 'should'
support a Domino, at least version 5.
I've tried to make (newer, even 1.2.6) it work with version 6
(just as intellectual exercise) but never had any luck.

IMHO there is no reason to try to maintain something that
has no real-world usage or at least a support from the
(well IBM-lke company).

I'm trying to maintain a Netscape (SunOne now) port,
just because you can find a relatively new release,
and just because their API didn't change a lot.
Although I think that maintaining that is useless too.



Thanks - it's been fun :)



You can always find some other web server :)


Regards,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Domino Tomcat Redirector

2005-06-17 Thread Mladen Turk

Andy Armstrong wrote:


I haven't used Domino for nearly two years and I have to say, without  
wishing to be unkind to the people who developed it, that my head is  a 
lot better these days :)




Well, frankly I don't mind to have a support for XYZ server, if
at least that server is maintained by the publisher itself.

For example, I'll (personally) drop a support even for
SunOne (Netscape), simply because my 6 month free license just went out.

The fact that I only use Apache myself has made it difficult to stay  
interested in Domino...




Right.
Feel free to contribute to the Apache1/2 part of the mod_jk.


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c jk_shm.h jk_status.c

2005-06-14 Thread Mladen Turk

jean-frederic clere wrote:

William A. Rowe, Jr. wrote:

Mladen; are you sure you weren't looking for 'long long', al la 
int64_t?  Falling over to the FPU is rarely the best

performance decision.



A little more coding is needed, because I have a related error (on 
ReliantUnix):

undefined
  typedef uint32_t JK_UINT4;
  ^


Seems that the uint32_t is not inside includes referenced
by jk_global.h. Not sure what is the possible location
for that type on all platforms.

Perhaps u_int32_t would be more portable.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c jk_shm.h jk_status.c

2005-06-14 Thread Mladen Turk

jean-frederic clere wrote:

Mladen Turk wrote:



Perhaps u_int32_t would be more portable.



I would prefer to add in configure something like:
+++
AC_CHECK_SIZEOF(char, 1)
AC_CHECK_SIZEOF(int, 4)
AC_CHECK_SIZEOF(long, 4)
AC_CHECK_SIZEOF(short, 2)
AC_CHECK_SIZEOF(long long, 8)
+++
and testing $ac_cv_sizeof_WHATWETESTED makes sure we right one.



Yes, but all that we need is 32 bit unsigned integer for JK_UINT4
What will you use if the int is 64 bits?

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c jk_shm.h jk_status.c

2005-06-14 Thread Mladen Turk

jean-frederic clere wrote:

Mladen Turk wrote:


Yes, but all that we need is 32 bit unsigned integer for JK_UINT4
What will you use if the int is 64 bits?



a long ;-)



Right :)

You will need the portable.in in that case, right?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Regression -- jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c

2005-06-14 Thread Mladen Turk

Derrick Koes wrote:
URL rewriting is once again broken.  1.2.14 exhibits the problem for 
certain.  Older version may as well.  This was fixed in 1.2.8, but has 
regressed.


Has anyone else noticed the regression?



Could you explain what do you mean by 'regression',
and URL rewriting?

If you give some example of what are you doing,
what the JK does, and what in your opinion it should do,
that would be helpful.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c

2005-06-09 Thread Mladen Turk

jean-frederic clere wrote:

[EMAIL PROTECTED] wrote:

  Log:
  Change the BIOCallback interface to use write(byte[] buf) and
  read(byte[] buf);
  Add SSL_accept to do the client handshake.
  Arrange the corresponding example.
  



+++ CUT +++

Hi,

I am not 100% happy with the code. Mladen already asked me to rollback 
the changes. I think the worst thing is setSock() I have added to 
BIOCallback.


Yes please rollback.

My idea is/was to use BIOCallback or a similar interface to be able to 
openssl either with normal JAVA sockets or APR native ones.




I plan to create the SSLSocket that will use created Socket
(here I speak about Native sockets only) then obtain apr_os_sock_t
and then do a SSL accept on that accepted socket.

SSLSocket.create will create tcn_ssl_t from SSLContext and will
contain both apr_sock_t* and SSL*. We need APR socket to be
able to do the polling on the SSL sockets as well.

Please give me a day or two to finish the skeleton implementation,
that will do a basic s_server/s_client.

BIOCallback will be used only for:
1. Password callbacks
2. Error logging
3. Custom byte streams for certificate data contained in
   non file system storage.
   For example right now we have:
   SSLContext.setCertificate(..., file, ...)
   I plan to add the:
   SSLContext.setCertificate(..., BIOCallback, ...)
   read/write callback methods could be used for reading
   certificate data from database blobs, or directly from keystorage.


Regards,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c

2005-06-09 Thread Mladen Turk

Bill Barker wrote:


I am not 100% happy with the code. Mladen already asked me to rollback 
the changes.


It looked OK to me.  Basically it's the APR implementation of SSLEngine. 
Don't really see a problem.




It does not, because it should fit inside the APR standard socket
implementation. Having callbacks would actually make a thing way slower,
because we would have to call the native, and from the native call the
Java that would call back the native again.

Of course, I don't really care about the APR-SSL Connector one way or 
the other.  Since the config is the same as for mod_ssl, there is 
absolutely no reason to not simply use mod_ssl instead.  If I just 
wanted the native-code optimizations, I'd use PureTLS instead.




It's not an APR-SSL connector, but rather the SSL support for the APR
connector. Since all that is optional feel free to just not use it :)


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c

2005-06-09 Thread Mladen Turk

jean-frederic clere wrote:


It does not, because it should fit inside the APR standard socket
implementation. Having callbacks would actually make a thing way slower,
because we would have to call the native, and from the native call the
Java that would call back the native again.



Well we just need a nativeBIO and a javaBIO.



The plan is to use the:

1. apr_sock_accept/connect
2. obtain a os_sock
3. Make a BIO with os_sock_t
4. Use APR for socket_opt_set/socket_opt_get
5. Do a SSL_accept/SSL_connect
6. Make verify/handshake
7. use SSL_write/SSL_read for I/O.

All that will use the poller and the pool cleanup.

The Java part will go to the SSLSocket with the
Socket API with specific read* and write*

Regards,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c

2005-06-09 Thread Mladen Turk

jean-frederic clere wrote:


OK, I will create a SSLBIO.java/sslbio.c to go on testing/experimenting 
using with the BIOCallback, the interest there is to use an hardware 
accelator with openssl.




Please, can you give me a day to finish initial implementation.
Hardware accelerator is used by default on SSL.initialize(egineName)

Once again, can you hold up with adding new files?


Thanks,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [PATCH] jakarta-tomcat-connectors Chunked transfer encoding for IIS

2005-06-08 Thread Mladen Turk

Tim Whittington wrote:
This patch adds chunked encoding for IIS responses - i.e. 
Transfer-Encoding: chunked responses for HTTP/1.1 clients - allowing IIS 
to maintain persistent connections to HTTP/1.1 clients through the ISAPI 
redirector.




Could you create a bugzilla entry for that as an enhancement.
I doubt this will be committed to the 1.2 branch, because we
wish to keep it frozen for any new features.


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jni/native/src error.c

2005-06-07 Thread Mladen Turk

[EMAIL PROTECTED] wrote:

jfclere 2005/06/07 03:08:08

  Modified:jni/native/src error.c
  Log:
  typo? It cores in my machine...
  
  -free(msg);


Yes, nasty typo. I was freeing a static string. Just great :)

Thanks for tracking that down,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]

2005-06-07 Thread Mladen Turk

[EMAIL PROTECTED] wrote:

Hi,

I've been asking some more questions about restarts on the Apache list, and
was redirected back here...

Does anyone know (David, Mladen?) what will happen to session affinity is
this situation?

ie with Apache in front of several tomcats using mod_jk, when Apache is
restarted gracefully using apache -k restart (Windows) will session
affinity be preserved across the restart?  ie will browsers with a session
open with a particular Tomcat continue being directed to that particular
Tomcat after the restart?



First of all graceful restart will not work on Windows for any busy
server. I suggest that you move to some unix/linux version.

And yes, the session affinity will be preserved because it is
related to the worker name and jvmRoute.

Also, like somebody already told you: The easiest is to try by yourself,
and then come up with the real problem.


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]

2005-06-07 Thread Mladen Turk

[EMAIL PROTECTED] wrote:



First of all graceful restart will not work on Windows for any busy
server. I suggest that you move to some unix/linux version.



Errr...could you explain why?  I was told on the Apache list that it does
work on Windows...what am I missing?



It works of course, but IIRC you are planning to use it for
reconfiguring mod_jk. I think you might get into the problems
with shared memory (particularly on unix) because some child
might have a different idea about shared memory addresses.
If you do not delete any worker and add new one at the end
of the worker.list it might work.

Anyhow it's not something I would use in the production and rely on
its proper behavior.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Session Affinity after Graceful Apache restart? [was Re: Adding working dynamically with mod_jk status?]

2005-06-07 Thread Mladen Turk

William A. Rowe, Jr. wrote:

At 02:08 PM 6/7/2005, Mladen Turk wrote:



It works of course, but IIRC you are planning to use it for
reconfiguring mod_jk. I think you might get into the problems
with shared memory (particularly on unix) because some child
might have a different idea about shared memory addresses.



Oh - so this is a bug/design flaw in mod_jk?  Does the same
affect the prefork/worker MPMs?



Actually the WIN32 has no such problems because it uses the
plain memory instead of shared.
Problem with WIN32 is because the closing child and new child
will not share the worker data during restart, so you will loose
the statistics during restart.

With unixes the problem is because the workers are allocated
according to the worker.list and balance_members.
If you change those lists in the config on restart the child
processes could have different shared memory segment addresses.

Like said if you only add to the end of list then everything
will probably be OK.

To resolve that we would actually need a database like shared memory
with worker name as a key.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: source code for tomcat as a service...

2005-05-31 Thread Mladen Turk

Mark wrote:

OK, I got the source code.  From what I can tell, this will install my
program in  the same manner as Tomcat.  I will get the little icon in
the system tray and all that, which is awesome.
Do you know which parts of this I should be loading into MSVC++ in
order to build the executable?



Project files are for VisualStudio .NET
Open the src/native/nt/procrun/procrun.sln

prunmgr is tomcat5w.exe
prunsrv is tomcat5.exe

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java Response.java

2005-05-25 Thread Mladen Turk

[EMAIL PROTECTED] wrote:

billbarker2005/05/20 20:02:25

  Modified:catalina/src/share/org/apache/catalina/connector
Connector.java Response.java
  Log:
  Reverting previous patch in favor of the better one submitted by JFC




No idea why but suddenly I'm getting the following when stopping the
Tomcat with simple CTRL+C and AJP connector enabled.


INFO: Pausing Coyote HTTP/1.1 on http-8080
May 25, 2005 4:46:53 PM 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run
SEVERE: Caught exception (java.lang.NoSuchMethodError: 
org.apache.jk.core.MsgContext.getRequest()Ljava/lang/Object;) executing 
[EMAIL PROTECTED], terminating thread

May 25, 2005 4:46:54 PM org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina


Any ideas why?

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java Response.java

2005-05-25 Thread Mladen Turk

jean-frederic clere wrote:

Mladen Turk wrote:


INFO: Pausing Coyote HTTP/1.1 on http-8080
May 25, 2005 4:46:53 PM 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run
SEVERE: Caught exception (java.lang.NoSuchMethodError: 
org.apache.jk.core.MsgContext.getRequest()Ljava/lang/Object;) 
executing [EMAIL PROTECTED], terminating 
thread

May 25, 2005 4:46:54 PM org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina


Any ideas why?


Why do you think the changes in Connector and Response cause the problem?



If I would have an idea I wouldn't ask 'Any ideas why?' :).

Anyhow seems the problem with MsgContext.java when Bill
changed the :
-public final  Object getRequest()
+public final Request getRequest()

Think that down the classtree getRequest() is still considered to
return the Ljava/lang/Object.


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote

2005-05-25 Thread Mladen Turk

Remy Maucherat wrote:


In my mind, the argument for tomcat supporting 1000 concurrent
connections for an extended period of time isn't valid from my
experience.


- all the other APR features which are really useful and not provided by 
the core Java platform




Actually I just read a perfect use case scenario request for
the new APR connector on [EMAIL PROTECTED]
With only couple of threads all the 1000 connections could be handled
without having 1000 threads.


 Users are connecting to the solution by invoking a servlet (runned by 
tomcat).
 If a user is auhentified, then I use HTTPServletResponse object (in 
the service
 method) to get the Outputstream of that object = 
HTTPServletResponse.getoutputstream)


 Then this stream will be use to handle communications between my 
client application
 and my custom Server Process (I need to send real time informations 
through

 this canal).

 Important = A client session can last several hours, so the life of the
 servlet is set to time infinite .

 In fact I had the idea delegate socket connection managment, to 
tomcat engine,

 by setting servlet life time to infinite.

 Is it a good way to do, or should I use a socket pooling algorithm 
(actualy,
 the server can freeze, after unregular amout of times, time for 
writing operation

 in the Output stream can increase until being totaly unusuable, I have to
 close, and reconnect)

 The objective is to handle more than 1000 client sessions.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java Response.java

2005-05-25 Thread Mladen Turk

Bill Barker wrote:


Doing a clean build of j-t-c/jk/java should fix it.  MsgContext isn't 
referenced outside of there.




I'm doing 'ant checkout  ant'.

This is actually changed as part of Mark's Form-auth POST-replay, not 
the Connector/Response buffering.




OK. Will try the clean build.

Thanks,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Adding working dynamically with mod_jk status?

2005-05-25 Thread Mladen Turk

[EMAIL PROTECTED] wrote:

Is this still true if we were to define extra workers that are marked as
disabled at startup?  Could we then point them to any new servers as they
are added and enable them without a restart?  I know it's not very clean,
but would it work?




It will work if you know the hostname and the port that new server
will have in advance.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: jk 1.2.11 / 1.2.13 not working on iSeries

2005-05-24 Thread Mladen Turk

Henri Gomez wrote:

A quick note to tell that both jk 1.2.11 and 1.2.13 didn't works on iSeries.



Very informative email. Thanks for sharing that ;)


Can't check why now but iSeries users should stay with 1.2.10 :)



Any particular messages or clues?

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: jk 1.2.11 / 1.2.13 not working on iSeries

2005-05-24 Thread Mladen Turk

Henri Gomez wrote:

Nope, but I suspect a bad build options somewhere.



Probably some libraries missing in detecting network
capabilities within configure.in.



I rebuild 1.2.13 with the up to date options and wait my net engineers
to make a try.



Aha... Now we even have a staff of engineers. Cool :)


stray tuned



No problemo,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: jk 1.2.11 / 1.2.13 not working on iSeries

2005-05-24 Thread Mladen Turk

Henri Gomez wrote:

Well I couldn't use configure on iSeries.

What's libs are you talking for ?



See the JK_CHECK_SETSOCKOPT function in configure.in
Perhaps the -lsocket (socket lib) is missing on iSeries?
If it is, we'll need some arch switch.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Adding working dynamically with mod_jk status?

2005-05-24 Thread Mladen Turk

[EMAIL PROTECTED] wrote:

Any ideas or recommendations on this?



Adding workers would be tricky because if member of load balancer
it has to be known at startup time so that shared memory slot can be
allocated.

The only solution would be to edit the workers.properties file and
then forcing the Apache to restart.


Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Adding working dynamically with mod_jk status?

2005-05-23 Thread Mladen Turk

[EMAIL PROTECTED] wrote:

Hi,

Is there any way in the current implementatio to **add** a new worker (for
a new Tomcat instance) dynamically?  Using mod_jk status?  Another way?




No.

Can you elaborate why would you need such a feature?

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote

2005-05-20 Thread Mladen Turk
Vicenç Beltran wrote:
Hi, 

attached you'll find a patch that changes the coyote multithreading
model to a hybrid threading model (NIO+Mulithread). It's fully
compatible with the existing Catalina code and is SSL enabled.
diff -uprN
jakarta-tomcat-5.5.9-src/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Can't you simply make two new files
Http11NioProcessor and Http11NioProtocol.
Trying to change default implementation that Tomcat uses will never
be committed (at least I'll vote -1 on that).
Simply create two files that can be used instead current implementation,
in a fashion we did for Http11AprProtocol.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote

2005-05-20 Thread Mladen Turk
Vicenc Beltran Querol wrote:
Hi guys,
I'm not trying to be a Tomcat developer. I'm working on my PhD on web 
performance and just decided to share with you the experimental code I've 
developed after studying the performance obtained ;).
I've done some serious testings with HTTP server and NIO.
The results were always bad for NIO.
Blocking I/O is minimum 25% faster then NIO.
You may tray that simply by using demo HTTP servers
Blocking/Blocking Pool/NIO single thread/NIO multiple threads
that comes with new Java6 (see java.net for sources).
OTOH, I'm sure you must have some performance results :)
Simply run the 'ab -n 10 -c 100 -k host:8080/tomcat.gif'
with your patch and standard Tomcat5.5.9.

Anyway, it's OK. I'll work on the new patch and resubmit it. 

Great.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote

2005-05-20 Thread Mladen Turk
Jeanfrancois Arcand wrote:
I've done some serious testings with HTTP server and NIO.
The results were always bad for NIO.
Blocking I/O is minimum 25% faster then NIO.
Faster in what? Throughput and/or scalability?
I disagree ;-) I would like to see your implementation, because from 
what I'm seeing/measuring, it is completely the inverse. I would be 
interested to see how you did implement your NIO connector.
I do not understand why the people are so obsessed with NIO, really.
Like said there IS a example from Sun that tries all the strategies
you can imagine, even using mapped byte buffers, single/multiple
threads etc...
Feel free to test by yourself if you don't believe me.
Download the Mustang sources from
http://www.java.net/download/jdk6/
You have a complete stack of 5 web servers inside:
j2se/src/share/sample/nio/server
Also read a nice aricle:
http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/index.html
Solaris and Linux 2.6 threading support is much more advanced then it
was in a days the even architecture was 'pushed'.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JK shutdown problem

2005-05-20 Thread Mladen Turk
Jean-Jacques Clar wrote:
Hi,
 
file: jk_connect.c
in jk_shutdown_socket(); when reading data from tomcat in the while loop,
the variable ttl is incremented every time by one, until breaking out of the loop:
snippet: 
line 505 *-
/* Read all data from the peer until we reach end-of-file (FIN
 * from peer) or we've exceeded our overall timeout. If the client does
 * not send us bytes within12 second, close the connection.
 */
while (1) {
nbytes = jk_tcp_socket_recvfull(s, dummy, sizeof(dummy));
if (nbytes = 0)
break;
ttl += SECONDS_TO_LINGER;
if (ttl  MAX_SECS_TO_LINGER)
break;

}

The problem is because I do not have a Netware box.
You guys can try to enable the following:
#if defined(WIN32)
setsockopt(s, SOL_SOCKET, SO_RCVTIMEO,
   (const char *) tmout, sizeof(int));
#endif
for Netware too...
I didn't try to enable that because so many times the
JK has been broken because of Netware build bugs ;)
Also the code in nb_connect:
#if defined(WIN32)
int tmout = timeout * 1000;
setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO,
   (const char *) tmout, sizeof(int));
setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO,
   (const char *) tmout, sizeof(int));
#else ...
Shuld be checked for: (probably but who knows ;)
for :
#if defined(WIN32) || (defined(NETWARE)  defined(__NOVELL_LIBC__))
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


AJP/Java connector issues

2005-05-19 Thread Mladen Turk
Hi,
Just noticed a strange behavior in the Java part of the
JK dealing with large (over 8184 bytes) data transfers.
Since with 8192 bytes AJP packet size, the maximum
transferred size per each packet is 8184 bytes one
would expect that for 2 bytes file the packets
would be in a form of:
1:8184,2:8184,3:3632 thus total of 2 bytes.
But in fact the behavior is rely weird:
1:8184,2:8,3:8184,4:8,5:3616.
Instead only three, the five! packets are transferred.
Seems that algorithm is breaking 8192 bytes of data to
two packets (8184 and 8 bytes).
Bill,
Any idea how to solve this, because it's way too
inefficient.
What's makes the things even worse is that for each
packet Apache2 creates a transient bucket thus
rising the memory usage.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: AJP/Java connector issues

2005-05-19 Thread Mladen Turk
Bill Barker wrote:

I see what this is now:  The default Connector OutputBuffer size is 8K, 
so it's sending the output to JkInputStream in 8K chunks.  JkInputStream 
sends all of the 8K to Apache in two chunks.

As a Coyote OutputBuffer, it's not really JkInputStream's job to do 
additional buffering.  It's probably better to do 
response.setBufferSize(2); so that the Connector will send the whole 
thing to JkInputStream as one chunk.


Sure that seems to be the problem, but it's hard to convince the users
to write the applications having AJP packet size in mind ;)
The best would be that instead default 8192 bytes, when AJP connector
is loaded that response size is either set to 8184 or 16386 bytes
(one or two packets) by default.
Is something like that possible?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: AJP/Java connector issues

2005-05-19 Thread Mladen Turk
Bill Barker wrote:
Is something like that possible?
It would be really easy to default to 8184 for all Connectors (just change
the value in o.a.c.connector.OutputBuffer).  I'm not so sure how happy that
would make Remy.
Not much I'm afraid ;)

It wouldn't be too hard to have Connector.createResponse check the protocol,
and if it's AJP/1.3 then set the buffer size to 16386 (currently it's not
possible to decrease the buffer size).
That would be great.

It wouldn't be that hard to add buffering to JkInputStream so that it always
tries to write out a 8184 packet.  This would also prevent fracturing in the
event that the webapp programmer decides to call response.setBufferSize
herself.  The downside would be an extra arraycopy when writing (and, of
course, an extra 8184*numThreads bytes of memory used :).
Not very optimal IMO. If somebody sets the buffer size by hand, then,
well, he probably knows better :)
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JK 1.2.13 TAGGED

2005-05-18 Thread Mladen Turk
Günter Knauf wrote:
Hi Mladen,

JK 1.2.13 has been taggeded as we agreed last week,
and the tarballs are available at:
http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.13/
any particular reason why you didnt tag my last commit on jk_connect.c?
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/jk/native/common/jk_connect.c?rev=1.59view=log
now we can again not build for AP13 on NetWare without patching.
I thought you said last time that you are fine with the patch?
Yes I am. Have no idea why this file wasn't tagged.
Can we retag that file only and rerelease?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JK 1.2.13 TAGGED

2005-05-18 Thread Mladen Turk
Günter Knauf wrote:
Hi Mladen,

JK 1.2.13 has been taggeded as we agreed last week,
and the tarballs are available at:
http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.13/
any particular reason why you didnt tag my last commit on jk_connect.c?
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/jk/native/common/jk_connect.c?rev=1.59view=log
now we can again not build for AP13 on NetWare without patching.
I thought you said last time that you are fine with the patch?
Seems I made a mistake while tagging, although have no idea
why that happened :(.
I've retagged the jk_connect.c JK_1_2_13 to rev 1.59, so that
Netware patches are now included.
Hope I didn't break any ASF rule by that.
Should I recreate the tarballs?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JK 1.2.13 TAGGED

2005-05-18 Thread Mladen Turk
Henri Gomez wrote:
Yes ;-) 

Yes what?
Broke a rule or recreate the tarballs, or both :)?

And put a note about this change also in the download location 

In a form of? Any example?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JK 1.2.13 TAGGED - ws_write call to ap_rflush in mod_jk.c

2005-05-18 Thread Mladen Turk
jean-frederic clere wrote:
Mladen Turk wrote:
JkFlush (On|Off|size) with On as default for each packet write.
That way we'd be able to flush after each write, flush after each
'size' bytes or not flush at all.
Won't it be better to have a ws_flush()?
Not sure what you mean by that. Like a generic callback?
Not sure if it would make sense. IIS for example does
auto flushing, so It's only needed for Apache2.
Having 'JkFlush size' like 'JkFlush 65536' will insert
an EOS bucket after 64K. Having large chunks might make
problems to outgoing filters like deflate, that depends
on EOS bucket for compressing window size.
Right now the chunk size is AJP packet size (8K) that
might cause memory problems like JJC said.
Adding that as configurable server wide option will not break
exiting behavior, while it might speed up large data transfer,
and keep the memory low.
If 'JkFlush Off' is used a single ap_rflush will be issued
when all the data is send.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: JK 1.2.13 TAGGED

2005-05-18 Thread Mladen Turk
Henri Gomez wrote:
Or provide a jk 1.2.13a including this fix for novell ?
I would like to skip that, but I like the Jean-Frederic's idea
about putting the tarballs inside binaries/netware/
Anyhow, the plan was retag that as 1.2.14 if everything else
is OK, or make 1.2.14-rc-(xxx), after some test period, like
couple of weeks.
If you guys are OK with JJC concerns and my proposal on
ap_rflush/JkFlush we can add that to 1.2.14-rc-1, or
leave that for 1.3 branch.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  1   2   3   4   5   6   7   8   9   >